Re: Prefer Draft Feedback

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 17:41:59 UTC