Anthony J. Biacco wrote:
No dice. I tried a bufferSize of 16384 and an 11K response still got chunked.
Even tried using packetSize and max_packet_size (mod_jk).
I think we need Rainer here.
In the meantime, just as an intellectual exercise, let's take the
problem from the other end.
A client gets a page (directly or not) from your site.
In that page, is a link to a javascript.
I understand that this link points to the CDN instead of your site.
The client thus requests this javascript from the CDN.
The CDN looks in their cache if they have it.
If they do, they serve it.
If not, they issue a request to your site for it, and your site delivers
it to the CDN. The CDN anyway delivers it to the client.
If the response of your site to the CDN is not chunked, they cache it,
otherwise they don't.
Presumably, you know when a request for such a javascript comes from the
CDN (as opposed to from a client directly), and you know exactly what
such a request looks like (I mean, there is pattern to these URLs).
Since you are mentioning mod_jk, I also presume that the CDN sends its
request to an Apache httpd front-end on your site, which in turn proxies
it to Tomcat via mod_jk.
And it seems to be AJP/mod_jk which (sometimes) chunks the content prior
to returning it to Apache.
It seems to me that in such a case, one should be able to do something
at your Apache httpd front-end level, to "de-chunk" this response and
re-create a content-length header, prior to returning it to the CDN.
(As per your earlier message, we're not talking about megabyte
responses, we're talking about 20 Kb or so).
Maybe Apache httpd could even cache it, which I guess may ensure that it
is returned non-chunked to the CDN.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
