Re: p6: maximum delta-seconds of 2147483648

On Fri, Nov 15, 2013 at 12:52:52AM -0800, Roy T. Fielding wrote:
> On Nov 15, 2013, at 12:38 AM, Julian Reschke wrote:
> >> Probably that Roy's right. After all, if this is a specific value
> >> then it makes sense to warn the developer about the fact he might
> >> need to read the man or use strcmp(!).
> > 
> > But this is true for parsing Content-Length as well, for instance. Do we need to state it there as well?
> 
> Oh, hell no ... we are only doing this for backwards compatibility
> with a silly magic number that should never have been discussed in
> the first place.  Protocols should never tell people how to program.
> 
> The sole purpose of the original text was to avoid overflows being
> treated as negative numbers during Age calculations, and a sane
> description would have simply said that (as did Jeff's original draft).
> A specific number was suggested by committee, over-specification
> commenced, and then it was rearranged into a generic section for
> delta-seconds. Murphy's law at work.

Which is why I don't like the fact that we don't suggest at least a
little bit of typing in the specs. I faced the issue several times
in the past. Content-length being to short as a 32-bit quantity for
people retrieving a DVD image.... Then my chunk parser that was
optimized for dealing with up to 7 hex digits once faced a case of
an application buffering and sending chunks larger than 256 MB!

It's probably too late for this standard to recommend anything, but
it would be nice in the future to recommend sizes to meet to ensure
interoperability over the internet.

Willy

Received on Saturday, 16 November 2013 07:51:19 UTC