Re: IPP> Chunked POST

with the availability of 413 (request too large), 411 was not made
clear to me from the specification.. it's only from working with it
for the last year that I've come to some clarity on the topic, and who
knows if that's shared with other folks.

In a previous episode Roy T. Fielding said...
:: 
:: [..]  Any server has the right to deny
:: service rather than buffer an unknown amount of data.  

 a server does not commit to an all or nothing buffering process.. it
can buffer and if the request seems to be getting too large, it may
abort with 413...

requiring attempts at chunked processing never requires commitments to
unknown amounts of material. Each chunk is labeled with a length and
the server is free to send back 413 if the length of the upcoming
chunk pushes it over a threshold of that which it is willing to
buffer.

However, I can see that under some circumstances like CGI a server
might be unwilling to continue to buffer a chunked request at some
threshold (and it must be buffered because CGI requires a
content-length) but if it had come with a c-l it could be streamed to
the CGI, so 411 would seem to convey the feeling. 

However, making that threshold 0 is ridiculous. The vast majority if
CGIs take very little input.. there are exceptions of course but
presumably they can be designed in an environment that can either
afford the buffering or done with something other than CGI 1.1 that
doesn't have the CL problem.

the 411 distinction of "you must be capable of doing chunked, but you're
never actually required to do it" is too fine of a line in my
opinion.... but that's a retrospective, there really isn't anything
that can be done about it now even if we agreed the semantics for it
needed to be stronger. (and I suspect we don't agree.. que sera sera).

-P

Received on Thursday, 19 August 1999 06:30:51 UTC