On 12.06.2009 17:48, Anthony J. Biacco wrote: >> Rainer Jung: >> >>> On 12.06.2009 10:43, Markus Schönhaber wrote: >>>> No, it's not strange at all. If the length of the response body is >> not >>>> known when the response headers are sent, you obviously can't add a >>>> Content-Length header. That has nothing to do with the HTTP version >> used. >>> ... true, but an HTTP/1.0 client can also just read until the >> connection >>> is closed. That's another way of handling content of unknown length. >> Yes, that's exactly what I was pointing at. >> IOW, using HTTP/1.0 doesn't magically add a Content-Length header (as >> the OP seems to have expected) in situations where the size of the > > I was 1/2 hoping it would add the content-length header and 1/2 hoping it'd > just stop chunking. Getting both was a pipe dream :-) > >> response body isn't known beforehand. The difference between HTTP/1.1 >> and HTTP/1.0 wrt this situation is simply what has to be done to enable >> the client to know about the end of transmission. While 1.1 will need >> to >> transfer the body chunked (at least with keep-alive), 1.0 doesn't know >> nor care about chunked because the server will close the underlying TCP >> connection when the response is completely sent. > > Yes, and I think that with keep-alive off, apache should not chunk (or at > least give the option to) since it knows I am closing the connection right > after the response is finished.
I suggest using the environment variables downgrade-1.0 and nokeepalive, maybe also no-gzip. You can set them via mod_rewrite dynamically. So you can support keep-alive for "normal" requests and the other configuration for the CDN. Of course this will only help, if you can determine a CDN request, e.g. via the user-agent, IP or similar. Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
