It can also be useful if you have a client that doesn't support "chunked encoding" - which is probably true for a _lot_ of scripting tools. If there is any other way to have the response not use chunked encoding, then I agree this is not needed.
Do we still support HTTP/1.0 or some request header to disable the
encoding?
AFAIK, the HTTP/1.0 support for Tomcat-Coyote-Standalone is nearly identical to Apache/httpd.
I noticed that if I send a request specifying HTTP/1.0 as the protocol version, and the response exceeds the output buffer, TC returns an HTTP/1.1 response with neither a "Content-Length" nor a "Transfer-Encoding: chunked" header.
I would have expected it to include a "Content-Length" header. Would you agree?
It, umh, can't do that for dynamic content without buffering the whole response since it doesn't know how long it is.
Hence the main reason for chunked encoding and the requirement HTTP/1.1 clients support it.
Any HTTP/1.1 client must support chunked encoding, if not then it is broken and really don't need to be taken into account. If someone doesn't want to support chunked encoding, they shouldn't be making HTTP/1.1 requests.
just for the record, and I'll shut up after this.
What you are saying is correct, but does not address the specific scenario I was testing. If you read my email again, you'll notice that my client was sending an HTTP/1.*0* request.
What I was trying to test is if chunked encoding can be turned off if the client pretends to only support HTTP/1.0, since chunked encoding is a feature of HTTP/1.1.
Remy has answered my question.
Jan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
