Re: Prefer Draft Feedback

On 12/18/2011 07:46 PM, James Snell wrote:
> Updated version based on the latest round of feedback...
> 
>   http://www.ietf.org/id/draft-snell-http-prefer-08.txt

>    In the case generating a response will take longer than the time
>    specified, the server, or proxy, can choose to either return a 202
>    Accepted response, cancel processing, or continue attempting to
>    complete the request

If you want to recommend one of TWO server actions (either "return 202"
or "continue"), then please remove "cancel processing" to avoid the
implication that there is a third action.

If you want to recommend one of THREE server actions ("return 202",
"cancel processing", or "continue"), then please consider removing
"either". In this case, you may want to clarify what "cancel processing"
means from the HTTP protocol point of view. Some kind of response is
probably appropriate even if request processing is canceled.

Please consider replacing "can choose to" with "MAY".


>    Failing to include a Date header field in the request would
>    require the server to use the instant it received and began
>    processing the request as the baseline for determining how long the
>    client has been waiting which could yield unintended results
>    depending on how out of synch the client and server clocks are.

The "depending on how out of synch the client and server clocks are"
trailer should be removed because:

1) When the clocks are out of sync, the Date header can only hurt so the
"Failing to include" precondition is not applicable when clocks are out
of sync.

2) When the clocks are in perfect sync, but there is no Date header,
then there still will be "unintended results", caused by absence of any
information regarding how long the client has already been waiting for
when the server received the request.

In other words, the Date header is no meant to solve the problem with
out-of-sync clocks. It is meant to solve the problem of a [long] chain
of [slow] connections/proxies eating at the remaining time to process
the request.


>    Note that because of the inherent difficulties in reliably
>    determining the length of time a request will take to arrive at
>    server, the wait preference is, at most, a hint to the server as to
>    what the client is likely to do should the processing of a request
>    take too long.

It feels like the "is, at most, a hint" part implies that all of the
above specs were useless. If the preference is just such a hint (or
less!), there is no need to specify the wait time. Perhaps it would be
better to rephrase the above in most specific terms? For example,

Lack of a Date header or poor clock synchronization makes it impossible
to determine the exact length of time the client has already been
waiting for when the request was received by the server. The only
reliable information conveyed by the wait preference is that the client
is not expecting the server to spend more than the specified time on
request processing and may terminate the transaction at any time.



>    When specifying a value for the wait preference,
>    Client's need to take appropriate care to specify a reasonable period
>    of time.

Replace "Client's need" with "client needs". I would actually remove
this sentence completely because it essentially says that "client needs
to be reasonable" which is kind of obvious/understood.

Moreover, when thinking about a _client_ implementation, I think all of
the above complications become unimportant. Our assumption is that the
client has its reasons to limit the wait.  It should not be important to
the _client_ what portion of its lifetime the request spends in-transit
or whether the clocks are in sync. All of that is outside client control
anyway. The client has reasons to terminate the transaction in X seconds
[after Date], and that is what it should say using this preference.


HTH,

Alex.

Received on Monday, 19 December 2011 05:15:54 UTC