Re: HTTPbis -10 drafts published

On 14.07.2010 09:28, Willy Tarreau wrote:
> Hi,
>
> On Tue, Jul 13, 2010 at 08:18:10AM +0200, Julian Reschke wrote:
>> <http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-10#appendix-D.11>
>
> In this one we would need to add a bit of clarifications about the
> value domains that may be used for integers. I have identified 2
> situations where we can encounter integer overflows, with either
> just impossibility to transfer data, or more important, security
> issues :
>
> - 6.2.1. Chunked Transfer Coding
>    chunk-size     = 1*HEXDIG
>
> - 9.2. Content-Length
>    Content-Length-v = 1*DIGIT
>
> In both cases, we don't indicate any minimal size requirement.
> It looks like both values are generally assumed to be 31 or 32
> bits depending on signedness. BTW, I've once been unable to

How did you come to that conclusion?

> download a DVD image from a site because the announced content
> length was wrong due to integer overflow. I don't remember what
> server it was though :-/

That's a server bug. If the content length exceeds what the server can 
express in Content-Length, it should switch to chunked encoding.

> I think it is difficult to ask every implementation to support
> at least XXX bits, but we should at least add as a strict
> requirement that any agent along the chain must detect integer
> overflows when parsing or printing these values, and must abort
> processing if this happens.

I think that requirement is already implicit; if you can't parse a 
length, don't pretend you can.

> ...
> I'm just realizing something else. Some implementers might be
> tempted to use strtoul() or equivalent to reliably parse these
> values and detect errors. The definition of those values with
> 1*DIGIT suggests that leading zeroes are allowed. Special care

They are.

> must be taken to ensure that the decoding is forced to base 10,
> otherwise a number such as 0123 may be automatically interpreted
> as the octal value for the decimal 83.

That's true, but again, that's a quality of implementation issue.

We've had similar discussions before: it's not clear that considerations 
like these belong into the actual HTTP spec. On the other hand, a 
separate document discussing issues like these could certainly be 
written (IETF Informational, or even somewhere else?).

Best regards, Julian

Received on Wednesday, 14 July 2010 07:42:51 UTC