W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2012

Re: draft-snell-http-prefer

From: James M Snell <jasnell@gmail.com>
Date: Wed, 3 Oct 2012 08:46:13 -0700
Message-ID: <CABP7Rbc2_VF05kjqh1FkYS8vwN-GpLwwC8SCPKXckoLVR6GRxA@mail.gmail.com>
To: Ken Murchison <murch@andrew.cmu.edu>
Cc: ietf-http-wg@w3.org
Given the specific mechanisms of the how your webdav-prefer is defined, you
really should have a Vary: Prefer in your responses anyway since the
application of the Prefer header will lead to variations in the specific
entity returned. Accordingly, if Vary: Prefer is always present, you'll
either need some separate mechanism to indicate that a specific Preference
was applied or, as Mark suggests, apply some heuristics to infer what the
server did.

- James

On Wed, Oct 3, 2012 at 8:14 AM, Ken Murchison <murch@andrew.cmu.edu> wrote:

> Hi James,
> That would obviously work.  Is reusing the Vary header not a good idea?
> James M Snell wrote:
>> A much older version of the specification included an optional
>> Preference-Applied response header that could explicitly indicate whether a
>> particular preference was applied, but after lots of feedback that "I
>> wasn't going to need it", I pulled it back out (largely against my better
>> judgement). I'm thinking that perhaps it needs to be added back in.
>> - James
>> On Wed, Oct 3, 2012 at 7:27 AM, Ken Murchison <murch@andrew.cmu.edu<mailto:
>> murch@andrew.cmu.edu>> wrote:
>>     Hello,
>>     I'm working on draft draft-murchison-webdav-prefer which describes
>>     how the return-minimal and return-representation apply to
>>     WebDAV/CalDAV methods.  My work is primarily CalDAV-centric but we
>>     are trying to make it generic to WebDAV and its derivatives.
>>     One of the issues that keeps coming up is a way for the client to
>>     differentiate between two  cases:
>>     - the server doesn't return a representation because it ignored or
>>     doesn't support the return-representation preference
>>     - the server understood the preference but didn't return a
>>     representation because it didn't change from what was in the request
>>     One possible solution is for the server to return a Vary: Prefer
>>     header to indicate that the server understood the preference,
>>     thereby allowing the client to infer what the lack of a
>>     representation in the response means.
>>     The next question is, does any such mandate or recommendation, if
>>     required, belong in my webdav-prefer draft or in the base Prefer spec?
>>     Thoughts?
>>     --     Kenneth Murchison
>>     Principal Systems Software Engineer
>>     Carnegie Mellon University
> --
> Kenneth Murchison
> Principal Systems Software Engineer
> Carnegie Mellon University
Received on Wednesday, 3 October 2012 15:47:06 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC