httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Stein <>
Subject chunked transfer-encoding (was: Re: PLEASE READ: Filter I/O)
Date Fri, 23 Jun 2000 10:34:44 GMT
On Fri, Jun 23, 2000 at 06:02:04AM -0400, wrote:
>... long rambling post ... what to quote? what to cut? ...

> If you are stuck in a filtering scenario where you 
> never get a chance to accurately supply the Content-Length
> or be sure that the changes you make to that field will
> be 'preserved' during the entire filtering process
> then you have to 'fall back' on the only HTTP
> method left available to you which signals 'End of Data'
> and that is to close the connection... even if

Eh? The chunked transfer-encoding allows the server to signal EOD. What's
wrong with that? If the client is not HTTP/1.1, then yah: close the
connection. But when that client tells the server "hey! I'm an HTTP/1.1
client" then the server simply uses chunked transfer-encoding.

Forget the Content-length header.

I think the real take-away from this, is that the content-length header
should be axed if a filter is present.

> The only implementations of IETF Content-Encoding
> that even work in modern browsers all DEPEND on
> the Content-Length field being accurate. The 
> decoders on the other end will 'wait' for only
> 1 of 2 events before they will decompress the
> inbound data...
> 1. The exact number of 'Content-Length' indicated
> bytes has been received OK.
> 2. The connection closed and it must be assumed
> all the data arrived OK ( but never known for sure ).

What about the chunked transfer-encoding? Browsers can use that to determine
the transfer size. Or are you stating that a compression mixed with chunked
encoding does not work on these browsers?

> At that level in the scheme of things... there
> simply isn't any way to 'know' you have all the
> data you need since there is no 'official' HTTP
> EOD transport layer indicator to allow you to
> distinguish a 'normal' port close EOD ( all data
> was sent and server has no other way to inform you )
> from an 'abnormal' one. ( Port closed early and all
> the data did NOT arrive ).

The chunked transfer-encoding provides a way for the client to detect an
abnormal termination. If it doesn't see the "end of data" signal, and the
connection closes, then it knows.

> What is missing is a THIRD option and that is an
> actual HTTP 'Transport' layer 'END OF DATA' signal
> that can be sent WITHOUT having to close the port
> and this does not currently exist.

Sorry, but it DOES exist. It is the chunked transfer-encoding. End of story.


Greg Stein,

View raw message