p6: maximum delta-seconds of 2147483648

This question was raised as part of issue #512

  http://trac.tools.ietf.org/wg/httpbis/trac/ticket/512

and discussed during the WG meeting in Vancouver.

> In Section 1.2.1:
> 
>> "If a cache receives a delta-seconds value larger than the largest positive integer it can represent, or if any of its subsequent calculations overflows, the cache MUST consider the value to be 2147483648 (2^31). A recipient parsing a delta-seconds value MUST use an arithmetic type of at least 31 bits of range, and a sender MUST NOT generate delta-seconds with a value greater than 2147483648."
>> 
> Shouldn't the largest value be 2147483647 (see MAX_INT)?

Much of the discussion was around why this particular number, and
whether it is a mistaken 32bit INT_MAX (off by one) or some form of NaN?

This number was apparently added to the description of the Age header
field by Jeff Mogul, around March 1996, as a substitute for infinity.
68 years is a pretty long time, so that's not surprising.  The odd
juxtaposition with the requirement on "31 bits of range" is what
makes people believe it is an error.

Mark says that the conclusion at the Vancouver meeting is that we
would explain this number and not change it in the protocol, out of
concern that changing it might cause an interop issue.  Hence, he
added a note of

   Note that this value (2147483648) might cause implementation issues on some
   platforms (in particular, those that represent MAX_INT as
   2<x:sup>31</x:sup>-1), and therefore ought to be handled carefullly.

IMO, the existing requirements are either not testable in the protocol
(the internal arithmetic type) or not implemented in practice.

I would like to replace them with

   A recipient parsing a delta-seconds value ought to use an
   arithmetic type of at least 32 bits of signed integer range.
   If a cache receives a delta-seconds value larger than the largest
   positive integer it can represent, or if any of its subsequent
   calculations overflows, the cache &MUST; consider the value to be
   either 2147483648 (2<x:sup>31</x:sup>) or the largest positive
   integer it can conveniently represent.

Note that this changes the "MUST use an arithmetic type of at least
31 bits of range" to an ought, and removes the "sender MUST NOT generate
delta-seconds with a value greater than 2147483648" requirement.
I did some more digging and have not been able to find a server that
actually implements the latter 2147483648 requirement.  The closest
I have come is this mention of IE9's treatment of received values:

http://blogs.msdn.com/b/ie/archive/2010/07/14/caching-improvements-in-internet-explorer-9.aspx

Apache httpd, nginx, and IIS allow any value to be sent that would
fit within a 64bit time_t.  I am not concerned about ever triggering
these requirements in real life, since 68 years is an absurdly long
period for a delta-seconds.

Would anyone be opposed to making these changes now in response to
the last call comment?

....Roy

Received on Tuesday, 12 November 2013 10:44:36 UTC