RE: Use of 1*DIGIT

There will be lots of cases where the syntax says something is legal,
but the semantics or an implementation say it isn't. This seems like one
of those, and unless there isn't an appropriate 5xx series error code
for any particular case, I don't think said case would be a problem.

In this case, a 64 bit implementation could handle lengths that a 32
versions couldn't. 

I don't see that we need to note every place in the syntax where this
problem could arise, just like we don't need to be explicit that
implementers shouldn't code buffer overflows.

-----Original Message-----
From: ietf-http-wg-request@w3.org [mailto:ietf-http-wg-request@w3.org]
On Behalf Of Travis Snoozy (Volt)
Sent: Thursday, December 21, 2006 12:22 PM
To: ietf-http-wg@w3.org
Subject: Use of 1*DIGIT


There are many instances in the spec that have 1*DIGIT (and one instance
of 1*HEX), where the number needs to be parsed for, e.g., a length. This
practically forces an implementation to choose between using bignums
everywhere (in case, e.g., they start talking to an implementation with
a bigger native word size), or to assume that everybody can and will be
able to use a word size of some fixed amount.

If I were the betting type, I'd say that implementations probably
operate on the latter more than they do the former. In either case, how
an implementation is supposed to deal with too-large numbers is not
specified. Content-Length, Content-Range, Byte-Ranges, Age,
Cache-Control, Retry-After, and the chunked transfer encoding are
probably all susceptible to mischief if you place values past the 4Gi
mark into them (assuming a 32-bit world and a general lack of oversize
checks, of course).

Anyone know how Apache handles this, off the top of their heads? Squid?
Other servers? Clients?


Thanks,

-- Travis

Received on Thursday, 21 December 2006 23:22:31 UTC