tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: IIS Connector and chunked encoding
Date Tue, 14 Sep 2004 13:58:28 GMT
>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 #.


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
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
<     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) {
>     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:
For additional commands, e-mail:

View raw message