Re: draft-snell-http-prefer

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 15:51:09 UTC