- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 12 Nov 2013 02:44:13 -0800
- To: HTTP Working Group <ietf-http-wg@w3.org>

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