> > > - the first-choice solution would be to have the CDN fix their > software, > > or select another CDN which can handle chunked content. > > I agree. >
And you know how easy that will be :-) > > - the second-best would be : > > (presuming the OP knows at some point the real size of the data chunk > > that has to be sent back.) > > Write a servlet which obtains the data, then uses > > response.setContentLength(nnn), then does a > > response.getWriter/getOutputStream, then writes the data there. Yes ? > > > > - if the above is not acceptable/practical, then another solution > would > > be to intercept and buffer the full response somewhere, calculate its > > size, and then forward it unchunked, preceded by a proper Content- > Length > > header. > > Yes. Yes, that's probably possible, I just don’t know how it would affect the load-time of the app or any timeouts, since now I'd be not writing any data until the very end of the servlet when all the output is collected, sized, and then shipped out. > I just noticed that the OP said he was going to experiment with setting > the bufferSize attribute of the AJP Connector to a higher value. > That might indeed be the easiest workaround - provided the output his > servlets/JSPs generate do not exceed the buffer size - and this > attribute really does what I understand it does. > Using ServletResponse#setBufferSize, which I already mentioned, might > work too - on an per servlet level. But if increasing the value of the > bufferSize attribute of the Connector works, it's much less hassle. > Yeah, the bufferSize attribute in the AJP connector (and HTTP connector) didn't help. I set it to 16384, and a 12K response still got chunked. I haven't tried the servlet method, mostly because I'm not a java programmer. I could figure it out, but I'd much rather have our dev. team handle it when I get them a free couple minutes. -Tony
