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

Re: Last Call: <draft-snell-http-prefer-14.txt> (Prefer Header for HTTP) to Proposed Standard

From: Martin Thomson <martin.thomson@gmail.com>
Date: Fri, 5 Oct 2012 11:12:26 -0700
Message-ID: <CABkgnnWvbjkmXe_orAKwLuq8J7LJ2uCgcW7Ry=mhBj=gOTgYHA@mail.gmail.com>
To: James M Snell <jasnell@gmail.com>
Cc: Julian Reschke <julian.reschke@gmx.de>, ietf@ietf.org, SM <sm@resistor.net>, HTTP Working Group <ietf-http-wg@w3.org>
On 5 October 2012 10:42, James M Snell <jasnell@gmail.com> wrote:
> I could drop the Date header recommendation altogether and stress in the
> text that good clock synchronization and predictable latency is required for
> the wait preference to be used effectively.

The feature is useful, I agree.  The problem is that - as defined -
the server needs to guess something about the times on the client in
order to implement this reliably.

Relying on clock synchronization is not realistic.  Even in controlled
environments, errors are commonplace.

Even the simple case shows a problem:
  a: client sends request
  b: server receives request
  c: time passes
  d: server responds to request
  e: client receives response

You require that the time be a measure of a->e.  The server has no way
to determine what that time is.

An alternative would be to make the requirement apply to b->d.  That
is something that the server has direct control over.  The client then
gains a little extra work, but at least they are in a position to
measure a->b + d->e.  In any case, with low or predictable latency, I
doubt that the addition of a->b + d->e will have any significant
impact on whether the information is useful to the client.  Especially
given that times are expressed in seconds, not microseconds.
Received on Friday, 5 October 2012 18:12:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:07 UTC