Re: draft-snell-http-prefer

Comments inline...

On Mon, Oct 17, 2011 at 3:42 PM, Mark Nottingham <> wrote:
> 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:
> 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...

Well, again, the Content-Location option only works for that specific
pair of preferences. And yes, Preference-Applied does add complexity
but in some cases there will simply be no way of knowing for sure
whether a preference was honored. In many cases, there simply will not
be any reason to include a Preference-Applied in the response,
regardless of whether it was applied. For instance, in the 200 vs 204
or 202 response code scenarios, as well as the "priority-handling" and
"wait" scenarios.

Thinking about it further just now... perhaps we could get away with
eliminating Preference-Applied and "simply" requiring individual
prefer directives to provide for their own signaling mechanism. Let me
stew on this a bit more and work it through, but I'm starting to feel
swayed on 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.

It's not quite as open-ended as it would look on the surface, which
needs to be called out in the draft. For instance, if I pass along a
"Prefer: return-content", an intermediary is only going to be able to
honor that if it has the ability to retrieve the current
representation of that resource (e.g. from a cache). If I pass along a
"Prefer: return-accepted", it's perfectly reasonable to imagine an
intermediary that implements the async behavior in front of a server
that doesn't support it. Likewise, if I pass along a "Prefer:
priority-handling;l=1" with a request per that async priority queue
example I described, an intermediary choosing the apply that
preference is only doing so within the context of it's own handling of
the request and is not necessarily doing so on behalf of the origin
server. Or, if I pass along a "Prefer: strict-validation" extension,
there'd be no problem with an intelligent intermediary performing the
validation prior to dispatching that request on to the origin server.
In other words, this is not so much a case of the intermediary acting
on behalf of the origin server as it is  making allowances for the
intermediary choosing to honor a preference independently of the
origin server. Hopefully that makes sense, lol. It'll be clearer once
I get a moment to write up the actual description in the spec text
later tonight after these kids are down to bed.

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

Received on Tuesday, 18 October 2011 03:26:46 UTC