Re: Prefer Draft Feedback

The bottom line to it is timing on the web is always going to be messy
and there's not a thing we're going to be able to do about that (nor
should we really try). The wait preference is intended as a hint to
the server as to what the client will likely do if the request takes
too long to process, not an absolute top limit. When setting the
preference, the client needs to specify a reasonable period of time
based on what it expects the latency to be. There's not much else we
can (or should) do... it is an optional preference afterall.

On Mon, Dec 12, 2011 at 9:40 AM, Alex Rousskov
<rousskov@measurement-factory.com> wrote:
> On 12/09/2011 08:48 PM, Martin Thomson wrote:
>
>> Regarding wait and Date and the text added since -05:
>>
>> You recommend that the client use Date so that the server knows the
>> absolute time that a response is required.  I don't see that working
>> particularly well in practice.
>
> An accurate Date header seems necessary for "wait" when multiple
> intermediaries are present. Without it, the end recipient will not be
> able to approximate the amount of time the user agent has been waiting.
> If such approximation is not necessary, the preference wording should be
> adjusted accordingly.
>
> We could assume that any number of intermediaries will not delay the
> requests by more than a couple of seconds, but that assumption will be
> wrong when connectivity is poor. Whether the preference is meant to work
> in poor connectivity cases or just in slow origin server cases is not
> clear to me.
>
> If recommendation for the Date header is removed, new wording should be
> added to explain that proxying and transmission delays are deemed
> unimportant for this preference.
>
>
>> It's very hard to know what time the client truly made a request, even
>> with a Date header.  At least at the client end, you can make some
>> assumptions so that you can compensate for clock drift and
>> request/response transit times.  Without a closed loop, it's virtually
>> impossible to guarantee good timing.
>
> If an agent clock is seriously wrong, the inclusion of Date header may
> indeed screw things up. Thus, we have a choice between two directions:
>
> 1) Focusing on correctly handling proxied transactions and slow
> connections when agent clocks are reasonably correct.
>
> 2) Focusing on per-hop processing delays and bad clocks while ignoring
> many delays caused by slow/poor connectivity.
>
> Either choice is OK, I guess, as long as it is clearly documented.
>
>
> Cheers,
>
> Alex.

Received on Monday, 12 December 2011 18:41:46 UTC