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]

Reply via email to