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

Re: p6: maximum delta-seconds of 2147483648

From: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 14 Nov 2013 13:31:55 +0100
Message-ID: <5284C2BB.7030206@gmx.de>
To: "Roy T. Fielding" <fielding@gbiv.com>, Eliot Lear <lear@cisco.com>
CC: HTTP Working Group <ietf-http-wg@w3.org>
On 2013-11-13 19:43, Roy T. Fielding wrote:
> 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


This is the only current issue that holds up draft -25. If no further 
information comes up, I'll apply this change (unless Roy beats me to 
it), and submit -25 over the weekend.

Best regards, Julian
Received on Thursday, 14 November 2013 12:32:27 UTC

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