Ok.. another iteration... bumped it once but realized just after that
I had omitted the Date header from the wait examples so bumped it
again...
http://www.ietf.org/id/draft-snell-http-prefer-10.txt
- James
On Mon, Dec 19, 2011 at 10:00 AM, James Snell <jasnell@gmail.com> wrote:
> Thx for the quick response... I'm making some tweaks and using some of
> your suggested text in the next draft.
>
> I'd like to be able to put a wrap on this after this next iteration.
>
> - James
>
> On Sun, Dec 18, 2011 at 9:15 PM, Alex Rousskov
> <rousskov@measurement-factory.com> wrote:
>> 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.