Re: IIS Connector and chunked encoding
>Well if you already have a patch, then it would be polite to share :).
>Anyhow you can post either to this thread or create a bugzilla #.
>Regards,
>MT.
Before I post this for real, can we talk? :-) Below is the diff of the
changes I'm testing today. I'm gonna
wait to post this as an attachment/bugzilla until after the simple testing
we're gonna do today is
done. But in the meantime It'd be good if you could review this and
suggest better ways to do
it, as I'm a total newbie to this code and what I came up in a short amount
of time feels low
on quality.
I ran into two issues in this test case. One was the is_chunked flag never
being set. The
other was once is_chunked is set, stopping the read logic when the chunked
stream has
been read so that it doesn't pass on any extra junk bytes as content.
As you can see from the diff there are two new ifs. The first one tries to
detect end-of-stream
during the read of the last 8186 byte chunk in the incoming stream.
Without this code it passes
the entire last 8186 byte block as message content, and if only part of the
block has real data,
the remainder gets repeating fragments of whatever is left in the buffer
from previous work (I have
a trace of this if it would help). I couldn't see a good way to tell
whether a true end-of-stream has
happened, so please point out any better ways if you know them and I'll
make the change.
This new if, which only applies to chunked content, works for our early
tests but I'm afraid in a
real-world slow internet test that maybe a false positive can happen with
my wimpy approach of
assuming the first short block means end-of-stream. BTW, there is code
elsewhere that already
(I think) handles the boundary condition of is_chunked==1 and the chunked
payload is an exact
multiple of 8186 bytes in length.
The second if adds the code to set is_chunked. I assume chunked encoding
when content
length is unknown. From looking at the HTTP specs I think this is a valid
assumption,
but if you think it'd be better to explicitly check for the
"Transfer-Encoding" header of "chunked"
instead of a missing content-length, lemme know.
diff -r1.30 jk_service_iis.c
227c227,232
< if ((s->content_read + *actually_read) == lpEcb->cbTotalBytes) {
---
>
> if (s->is_chunked && (*actually_read < len)) {
> s->end_of_stream = JK_TRUE;
> s->no_more_chunks = 1;
> }
> else if ((s->content_read + *actually_read) == lpEcb->cbTotalBytes) {
398a404,408
> if (s->content_length == -1) {
> env->l->jkLog(env, env->l, JK_LOG_DEBUG,
> "jk_ws_service_t::init, Unknown content length,
using chunked transfer encoding\n");
> s->is_chunked = 1;
> }
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS Connector and chunked encoding
>>Well, I wouldn't spend much time trying to fix it, cause we'll probably >>drop the jk2 altogether, and focus on jk for platforms other then >>apache 2.2. The apache 2.2 will have it's own connector inside standard >>distribution. >>So either the provided dll works or not. Of course you may do with the >>jk2 code whatever you wish, as long as you comply to the Apache 2 >>license :). >>Regards, >>MT. Thanks for the info. By the time I read your last email, I already had a patch that works for me, although I don't like it a whole lot :-) I didn't realize the long-range plan might be to go back to JK - that's good to know. Anyway, I have a patch that makes two small changes in jk_service_iis.c that together make the already existing chunked encoding code work in my test case. We're gonna do some internal testing on the changes by throwing messages of varying sizes at it tomorrow. If you have any interest in the changes made, I can send you the patch direct, or open a bugzilla and post the patch as an attachment, or some other method of your choice, just let me know. There are two new small if statements, and one of them I'm not comfortable with - if you are interested I'd love to discuss whether there's a cleaner way to do what I'm after. That's assuming of course that the point isn't moot :-) If you want to get into an in-depth discussion, I also have before, during and after debug traces in jk2.log for this particular test case. Thanks again for your time and info. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: IIS Connector and chunked encoding
>> 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" > Issue been mentioned couple of times: > http://www.apache.org/~mturk/isapi_redirector2.zip > This is 2.0.5 pre-release (if the 2.0.5 ever sees daylight :). >Regards, >MT. Thanks for the dll Mladen. I downloaded it and discovered that the build from 4/3/2004 in this zip is the same one I'm running. I'd downloaded yours a couple months ago after seeing one of the bug discussions in a search, then proceeded to forget that I'd done that when I posted last week (sorry). So my current test case with the chunked encoding problem is also failing on this build. Today I'll get the source for my local build from CVS instead of the 2.0.4 src zip, and put in the same debugging log probes I've been using into that source to see what the current scoop is. Let me know if there's anything I can supply you or can do during the testing that you'd like to see. I should know more today, as I actually have time to spend on this, and finding it will cure an infrequent production problem we're having with a new vendor that hits this. Once I know more I'll post again. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IIS Connector and chunked encoding
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]
