On Mon, 14 Jul 2003, Jan Luehe wrote: > >>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. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
