Re: draft-snell-http-prefer

On 17/10/2011, at 5:26 PM, James Snell wrote:
> 
> One point that I will note (here and in the draft) although the draft
> itself currently only defines preferences involving the types of
> responses preferred by the client, the extensibility of the header
> makes it possible to leverage this mechanism to apply to any
> potentially optional feature or behavior employable by the server.

Which brings to mind the registry.

Currently, the policy is IESG approval. That's pretty heavyweight, and requires the IESG to know something about Prefer (fairly optimistic ;)

I'd be inclined to make this more something like Specification Required; that's significantly less burdensome (because it doesn't have to be an IETF spec, or even a spec from a standards org), and the time between request and registration can be significantly reduced.


>>> 3.  The Preference-Applied Response Header
>> 
>> I'm not sure this is necessary, as the application of the preference should
>> be obvious in the response, no?
>> 
> 
> Not necessarily. Imagine, for instance, the case where an API uses a
> JSON-encoded resource to report the status of a request as well as to
> represent the resource itself. If send Prefer: return-status and get
> back a JSON object, I would have no way of knowing prior to parsing
> the resource whether the preference was applied.

If there's a Content-Location header that has the same URI as the resource, it's a representation of that resource. See:
  http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-16#section-6.1

I've always thought of Prefer as a lightweight mechanism that can be used to simplify resources (e.g., so that I don't have to have a "full content" vs. "no content" URI for the same thing). I guess I'm concerned that, by adding an explicit return channel, it's making things potentially more complex; I can see people layering lots of weird things on top of this...


> Further, since the
> spec explicitly allows a proxy to honor a Preference even if the
> origin server does not, the Preference-Applied header can be used by
> the intermediary to determine the action taken by the server, to
> determine whether it needs to do any additional work at all.

Whoa. That's kind of a loophole that a truck can drive through. It's one thing to allow a proxy to turn a 200 into a 204; it's another to allow it to act on behalf of the origin server.

This needs to be bolted down; non-transforming intermediaries cannot change things without explicit permission in the protocol, and that's giving them way too much. I'd suggest making this a directive-by-directive decision. 


> As a side note, the fact that an intermediary can honor a preference
> independently also, at least partially, addresses the concern that Roy
> raises about whether the mechanism handling the PUT/POST would even be
> capable of honoring the Preference. An intelligent proxy could have
> mechanisms in place to properly handle the preference regardless of
> the capabilities of the mechanism handling the modification.


I see Roy's concern as already being dealt with by the optionality of the mechanism. I'm much more concerned about giving intermediaries -- especially proxies! -- so much license. 


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

Received on Monday, 17 October 2011 22:43:09 UTC