This has been given the bug # http://issues.apache.org/bugzilla/show_bug.cgi?id=43478
"Rainer Jung" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Hi Lary, > > Larry Reisler wrote: >> Thanks for your reply. There is a holiday here right now, so I'm not >> sure if I will be able to get to file the Bugzilla issue before the >> holiday break. > > Maybe this time we are faster than our request ticketing ... > >> We tried a few different versions of mod_jk (the early ones had other >> issues), but all the latest ones showed the problem. We are >> currently using mod_jk 1.2.25. >> >> In desperation, I was able to create a patch to mod_jk that seems to >> prevent the symptom from occurring. Here is the diff for the file >> jk_ajp_common.c: 1742,1751d1741 > > < // Removing extra flush buffer if we do not need it. > < if (headeratclient == JK_FALSE) { > < int code = (int)jk_b_pget_byte(op->reply,0); > < unsigned int len = (unsigned int)jk_b_pget_int(op->reply,1); > < if ((code == JK_AJP13_SEND_BODY_CHUNK) && (len == 0)) { > < jk_log(l, JK_LOG_DEBUG, "Received flushbuffer -- ignoring"); > < continue; > < } > < } > < > > I'm a little reluctant to use your approach. It should work, but the > peeking for the message code and length does not belong into the get reply > function. The best place for the patch would be in the callback handling, > but there we don't know, if we already received the headers. > > So either we pass some additional info to the callback handling (status > info about the request processing stage), or we prevent the flushing > later. I decided to move an already existing flag "response_started" from > the web server private data to the public service struct and use it > inside the callback handler. > > This patch was committted > (http://svn.apache.org/viewvc?view=rev&revision=579349). You can find a > simple download form of it under > > http://people.apache.org/~rjung/mod_jk-dev/patches/flush-before-header.patch > > The patch looks lengthy, but in fact did only small changes. > > It would be helpful, if you could try it with your reproduction scenario. > > Regards, > > Rainer > > --------------------------------------------------------------------- > To start a new topic, e-mail: users@tomcat.apache.org > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
