> > > Here's my problem. When the request is to a servlet (static apache > files > > and JSPs through mod_jk are fine) in the form of a GET, instead of > > sending a Content-Length response header, I get a Transfer-Encoding: > > chunked header > > I'd like to know: > > 1) What are the causes of either Tomcat (or Apache is it?) enabling > > chunking on the connection? > > Tomcat, probably, since you're talking about a servlet-created > response. > And it's not chunking the connection but transferring the response body > chunked. >
The only thing that makes me question this, is that if I query the servlet directly on port 8080 instead of through mod_jk/ajp, it doesn't get chunked. Well, I don’t get a transfer-encoding header I should say. But I don’t get a content length through there either. > If at the time the response headers are sent the size of the response > body is already known (for example, if it's just the contents of a > file), it's easy to send a Content-Length response header. > OTOH, how big the output of a servlet will be is generally not known > before the servlet has finished. If you want to send a Content-Length > header anyway, I see two (well, really only one) alternatives: > 1. Cache the complete servlet output and count the bytes - which isn't > very practical.[1] agreed > 2. Don't send a Content-Length header. > Alternative 2. creates another problem: > With HTTP/1.0 a client can quite reliably determine when the entire > response body is transferred, even if no content-length header is sent: > when the server closes the underlying TCP connection. > With HTTP/1.1 this isn't the case any more since the TCP connection may > be left open to be used to transfer additional requests/responses > (keep-alive). To enable the client to determine when the entire > response > was transmitted, you'll have to transfer it chunked. > Well, to accomplish #2 I wouldn't have to do anything, since this is my problem :-) I don’t do keep-alives on apache, FWIW. I have is specifically turned off. > > 2) How do I get a Content-Length reponse header instead? Do I need to > > downgrade the client to HTTP/1.0 or is there another way? > > What's the point in caching dynamically created responses? > While they are dynamically created (from database and other sources), the content doesn't change on every request, so internally we set the cache-control to something like 300 seconds, or whatever we deem appropriate based on how constant the content stays. And the same goes for our CDN, which is a Content Delivery Network (limelight, akamai, etc..). With requests in the millions per day, we're talking a substantial bandwidth and load savings if we can cache this content at the CDN. But according to the CDN, without a content-length header, the caching won't happen. I wonder if I downgrade the connection to http 1.0 if it applies to every hop? The way the CDN works is that, a request is made to it by the client, if it has it in its cache, it serves it to the client, if not, it requests the file from the origin server (my web server), I'm assuming by some proxy mechanism. So if I downgrade to 1.0, will that apply to the connection from the client to the CDN, the CDN to me, or both? > > FYI, the reason I'm trying to do this is that I use a CDN, and they > > won't cache my data without the presence of a Content-Length response > > header, so my servlet data isn't getting cached at the CDN. > > What's a CDN? > > [1] Tomcat will, by default, cache some output of servlets. IIRC the > default buffer size is 8k. So, if your servlet creates output of no > more > then 8k, a Content-Length header will be sent. Otherwise chunked > encoding will be used. > This might be the reason why you see Content-Length headers from your > JSPs - their output is probably small enough. I tested with a >8K jsp and did get it chunked. Do you happen to know the parameter for changing the buffer size? Perhaps I can increase it to a number representing the largest length of my servlet content. Which isn't too big, maybe 20K. Thanx, -Tony
