I send this to dev list, but received no response: http://mail-archives.apache.org/mod_mbox/tomcat-dev/200809.mbox/<b61a4e530809081550u242eacaapd5fa7e37c9c3d222@mail.gmail.com> When mod_jk sends a 401, it is not sending an EOS (sends a FLUSH). This causes a module that buffers the response (for example, the mod_security2 module which I maintain) to not realize the full page has been sent. This causes httpd to issue the default 401 response, which does not include the WWW-Authenticate header and thus no prompt for credentials. I am able to work around this, but I am confused as to why mod_jk does not send an EOS. Is it a bug? If not, then why and how can a module know mod_jk is done sending data (other than looking at C-L header)? Some more info can be found in the ModSecurity issue tracker: https://www.modsecurity.org/tracker/browse/MODSEC-16 -B
Looking at reported issue on modsecurity.org site, it looks like you guys are trying 1.2.5 version of mod_jk. I suppose the same happening with latest mod_jk (1.2.26) ? Will you be able to test the current SVN build, cause I plan to add the call to ap_finalize_request_protocol on JK_AJP13_END_RESPONSE message. This API creates the EOS bucket I suspect you are pursuing.
Sorry, that was a typo on my part on the modsec issue. It was mod_jk version 1.2.25 (not 1.2.5). That just happened to be the debian packaged version. The problem was also reported on the tomcat-users list with 1.2.24, 1.2.25 and 1.2.26, so I did not test with 1.2.26 after duplicating with 1.2.25. I will test with SVN version when you have a fix. Thanks. tomcat-users list report: http://mail-archives.apache.org/mod_mbox/tomcat-users/200809.mbox/%3C215811.93737.qm@web55203.mail.re4.yahoo.com%3E
Fix is already in the SVN. It calls the ap_finalize_request_protocol on JK_AJP13_END_RESPONSE message, so please tell us if that resolves the issue.
The SVN version does indeed fix this problem. However, I noticed it now sends FLUSH followed by EOS. In my bugzilla searches I came across Bug 26446 that is rather old, but not sure if that may be triggered by this change. And just FYI, apxs on my system was including the -Wl, prefix on the LDFLAGS query which caused the SVN version of configure to add it twice (ie -Wl,-Wl,foo). I had to do this to get it to build: Index: configure.in =================================================================== --- configure.in (revision 695980) +++ configure.in (working copy) @@ -109,7 +109,7 @@ dnl sed magic needed to prepend each token with "-Wl," s.t. libtool dnl detects those arguments correctly as ld flags. dnl Double square brackets needed, because single ones will be removed by autoconf. - APXSLDFLAGS="`$APXS -q LDFLAGS_SHLIB | $SED -e 's/\([[^ ]]*\)/-Wl,\1/g'`" + APXSLDFLAGS="`$APXS -q LDFLAGS_SHLIB | $SED -e 's/\(-Wl,\)\?\([[^ ]]\+\)/-Wl,\2/g'`" else WEBSERVER="apache-2.0" APRINCLUDEDIR="" @@ -124,7 +124,7 @@ dnl sed magic needed to prepend each token with "-Wl," s.t. libtool dnl detects those arguments correctly as ld flags. dnl Double square brackets needed, because single ones will be removed by autoconf. - APXSLDFLAGS="`$APXS -q LDFLAGS | $SED -e 's/\([[^ ]]*\)/-Wl,\1/g'`" + APXSLDFLAGS="`$APXS -q LDFLAGS | $SED -e 's/\(-Wl,\)\?\([[^ ]]\+\)/-Wl,\2/g'`" APACHE_CONFIG_VARS="`${APXS} -q exp_installbuilddir`/config_vars.mk" LIBTOOL=`$APXS -q LIBTOOL` fi @@ -534,7 +534,7 @@ fi dnl the APXSLDFLAGS is given to the linker (for APRVARS). if ${TEST} -n "${LDFLAGS}" ; then - TMPLDFLAGS="`${ECHO} ${LDFLAGS} | $SED -e 's/\([[^ ]]*\)/-Wl,\1/g'`" + TMPLDFLAGS="`${ECHO} ${LDFLAGS} | $SED -e 's/\(-Wl,\)\?\([[^ ]]\+\)/-Wl,\2/g'`" APXSLDFLAGS="${APXSLDFLAGS} ${TMPLDFLAGS}" fi AC_SUBST(APXSCFLAGS)
Concerning the unrelated configure problem: That should be fixed in SVN trunk now as well (revision 695003). I used a slightly different pattern though, to make sure we only respect -Wl, in front of a token. The pattern has been tested with Solaris, AIX and Linux sed, though I still need to check the autoconf generated configure.
OK. I have modified the code so that for last packet only the EOS is send instead flush+eos. This should now behave like mod_proxy_ajp