W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Re: Chunking and trailers (IMPORTANT question for implementers)

From: Patrick McManus <mcmanus@appliedtheory.com>
Date: Sun, 16 Aug 1998 10:27:08 -0400 (EDT)
Message-Id: <199808161427.KAA02929@pat.appliedtheory.com>
To: Jim Gettys <jg@pa.dec.com>
Cc: http-wg@hplb.hpl.hp.com
In a previous episode Jim Gettys said...
:: 
:: 
:: We need data from implementers to make a good recommendation of how to 
:: proceed.
[..]
:: 
:: Are there any deployed HTTP servers or proxies that actually
:: send Authentication-Info or Content-MD5 in the trailer of
:: a chunked encoding when the request does not include "chunked"
:: in a TE request-header field?

yes - my origin server will send md5 trailers under some conditions.. the
server is currently in use with a few development projects and shipped
(embedded) to one customer.. it could be altered, but at some cost.

because our server never generates trailers other than md5 it isn't
aware at this stage whether or not a TE request was sent or not, only
whether or not it is in chunked mode.. it will go into chunked mode
anytime there is a 1.1 request and the server feels buffering latency
could be improved by chunking.. when md5 is turned on by the resource
(about 10% of the time in the deployed ap) this almost always results
in chunking to occur..

flip side: a simpleminded (embedded) 1.1 client that interacts with above
mentioned server doesn't send TE but does check the checksum of the
response.. a change to the spec would make that info unavailable to
it.. and it's probably the only client that cares.. other uas (msie,
netscape, etc..) also interact with the server, but they probably
don't check the sums..

opinion: I haven't had time to follow why this is a problem so won't
comment on that.. I will say that this feature is fairly important to
me to preserve.. it lets me apply the MIC without impacting
latency.. though I guess the penalty of having the client send TE to
preserve this is doable..

-P
Received on Sunday, 16 August 1998 07:27:17 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:33:20 EDT