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

Chunking and trailers (IMPORTANT question for implementers)

From: Jim Gettys <jg@pa.dec.com>
Date: Fri, 14 Aug 1998 13:15:08 -0700
Message-Id: <9808142015.AA04132@pachyderm.pa.dec.com>
To: http-wg@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/338

We've come across a protocol interoperability problem with chunking and 
trailers; Jeff Mogul is working on a description of this problem for the 
working group and discussion of the possible fixes (it is subtle enough 
to want a careful exposition). He hopes to have it out in the next couple

We need data from implementers to make a good recommendation of how to 
proceed.  This question is needed to get data on whether the problem actually 
occurs in practice in any deployed code, which will affect what the right 
fix might be (if the situation never exists in any deployed code, then 
the simplest, cleanest fix involves outlawing the protocol condition that
can generate the problem in the first place).

Section 3.6.1 (Chunked Transfer Coding) currently says:

     A server using chunked transfer-coding in a response MUST NOT
     use the trailer for other header fields than Content-MD5 and
     Authentication-Info unless the "chunked" transfer-coding is
     present in the request as an accepted transfer-coding in the TE
     field (section 14.39). The Authentication-Info header is
      defined by RFC 2069 [32] or its successor [43].

This exception for Authentication-Info and Content-MD5 leads
to a potential interoperability bug.

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?

If so, please respond ASAP.  Otherwise, this exception might
be removed from the final draft of the specification.

			Thanks greatly,
			- Jim Gettys
Received on Friday, 14 August 1998 13:18:31 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:23 UTC