On 10.10.2009 12:32, Sam Crawford wrote: > Hello, > > I've got a simple web application deployed, and am accessing it via a > basic mod_jk load balancer setup. The web application on the J2EE app > server is returning a fixed "Content-Length: 84" header (it's just a > HelloWorld page for testing purposes), but when I access the same > application via the mod_jk web server I'm getting *both* a > "Content-Length: 84" header and a "Transfer-Encoding: Chunked" header > (see bottom of mail). I'm pretty certain that these headers are > mutually exclusive, no? > > I'm struggling to understand where this Transfer-Encoding header is > being created, and why! It's certainly not the backend web > application. Its presence is causing problems for upstream proxy > servers, which assume the body will be chunked, but it's not - so we > get back mangled HTML. > > I'm running the following setup: > > * Backend J2EE app server: JBoss 4.2.3 with a simple HelloWorld app > deployed under /test > * Sun ONE 7.0u6 (stock configuration) with mod_jk 1.2.28 > > The mod_jk workers.properties is shown below: > > worker.list=jkstatus,PORTALMY > worker.jkstatus.type=status > worker.basic.type=ajp13 > worker.basic.connection_pool_timeout=600 > worker.basic.socket_keepalive=1 > worker.basic.lbfactor=1 > worker.PORTALMY.balance_workers=PORTALMY0,PORTALMY1 > worker.PORTALMY.type=lb > worker.PORTALMY.reference=worker.basic > worker.PORTALMY0.host=appserver1.company.com > worker.PORTALMY1.host=appserver2.company.com > worker.PORTALMY0.port=8009 > worker.PORTALMY1.port=8009 > > Now, I should add that I can't be certain whether it's SunONE or > mod_jk that's inserting this header. I would have thought that if the > Content-Length header was available, then there should be no need to > insert the "Transfer-Encoding: Chunked" header - as the length of the > body is already known before it's even begun.
mod_jk doesn't add any headers. It could be, that mod_jk unintentionally triggers adding the header by the SunONE web server. If you can easily reproduce in a test scenario, I would first run a test request using a log level of trace for mod_jk. With this high log level, you will find messages in the mod_jk log, which contain each header it received from the backend via the AJP13 protocol, so you can make sure, that the Transfer-Encoding is definitely not coming from JBoss. Unfortunately the SunONE variant of mod_jk is the least often used one and therefore it's the one where bugs are most likely. But I don't remember someone reporting the same problem, that you see. Regards, Rainer > # curl -v http://webserver1.company.com:28080/test/ > * About to connect() to webserver1.company.com port 28080 > * Trying 10.1.2.3... * connected > * Connected to webserver1.company.com (10.1.2.3) port 28080 >> GET /test/ HTTP/1.1 > User-Agent: curl/7.12.1 (x86_64-redhat-linux-gnu) libcurl/7.12.1 > OpenSSL/0.9.7a zlib/1.2.1.2 libidn/0.5.6 > Pragma: no-cache > Accept: */* > Host: webserver1.company.com:28080 > > < HTTP/1.1 200 OK > < Server: Sun-Java-System-Web-Server/7.0 > < Date: Sat, 10 Oct 2009 10:26:57 GMT > < X-Powered-By: Servlet 2.4; JBoss-4.2.3.GA (build: > SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0 > < Set-Cookie: JSESSIONID=B1E6FD1C007FFDE2939796018AB4CB27; Path=/ > < Content-Type: text/html;charset=ISO-8859-1 > < Content-Length: 84 > < Transfer-encoding: chunked > > > <html> > <head><title>Hello World</title></head> > > <body> > PROXY MY0 > </body> > </html> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
