Re: draft-snell-http-prefer

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
solution?

- 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/
>
>
>
>
>