- From: James M Snell <jasnell@gmail.com>
- Date: Wed, 3 Oct 2012 15:14:09 -0700
- To: Ken Murchison <murch@andrew.cmu.edu>
- Cc: ietf-http-wg@w3.org
- Message-ID: <CABP7RbeMBOiA9FnQ-2F5AfB9aVnDcwdX4Xd0wCPs87YR78WRng@mail.gmail.com>
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 UTC