tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Luehe <Jan.Lu...@Sun.COM>
Subject Re: [5.0] [PROPOSAL] Make output buffer size limit configurable
Date Tue, 15 Jul 2003 19:13:23 GMT

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message