At the risk of bringing this thread back on topic, I still haven't found a solution to the problem. I suspect that mod_jk may be setting the Content-Length header in a case that SunOne does not expect (SunOne is case-sensitive to headers in it's NSAPI modules!). I note the following sentence from http://docsun.cites.uiuc.edu/sun_docs/C/solaris_9/SUNWadoc/SONEAPPSVRNSAPI/dnhttp.html#24970
"Response length determination: If the buffering layer cannot determine the length of the response, it uses HTTP 1.1 chunked encoding instead of the content-length header to convey the delineation information. If the client only understands HTTP 1.0, the server must close the connection to indicate the end of the response." Delving into the mod_jk source is certainly an option, but I'm concerned about other incompatibilities we may stumble across later (particularly as this seems an uncommon combination to run nowadays). For the moment we've just reverted to using the SunOne 7.0 stock reverse proxy. This seems to fulfill our immediate needs, and we can perhaps revisit mod_jk later. Thanks for the tips so far, Sam --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
