W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2011

Re: draft-snell-http-prefer

From: James Snell <jasnell@gmail.com>
Date: Mon, 17 Oct 2011 06:36:03 -0700
Message-ID: <CABP7Rbf0PjVXhWCFW8thRA8_gXCs2=qU0goLqUHzYfFnOb-+vw@mail.gmail.com>
To: "Thomson, Martin" <Martin.Thomson@commscope.com>
Cc: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Sun, Oct 16, 2011 at 11:40 PM, Thomson, Martin
<Martin.Thomson@commscope.com> wrote:
> On 2011-10-17 at 17:26:30, James Snell wrote:
>> 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.
>
>
> Hi James,
>
> I've been looking at this for a little while and I think that you could address both with an (optional) parameter that sets an upper bound on the wait interval.  This indicates that after this time, the client is likely to close the connection.  I've found some cases where knowing the time limit can affect what the server does in order to produce a result.
>
> Prefer: wait=0 is then equivalent to no-wait.  We've found that being able to set a limit on the wait time is quite useful.  A server (or intermediary) that was aware of the prefer option can then generate a response prior to this time elapsing.
>

Martin, agreed... my feedback to the folks who were putting this
particular implementation together was along the same lines, actually.
In fact, thinking about it further, defining "wait" as a distinct
preference allows us to keep from having to parameterize the
return-accepted preference, we'd simply be able to compose the two:
"Prefer: return-accepted, wait=500".

- James

> --Martin
>
Received on Monday, 17 October 2011 13:36:40 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:48 GMT