RE: Large content size value

Paul Leach said:
> The following already existing errors would be appropriate when a server
> gets an integer larger than it can handle:
>
> 413 Request Entity Too Large
> 501 Not Implemented
>
> I think these can handle any interop problems with same.

Deja vous; you forgot the client again (behavior is unspec'd).

Also, IHMO, failure isn't interop; it's the last resort when you *can't*
interop. A Windows+NTFS system can totally handle a 4+GiB file; the fact
that a client that (should) be HTTP/1.1 compatible can't handle a file of
that size says "interoperability problem" to me. Granted, it's not
implementing the spec, but the spec says you need to have infinitely long
numbers or fail (which is flat-out unreasonable).

A better spec would enforce what Apache does: the server/client needs to
support transferring files as large as the OS's filesystem will support
("infinitely long with a reasonable cap," if you will). This is sane,
because if a client can't download (or a server can't serve) a file bigger
than the FS can handle, it doesn't really matter -- the file wouldn't be
able to exist on the filesystem anyway. That's an OS-level interop problem,
then, as opposed to a protocol-level one. Making a friendly warning a SHOULD
level requirement would be kind of nice, too, so that the end-users
understand *why* they can't download certain files.

A cool spec (but potentially one that's too fancy) might allow for word-size
negotiation, so an 8-bit computer on a 32-bit filesystem could be more
efficient with its buffer management code (and have to do 32-bit ops only
when it came time to flush the buffers). This would allow for a whole other
host of problems (e.g., chunked transfers that are larger than the
filesystem can handle, with the error showing up -very- late in the game),
but would solve this particular issue.

<snip>

I admit and concur that the best we can probably do right now is fail;
however, the spec needs to give specifics on *how* to fail (especially for
clients, and especially regarding connection handling). Guidance (not
necessarily requirements) regarding sane max lengths (e.g., using an integer
size that can represent the maximum size supported by the underlying OS/FS)
would be nice, too.


Thanks,

-- Travis

Received on Thursday, 4 January 2007 22:01:41 UTC