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

Re: p6: maximum delta-seconds of 2147483648

From: Roy T. Fielding <fielding@gbiv.com>
Date: Wed, 13 Nov 2013 10:43:34 -0800
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <5179EE99-97C0-47ED-B251-75E9C897A49A@gbiv.com>
To: Eliot Lear <lear@cisco.com>
On Nov 13, 2013, at 8:59 AM, Eliot Lear wrote:

> Roy,
> 
> My only issue with your proposed change is that we don't know what we
> don't know.  There are quite a lot of browsers in phones of all sorts
> and maybe other things that we haven't really tested.  It's a bit of a
> gamble to remove the MUST NOT, and I wonder if there really is any
> reason to do so.  Can we simply declare 68 years to be BIGNUM for
> purposes of caching?
> 
> Eliot

That's a good concern, but what does a requirement on senders do
for them?  The recipient parser is going to have to expect numbers
larger than 2^31, because they can't trust senders regardless, and
the remaining requirement (to treat overflow as either 2147483648
or INT_MAX) is intended to allow any device to handle this situation
properly.  That is, unlike the existing text, which requires overflow
be handled as 2147483648 even if the device is limited to 2^31-1.

BTW, the reason for 2^31 seems to be because the value is unsigned.
The concern was for overflow after arithmetic operations on Age, so
maybe I should point that out in the spec.

Yes, it is fair to say that 68 years is far beyond the realm for
delta-seconds, since it is relative to the time of receipt.
I don't think there is any confusion about 68 years being too long
for caching (most limit to one year or 10 years, regardless).

I am concerned that we have a MUST NOT in the spec that most people
simply ignore.  Some of these implementations probably assumed
that a time_t is always 32 bits, back in 1995-97; I haven't
found a sender of delta-seconds that checks for >= 2147483648.

....Roy
Received on Wednesday, 13 November 2013 18:43:52 UTC

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