RE: Use of 1*DIGIT

Paul Leach said:
> 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.

A 5xx would work fine for dealing with a Request that the server can't handle (given that the implementation even realizes the error is there), but it doesn't help in the case when a client gets a Response it can't handle.

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

Yep. And a 64 bit server could give a 32 bit client a headache if that client happens to request a file over 4GiB (like a DVD image) and the server tries to cram it down the pipe with a single Content-Length. Same deal down the line for 16 or 8 bit processors. Again, this means that everyone either has to use bignums (which is unlikely), or attempt interop in some unspecified manner (also unlikely), or abort gracefully (reasonable), or be broken but work in most cases (likely).

Ideally, the transfer problem would be solved by allowing the client and server to negotiate word sizes. This would allow any oversized to be sent with a chunked transfer encoding (with each chunk at or below the word size for the receiver) instead of with Content-Length. It would also be useful in ensuring that chunked entities have chunk sizes that are easily digestible by the recipient. It's also forwards compatible, so if we ever decide we need 100EiB files on 128-bit computers, everything will still play nice with an old, clunky 32-bit machine. (Note that this does _not_ address the security issue with maliciously constructed messages, it merely facilitates interop in the non-malicious cases.)

Clearly that's not going to happen in HTTP/1.1, But I _do_ think that the spec should offer some guidance on the best way to fail or recover, instead of just being mum on the matter.

> 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.

Well, given the number of buffer overflows and integer overflows in the world, I'd say that it sure might be helpful.

Tossing a note in section 15 would be good enough for me. There's a risk in parsing numbers that are bigger than the application wants to deal with, clients SHOULD do this (probably abort, and user-agents give a message), and servers SHOULD do that (probably return a 5xx code).


-- Travis

Received on Friday, 22 December 2006 00:19:09 UTC