httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject Re: [PATCH] chunking filter.
Date Wed, 16 Aug 2000 20:40:29 GMT
On Wed, Aug 16, 2000 at 12:56:25PM -0700, wrote:
> > > This does work as far as I can tell.  There is one extra 0 added at the
> > > end of response, but I think that is because I haven't completely removed
> > > the BUFF chunking code.  At least, I can't find any other reason for it.
> > 
> > The extra 0 is part of the protocol. It signifies "no more chunks". There is
> > also an extra CRLF pair to signify "no trailer headers".
> No Greg, there is an extra 0.  Did you even try the code.

Applying and trying it would have been rather difficult. So no. I was
attempting to help you by pointing out where the 0 may have come from. Was
it the "real" thing? Apparently not.

> The ending
> response looks like:
> 0
> 0
> My undertstanding of the protocol is that it is supposed to be
> 0

Yup... that's correct. With an extra CRLF to denote the end of the trailers.

> I only have so much time right now.  This chunking filter works, and it
> works well.  There is no IMMORTAL bucket type, and I am unlikely to have
> the time to write it.  This chunking filter was written in about four
> hours this morning, and most of that was spent hacking around the
> ap_add_filter code.  This patch comes directly out of my original
> chunking patch.  If you want the IMMORTAL bucket, then write it.  If you
> don't, then it will wait until somebody has the time to write it.  Until
> then, this chunking filter works well, it just isn't optimal.

Dude. Why so antagonistic? Geez. I was attempting to help, by pointing out
why the zero might be there, and with some suggestions for improvement.

If you don't have time, then fine. Just don't take my head off.

This patch may work well, but you said yourself there is an extra zero. It
is probably because a zero-length brigade arrives at the chunking filter.

Ah. I found a problem in http_protocol.c. An EOS bucket was being sent on an
ap_rflush() rather than the end_output_stream() function [commit coming
momentarily]. If somebody called ap_rflush() at any point, then you could
get a couple EOS buckets. The length of that brigade is zero.

Hmm. The chunking filter needs to watch out for brigades that are zero
length. I think the right answer is:

*) if the brigade is zero length, then do not insert a chunk header. there
   may be other metadata buckets in the brigade, so it must still be passed.
*) if the brigade is not zero length, then add the chunk header and trailing
*) if the brigade contains EOS, then append the right "termination" stuff
   for the chunking. the appending is really that... the termination text
   must come before the EOS bucket :-)


Greg Stein,

View raw message