I've found what I believe is a bug in the 2.0.4 connector for IIS that
prevents it from handling a POST with a transfer encoding of "chunked"
properly. I did some searching across the bug database and couldn't find a
direct hit on this issue, and had no luck on multiple googles either. This
is the first time I've been in this code, so would love help/info from
anyone that has worked with this source before with finishing this "chase"
so I can submit a patch to any interested committer.
My test case that causes the failure consists of a 56,662 byte text/xml
POST with chunked encoding that gets passed to the Tomcat servlet as a 0
byte request with all the valid headers including the chunked transfer
encoding one. I downloaded the 2.0.4 source and built a version of
isapi_redirector2.dll with some extra logging messages that I added for
diagnostics. The first issue that popped out is in module
jk_service_iis.c. Method jk2_service_iis_initService initializes the
jk_ws_service_t structure for my chunked request, but the "is_chunked"
flag in that structure never gets set to 1. This causes the chunked
content to be skipped in later code as the content length is -1 which
causes 0 bytes to be read and passed to Tomcat. I found code in various
places in multiple modules that rely on this flag being set, but I couldn't
find anywhere that actually sets it. So then I added these two lines at
line 391 of module jk_service_iis.c which is in method
jk2_service_iis_initService) :
if (s->content_length == -1)
s->is_chunked = 1;
This version read all the content from the incoming POST. Unfortunately I
have more chasing to do yet because the data that gets passed on to Tomcat
from the filter includes my entire payload of 56,662 bytes, followed by
repeating junk for a total length of 57302. The trace shows it read too
many bytes:
[Fri Sep 10 12:43:21 2004] (debug ) [jk_service_iis.c (216)]
jk_ws_service_t::read actually readed 0 from already 57302 of total -1
bytes
57302 = 7 blocks of 8186 bytes each. 8186 is the number of bytes read by
the filter in each block from the chunked POST. So there's still some
issue left to get it to properly handle the end of the message that I'm
still chasing when the message length is not an exact multiple of 8186.
Once I have the end-of-chunked-message-byte-count issue chased and have a
final patch to propose, I'll post again. But I'd love to hear from anyone
that's familiar with this code to get input on whether this patch is valid,
whether you feel I'm heading in a decent direction, whether someone else
has already worked this and I just haven't seen it, etc.
Thanks in advance for any info/tips.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
