Re: draft-snell-http-prefer

Ok... I've published an update

http://www.ietf.org/id/draft-snell-http-prefer-04.txt

I've added much more explanation around the motivation for each
preference directive but I plan on making another round of edits to
tease it out further.

- James

On Mon, Oct 17, 2011 at 8:26 PM, James Snell <jasnell@gmail.com> wrote:
> Comments inline...
>
> On Mon, Oct 17, 2011 at 3:42 PM, Mark Nottingham <mnot@mnot.net> 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.
>>
>
> Agreed.
>
>>
>>>>> 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...
>>
>
> 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   http://www.mnot.net/
>>
>>
>>
>>
>

Received on Tuesday, 25 October 2011 16:43:46 UTC