RE: Large content size value

> On a sub-32-bit processor, I certainly wouldn't want to be stuck doing 32-
> or 64-bit math unless -absolutely- necessary. I'll grant that it's much
> less
> likely for a sub-32-bit processor to have to deal with a >4GiB file.
> However, having to deal with all 32-bit numbers just because the average
> user will hit some (substantial, but minority) number of files >64KiB (on
> a
> 16-bit proc) is just cruel. Workaround logic to do a 16/32 switch isn't
> exactly a cakewalk, either (though if performance is a big concern, and
> 32-
> bit numbers are slow enough, it might happen). Likewise, an 8-bit proc
> would
> be stuck emulating 16 bits enough of the time already -- requiring 32-bits
> everywhere (especially when it's not _really_ necessary) is wasteful.
>
> I'd be interested to hear any comments from folks who run HTTP on (sub-32-
> bit) embedded processors.

That would be me... (or used to be).  Such systems are very unlikely to be
able to (or interested in) handle such large body sizes, but they don't
need to do big-integer math to discover that fact.  The parser can (and
should) recognize that the ascii value is larger than it can cope with and
cause the request or response to fail (the sooner the better).  Whether or
not they use any given existing library routine to discover this is not
important and need not be addressed by the protocol spec.

>> and it's realistic to expect implementations to check (and fail
>> gracefully) when any received protocol value exceeds its representation
>> capacity.
>
> Yes, but I think we have failed to define "graceful failure". I don't
> think
> that we'll be able to solve the transfer problem in an ideal way, but we
> also haven't defined any client behavior when the client gets a message it
> doesn't want to deal with.

Yes we have.   For a large body in a request, the server can return an
error; the client is required to abort sending the body if an error is
received.  For a large body in a response, it's not lovely, but it's well
understood - the client just closes the connection.  Since there is no
3-way handshake, that's the best that can be done.

Received on Friday, 5 January 2007 21:26:29 UTC