Subject: draft-snell-http-prefer

From: Ken Murchison <[email-masked]>
Date: Wed, 03 Oct 2012 10:27:09 -0400

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

---

From: James M Snell <[email-masked]>
Date: Wed, 3 Oct 2012 08:02:47 -0700

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 <[email-masked]> 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.
>
> - 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.
>

---

From: Ken Murchison <[email-masked]>
Date: Wed, 03 Oct 2012 11:14:44 -0400

Hi James,

That would obviously work.  Is reusing the Vary header not a good idea?

James M Snell wrote:
> 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 <[email-masked] 
> <mailto:[email-masked]>> 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 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.
>

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 3 Oct 2012 16:41:02 +0100

If the response has changed based upon the Prefer header, you really need to include Vary: prefer.

If you can infer from that what the server did, there's no need for a separate header.

Cheers,

On 03/10/2012, at 4:14 PM, Ken Murchison <[email-masked]> 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 <[email-masked] <mailto:[email-masked]>> wrote:
>>    Hello,
>>    --     Kenneth Murchison

--
Mark Nottingham
http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Wed, 3 Oct 2012 08:46:13 -0700

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 <[email-masked]> wrote:

>> On Wed, Oct 3, 2012 at 7:27 AM, Ken Murchison <[email-masked]<mailto:
>> [email-masked]>> wrote:
>>
>>     Hello,
>>

---

From: Ken Murchison <[email-masked]>
Date: Wed, 03 Oct 2012 11:50:35 -0400

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 
> 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 <[email-masked] 
>         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
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
> 
>             Hello,
>

---

From: James M Snell <[email-masked]>
Date: Wed, 3 Oct 2012 15:14:09 -0700

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 <[email-masked]> 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:
>
>> On Wed, Oct 3, 2012 at 8:14 AM, Ken Murchison <[email-masked]<mailto:
>>         <mailto:[email-masked] <mailto:[email-masked]>>**>
>> wrote:
>>
>>             Hello,
>>

---

From: Ken Murchison <[email-masked]>
Date: Fri, 12 Oct 2012 13:11:42 -0400

Hello,

Another ignorant question:  If an origin server honors the 
"return-representation" preference in a PUT request, does this alter the 
statement in HTTPbis Part 2 that PUT responses are not cacheable?

In other words, is there a way to make the response suitable for a cache 
to use it to satisfy subsequent GET/HEAD requests, in the same way that 
POST responses can be?

---

From: James M Snell <[email-masked]>
Date: Fri, 12 Oct 2012 10:21:55 -0700

No, the application of a preference does not alter the caching
characteristics of a method.

---

From: Martin Thomson <[email-masked]>
Date: Fri, 12 Oct 2012 11:49:52 -0700

On 12 October 2012 10:11, Ken Murchison <[email-masked]> wrote:
> In other words, is there a way to make the response suitable for a cache to
> use it to satisfy subsequent GET/HEAD requests, in the same way that POST
> responses can be?

p2 is quite clear on PUT and caches: PUT invalidates caches and nothing more.

My hope was that the rules for indicating that a response is cacheable
would be more generally applicable than for just POST.  I can see how
"return-representation" on PUT would be a useful optimization for
cache population.

---

From: James M Snell <[email-masked]>
Date: Fri, 12 Oct 2012 12:02:25 -0700

Yes it would be useful, but unfortunately not possible given the way PUT is
currently defined. The only way it could work is if an intelligent
intermediary handled the return-representation on it's own, issuing a
subsequent GET to the origin server and sending it's own response back to
the client rather than relying on the server. Obviously, however, that's
not something we can rely on.

- James

On Fri, Oct 12, 2012 at 11:49 AM, Martin Thomson
<[email-masked]>wrote:

> to

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 14 Oct 2012 05:40:57 +1100

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 <[email-masked]> 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

--
Mark Nottingham   http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Tue, 16 Oct 2012 17:14:10 -0700

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 <[email-masked]> 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
> 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,
>
>
> methods.  My work is primarily CalDAV-centric but we are trying to make it
> generic to WebDAV and its derivatives.
> >
> to indicate that the server understood the preference, thereby allowing the

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 16 Oct 2012 22:46:37 -0700

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

There is nothing to guarantee that the PUT payload received by
the origin server is byte-equivalent to the payload sent by the
user agent, so it does little good for the origin to say that
it received what "you" sent and didn't change it.

A more interoperable protocol would be for the request message to
contain some sort of end-to-end hash or signature of the request
representation, and the server to respond with the same hash
applied to the new representation.

....Roy

---

From: James M Snell <[email-masked]>
Date: Tue, 16 Oct 2012 22:56:45 -0700

On Tue, Oct 16, 2012 at 10:46 PM, Roy T. Fielding <[email-masked]> 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.
>
Noted and agreed.. but that's not quite what's going on with the Prefer
header here. The return-representation preference merely indicates to the
server that the UA would like the server to return a representation of the
resource within the response vs. a representation of the request status.
What's missing is some indicator within the response as to which the server
is actually returning. There is some ambiguity that needs to be resolved.
All the Preference-Applied header does is provide an explicit indicator
that the server did, in fact, do as the UA asked and returned the resource
representation in the response... an indicator that is only necessary if
it's not obvious by the content type of the payload or by direct
examination of the payload.

> applied to the new representation.
Agreed, but again, that's an orthogonal problem to the one addressed by the
Prefer header.

- James

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 16 Oct 2012 23:10:53 -0700

On Oct 16, 2012, at 10:56 PM, James M Snell wrote:
> Noted and agreed.. but that's not quite what's going on with the Prefer header here. The return-representation preference merely indicates to the server that the UA would like the server to return a representation of the resource within the response vs. a representation of the request status. What's missing is some indicator within the response as to which the server is actually returning. There is some ambiguity that needs to be resolved. All the Preference-Applied header does is provide an explicit indicator that the server did, in fact, do as the UA asked and returned the resource representation in the response... an indicator that is only necessary if it's not obvious by the content type of the payload or by direct examination of the payload. 

In that case, there is no need for it.  A Content-Location field with
the same value as the effective request URI means that the preference
has been applied.  See

http://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/21/p2-semantics.html#header.content-location

....Roy

---

From: James M Snell <[email-masked]>
Date: Tue, 16 Oct 2012 23:31:50 -0700

You know how every once in a while you can read something over and over and
about the fifth or sixth time you read through it you suddenly notice
something that's been there for a while and think, "Dammit! where did that
come from?!" ... Sigh, I had completely overlooked the fact that this level
of detail was added to p2 for content-location. Turns out it's quite
helpful to RTFM after all.

---

From: Ken Murchison <[email-masked]>
Date: Wed, 17 Oct 2012 08:15:05 -0400

James M Snell wrote:
> 
> 
> On Tue, Oct 16, 2012 at 10:46 PM, Roy T. Fielding <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     representation of the resource is byte-equivalent to the PUT request
>     you just made" for *that* case.
>      >
>     response. It could even be a "duplicate" link relation (RFC6249),
>     pointing to a URI for "the request you just made"; e.g.
> 
> header here. The return-representation preference merely indicates to 
> the server that the UA would like the server to return a representation 
> of the resource within the response vs. a representation of the request 
> status. What's missing is some indicator within the response as to which 
> the server is actually returning. There is some ambiguity that needs to 
> be resolved. All the Preference-Applied header does is provide an 
> explicit indicator that the server did, in fact, do as the UA asked and 
> returned the resource representation in the response... an indicator 
> that is only necessary if it's not obvious by the content type of the 
> payload or by direct examination of the payload. 

Actually, the question/concern that started this thread (not my own, but 
channeled from CalConnect) is can a client can figure out why the server 
didn't respond with a representation?  Did the server not understand the 
return-representation preference?  Did it understand it and choose to 
ignore it?  Or did the server not include a representation in the 
response because it didn't change from what the client sent and didn't 
want to waste the bandwidth?

If you don't think that this is a problem, or don't think its worth 
fixing (I might agree here), then please don't hold up the WGLC if 
Preference-Applied is going to be controversial.

---

From: James M Snell <[email-masked]>
Date: Wed, 17 Oct 2012 08:09:34 -0700

On Wed, Oct 17, 2012 at 5:15 AM, Ken Murchison <[email-masked]> wrote:

> [snip]
> ignore it?  Or did the server not include a representation in the response
> because it didn't change from what the client sent and didn't want to waste
> the bandwidth?
>
> If you don't think that this is a problem, or don't think its worth fixing
> (I might agree here), then please don't hold up the WGLC if
Thanks for chiming in again on it Kenneth. I was going to write this up
last night but ended up getting side tracked by sleep ;-) ... In my view
the Preference-Applied header is entirely optional. There's no demonstrated
harm in having it and it does have a useful (if limited) purpose for the
type of case you've suggested. I understand Mark's argument but I do not
feel the objection is strong enough to warrant holding things up (or making
further modifications to the spec). For those who do not feel the
Preference-Applied header is necessary, they needn't worry about it as it
can safely be ignored. For those who find it useful, it's there. Time and
implementation will ultimately determine whether it was truly necessary.

- James