Thanks Rainer. I've done as you suggested and enabled trace logging on mod_jk. The output doesn't show any Transfer-Encoding header, which leads me to believe that your suggestion that mod_jk is inadvertently triggering SunONE into inserting this header is correct. A portion of the log output is copied below.
I'll keep investigating, but suspect I may have to switch to using the stock SunONE reverse proxy (which doesn't seem to exhibit this issue). Thanks, Sam [Sat Oct 10 20:52:12.924 2009] [25246:3641224096] [trace] ajp_process_callback::jk_ajp_common.c (1702): enter [Sat Oct 10 20:52:12.924 2009] [25246:3641224096] [trace] ajp_unmarshal_response::jk_ajp_common.c (642): enter [Sat Oct 10 20:52:12.924 2009] [25246:3641224096] [debug] ajp_unmarshal_response::jk_ajp_common.c (660): status = 200 [Sat Oct 10 20:52:12.924 2009] [25246:3641224096] [debug] ajp_unmarshal_response::jk_ajp_common.c (667): Number of headers is = 3 [Sat Oct 10 20:52:12.924 2009] [25246:3641224096] [debug] ajp_unmarshal_response::jk_ajp_common.c (723): Header[0] [X-Powered-By] = [Servlet 2.4; JBoss-4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)/JBossWeb-2.0] [Sat Oct 10 20:52:12.924 2009] [25246:3641224096] [debug] ajp_unmarshal_response::jk_ajp_common.c (723): Header[1] [Content-Type] = [text/html;charset=ISO-8859-1] [Sat Oct 10 20:52:12.924 2009] [25246:3641224096] [debug] ajp_unmarshal_response::jk_ajp_common.c (723): Header[2] [Content-Length] = [84] [Sat Oct 10 20:52:12.924 2009] [25246:3641224096] [trace] ajp_unmarshal_response::jk_ajp_common.c (730): exit [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [trace] ajp_connection_tcp_get_message::jk_ajp_common.c (1131): enter [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [trace] jk_tcp_socket_recvfull::jk_connect.c (807): enter [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [trace] jk_tcp_socket_recvfull::jk_connect.c (836): exit [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [trace] jk_tcp_socket_recvfull::jk_connect.c (807): enter [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [trace] jk_tcp_socket_recvfull::jk_connect.c (836): exit [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1259): received from ajp13 pos=0 len=88 max=8192 [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1259): 0000 03 00 54 0A 0A 3C 68 74 6D 6C 3E 0A 3C 68 65 61 - ..T..<html>.<hea [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1259): 0010 64 3E 3C 74 69 74 6C 65 3E 48 65 6C 6C 6F 20 57 - d><title>Hello.W [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1259): 0020 6F 72 6C 64 3C 2F 74 69 74 6C 65 3E 3C 2F 68 65 - orld</title></he [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1259): 0030 61 64 3E 0A 0A 3C 62 6F 64 79 3E 0A 50 52 4F 58 - ad>..<body>.PROX [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1259): 0040 59 20 4D 59 31 20 0A 3C 2F 62 6F 64 79 3E 0A 3C - Y.MY1..</body>.< [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [debug] ajp_connection_tcp_get_message::jk_ajp_common.c (1259): 0050 2F 68 74 6D 6C 3E 0A 00 00 00 00 00 00 00 00 00 - /html>.......... [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [trace] ajp_connection_tcp_get_message::jk_ajp_common.c (1263): exit [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [trace] ajp_process_callback::jk_ajp_common.c (1702): enter [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [trace] ajp_process_callback::jk_ajp_common.c (1871): exit [Sat Oct 10 20:52:12.925 2009] [25246:3641224096] [trace] ajp_connection_tcp_get_message::jk_ajp_common.c (1131): enter 2009/10/10 Rainer Jung <rainer.j...@kippdata.de>: > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
