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: Tue, 16 Oct 2012 17:14:10 -0700
Message-ID: <CABP7RbducJuzFE7LFw8NeM3HOvwiifrnaC7GcQe61LDWXDa57w@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Ken Murchison <murch@andrew.cmu.edu>, ietf-http-wg@w3.org
I certainly do agree that it would be useful to have some generic mechanism
within the response that can be used to unambiguously indicate that the
payload is a representation of the resource vs. a representation of the
status but such a mechanism currently does not exist. Perhaps we should
take some time to write it up. In the meantime, while I do understand the
objection here, I don't see how any of the suggestions below are a
significant improvement over Preference-Applied since all would essentially
have to deal with the same set of issues. For now, Preference-Applied is
not a perfect solution, but it addresses the immediate need and the spec
does clearly specify that it's use is solely intended for situations where
the application of a preference is not readily determinable by examining
the response and such information is critical to the handling of the
response. Hopefully such cases will be rare.

Mark: perhaps the thing we should put our heads together on a solution to
the resource vs. status issue and see if we can come up with a more general

- James

On Sat, Oct 13, 2012 at 11:40 AM, Mark Nottingham <mnot@mnot.net> wrote:

> Actually, I don't think you need Preference-Applied *or* Vary to indicate
> this; both are barking up the wrong tree.
> Rather, you need something with the specific semantics "the representation
> of the resource is byte-equivalent to the PUT request you just made" for
> *that* case.
> This could be a new status code, or it could be a header on the response.
> It could even be a "duplicate" link relation (RFC6249), pointing to a URI
> for "the request you just made"; e.g.
> 200 OK
> Link: <urn:http:your-request>; rel="duplicate"
> (obviously, we would need to get the URL actually defined)
> The tricky part, no matter what approach you take -- including
> preference-applied! -- is figuring out what this means for headers; it's
> fuzzy at best.
> Cheers,
> On 04/10/2012, at 12:27 AM, Ken Murchison <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
> >
> --
> Mark Nottingham   http://www.mnot.net/
Received on Wednesday, 17 October 2012 00:15:16 UTC

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