IETF Logo Mail Archive

Re: draft-murchison-webdav-prefer

Ken Murchison <murch@andrew.cmu.edu> Thu, 18 December 2014 15:59 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA8A51A8A7B for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 18 Dec 2014 07:59:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTdJGKZ92qGY for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 18 Dec 2014 07:59:33 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D58171A701F for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 18 Dec 2014 07:59:32 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1Y1dS6-00036t-B7 for ietf-http-wg-dist@listhub.w3.org; Thu, 18 Dec 2014 15:57:22 +0000
Resent-Date: Thu, 18 Dec 2014 15:57:22 +0000
Resent-Message-Id: <E1Y1dS6-00036t-B7@frink.w3.org>
Received: from lisa.w3.org ([128.30.52.41]) by frink.w3.org with esmtp (Exim 4.80) (envelope-from <murch@andrew.cmu.edu>) id 1Y1dRv-00034X-5z for ietf-http-wg@listhub.w3.org; Thu, 18 Dec 2014 15:57:11 +0000
Received: from smtp.andrew.cmu.edu ([128.2.105.204]) by lisa.w3.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from <murch@andrew.cmu.edu>) id 1Y1dRr-0007jA-NB for ietf-http-wg@w3.org; Thu, 18 Dec 2014 15:57:11 +0000
Received: from localhost.localdomain (cpe-76-180-151-43.buffalo.res.rr.com [76.180.151.43]) (user=murch mech=PLAIN (0 bits)) by smtp.andrew.cmu.edu (8.14.8/8.14.8) with ESMTP id sBIFujPM031012 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 18 Dec 2014 10:56:45 -0500
Message-ID: <5492F93D.5060804@andrew.cmu.edu>
Date: Thu, 18 Dec 2014 10:56:45 -0500
From: Ken Murchison <murch@andrew.cmu.edu>
Organization: Carnegie Mellon University
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: James M Snell <jasnell@gmail.com>
CC: ietf-http-wg@w3.org
References: <5492F15E.8080101@andrew.cmu.edu> <CABP7RbfrGXG7JU=+HM-GcssOmshfhkae5kv5bhZ7VLofnVLcPQ@mail.gmail.com>
In-Reply-To: <CABP7RbfrGXG7JU=+HM-GcssOmshfhkae5kv5bhZ7VLofnVLcPQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------060801090004010306040104"
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.18.154820
X-SMTP-Spam-Clean: 27% ( SXL_IP_DYNAMIC 3, BODYTEXTH_SIZE_10000_LESS 0, BODYTEXTP_SIZE_3000_LESS 0, BODY_SIZE_5000_5999 0, BODY_SIZE_7000_LESS 0, DATE_TZ_NA 0, FROM_EDU_TLD 0, RDNS_GENERIC_POOLED 0, RDNS_POOLED 0, RDNS_RESIDENTIAL 0, RDNS_SUSP 0, RDNS_SUSP_GENERIC 0, RDNS_SUSP_SPECIFIC 0, REFERENCES 0, __ANY_URI 0, __BAT_BOUNDARY 0, __BOUNCE_CHALLENGE_SUBJ 0, __BOUNCE_NDR_SUBJ_EXEMPT 0, __CP_URI_IN_BODY 0, __CT 0, __CTYPE_HAS_BOUNDARY 0, __CTYPE_MULTIPART 0, __CTYPE_MULTIPART_ALT 0, __FORWARDED_MSG 0, __HAS_FROM 0, __HAS_HTML 0, __HAS_MSGID 0, __IN_REP_TO 0, __MIME_HTML 0, __MIME_VERSION 0, __MOZILLA_MSGID 0, __MOZILLA_USER_AGENT 0, __RDNS_POOLED_1 0, __REFERENCES 0, __SANE_MSGID 0, __SUBJ_ALPHA_END 0, __SUBJ_ALPHA_NEGATE 0, __TAG_EXISTS_HTML 0, __TO_MALFORMED_2 0, __URI_NO_WWW 0, __URI_NS , __USER_AGENT 0)
X-SMTP-Spam-Score: 27%
X-Scanned-By: MIMEDefang 2.74 on 128.2.105.204
Received-SPF: none client-ip=128.2.105.204; envelope-from=murch@andrew.cmu.edu; helo=smtp.andrew.cmu.edu
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: AWL=-2.261, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001
X-W3C-Scan-Sig: lisa.w3.org 1Y1dRr-0007jA-NB 1f78ff9378c19f35dedd947de7191c52
X-Original-To: ietf-http-wg@w3.org
Subject: Re: draft-murchison-webdav-prefer
Archived-At: <http://www.w3.org/mid/5492F93D.5060804@andrew.cmu.edu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/28338
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

Hi James,


On 12/18/2014 10:52 AM, James M Snell wrote:
>
> I think that behavior is acceptable. Please be sure to include the 
> Preference-Applied response header tho. Just to make it unambiguous.
>

Yes, absolutely.  The example in the draft includes it as does my dev 
implementation.



> On Dec 18, 2014 7:26 AM, "Ken Murchison" <murch@andrew.cmu.edu 
> <mailto:murch@andrew.cmu.edu>> wrote:
>
>     All,
>
>     I'd like to get some feedback on draft-murchison-webdav-prefer
>     <http://tools.ietf.org/html/draft-murchison-webdav-prefer-07> ,
>     specifically Section 3
>     <http://tools.ietf.org/html/draft-murchison-webdav-prefer-07#section-3>
>     (the rest of the document is truly WebDAV specific).  Per a
>     request from the Apple calendar client folks, we'd like to extend
>     Prefer:return=representation
>     <http://tools.ietf.org/html/rfc7240#section-4.2> to apply to a
>     conditional PUT request that fails with a 412 (Precondition
>     Failed) response.  This eliminates the need for a subsequent GET
>     to fetch the current representation of a resource that failed to
>     update because of a validator mismatch.  I view this as analogous
>     to Get + If-Range.
>
>     Does anyone see any issues with this new behavior?  Does it
>     violate RFC7230-7232 in any way?  Are we allowed to extended
>     return=representation to failure responses (RFC7240 only discusses
>     success responses)?  Are there any other sane interpretations of a
>     412 response with a Preference-Applied:representation header field
>     which would cause ambiguity for the client?
>
>     Thanks and Happy Holidays!
>     Ken
>
>     -- 
>     Kenneth Murchison
>     Principal Systems Software Engineer
>     Carnegie Mellon University
>


-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University

v2.23.0 | Report a Bug | By Email