Re: draft-snell-http-prefer

My apologies for missing this Mark, comments inline

On Thu, Oct 6, 2011 at 8:05 PM, Mark Nottingham <mnot@mnot.net> wrote:
> Hi James,
>
> I notice that this draft expired a few days ago. Are you still planning on
> persuing it?
>

Yes.

> If so, it'd be good to motivate the document, as per Roy's comment
> <http://lists.w3.org/Archives/Public/ietf-http-wg/2011JanMar/0294.html>.
>

Definitely noted. I will update the draft with appropriate coverage for this.

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. One
example that has come up in a real scenario is a server that allows
clients to request a certain level of error handling capability and
detail in an error response. For instance, when PUTing a resource, the
client could ask for "Prefer: strict-validation" or "Prefer:
relaxed-validation", either of which could impact the choices the
server makes when processing the resource and reporting errors.
Obviously the server is still free to do whatever it wants in either
case.

Another real-world use case that has come up is the ability for a
client to request a certain priority for handling a given request. In
the case that came up, if a client wished to request that a server
handle a given request with greater priority than another, it could
include something along the lines of, "Prefer: priority-handling;l=1"
(where l is a non-negative integer [1...*] specifying the handling
priority, 1 being the highest). This obviously only works is fairly
controlled environments, but you get the idea... use of the Prefer
header is in no way bound strictly to the determination of which
response codes and payloads to return.

(Just to note, in this particular case, the priority-handling
preference is combined with the return-accepted preference to
construct what is essentially an asynchronous priority queue for
long-running requests)

A third case that has come up (albeit purely experimental at this
stage) involves the use of Prefer in cometd/long-polling scenarios...
essentially using it as a mechanism for indicating whether the client
would like the server to return a response immediately or hold the
connection until a response is available without requiring the use of
a query string parameters in the request URI. For instance,

GET /my_uri HTTP/1.1
Prefer: no-wait

vs.

GET /my_uri HTTP/1.1
Prefer: wait

Again, the server is obviously free to do what it wants, but in this
particular scenario, when the server received a no-wait preference, it
returned immediately without holding the connection regardless of
whether there was any data to return. When receiving a "wait"
preference, on the other hand, the connection would be held until data
became available or until a certain server specified period of time
had passed.

Obviously, these scenarios are possible through the use and
manipulation of query string parameters, but those, too, have their
own drawbacks.
> A few suggestions:
>
>> Note that the application of a preference by the server MAY affect the
>> caching characteristics of the response.
>
> It'd be good to mention Vary here explicitly.

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

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.

>
>> The "return-accepted" token indicates that the client prefers that
>> the server respond with a 202 Accepted response indicating that the
>> request has been accepted for processing.
>
> I think the use case here is that a 202 is preferred *if* the response takes
> too long to generate, by some arbitrary measure (under control of the
> server), not that the 202 is unconditionally preferred over a 200 (for
> example).
>
> If so, it'd be good to explain.
>

Agreed. This is one that definitely needs expansion. I don't believe
we necessarily have to leave it completely under the control of the
server. When specified by itself, e.g. "Prefer: return-accepted"...
then yes, the server decides the maximum acceptable wait time.
However, when specified as "Prefer: return-accepted; wait=1000"
(where "wait" is specified in milliseconds), this would effectively be
interpreted as "If the response will take at least 1000 milliseconds
or more to complete, please return a 202 Accepted Response". Even
specified in this way, as application of the Preferences header is
entirely optional on the part of the server, the server can choose to
do what it wants. For instance, if the server deems the 1000
milliseconds to be to long to wait and returns a 202 after only 500
milliseconds, then it can return a "Preference-Applied:
return-accepted; wait=500" in the response.

>
>> 5.  The "return-content" Preference
>
> I think this needs to explain that if the response isn't normally a
> representation of the resource, you need to include a Content-Location
> header with the resource's URI (see the httpbis drafts).
>

Agreed.

>
> Cheers,
>

Thanks for the feedback. I'll get that draft updated within the next
day or two.

- James

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

Received on Monday, 17 October 2011 06:29:38 UTC