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 15:14:09 -0700
Message-ID: <CABP7RbeMBOiA9FnQ-2F5AfB9aVnDcwdX4Xd0wCPs87YR78WRng@mail.gmail.com>
To: Ken Murchison <murch@andrew.cmu.edu>
Cc: ietf-http-wg@w3.org
There is already mention of Vary in the current Prefer draft. Essentially,
it says that if the application of a preference could alter the cacheing of
a response, the response MUST contain Vary: Prefer. It wouldn't hurt to
reinforce that in your draft.

- James

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

> Yes.  Our application of return-minimal and our newly defined depth-noroot
> to PROPFIND and REPORT should include Vary: Prefer and I will mention that
> in my draft.
>
> Should I also mention the same thing in regards to return-representation,
> or would that belong in your draft?
>
>
> James M Snell wrote:
>
>> 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<mailto:
>> 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>
>>         <mailto: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
>>
>>
>>
>
> --
> Kenneth Murchison
> Principal Systems Software Engineer
> Carnegie Mellon University
>
Received on Wednesday, 3 October 2012 22:14:57 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 3 October 2012 22:15:00 GMT