Re: p6: maximum delta-seconds of 2147483648

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

On 11/12/13 2:44 AM, Roy T. Fielding wrote:
> 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 Wednesday, 13 November 2013 16:59:52 UTC