IPP Mail Archive: (no subject)

IPP Mail Archive: (no subject)

(no subject)

manros@cp10.es.xerox.com
Mon, 17 Aug 1998 07:28:53 +0100

Message-Id: <3.0.5.32.19980814134358.009ce870@garfield>
X-Sender: cmanros@garfield
X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date: Fri, 14 Aug 1998 13:43:58 PDT
To: ipp@pwg.org
From: Carl-Uno Manros <manros@cp10.es.xerox.com>
Subject: IPP> Chunking and trailers (IMPORTANT question for implementers)
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-ipp@pwg.org

Folks,

Apparently we are not the only ones having question marks about chunking.

Carl-Uno

>Resent-Date: Fri, 14 Aug 1998 13:15:25 PDT
>Date: Fri, 14 Aug 1998 13:15:08 PDT
>From: jg@pa.dec.com (Jim Gettys)
>X-Mailer: Pachyderm (client lkgdhcp-24-224-199.lkg.dec.com, user jg)
>To: http-wg@hplb.hpl.hp.com
>Resent-To: <manros@cp10.es.xerox.com>
>Subject: Chunking and trailers (IMPORTANT question for implementers)
>Resent-From: http-wg@hplb.hpl.hp.com
>X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/338
>X-Loop: http-wg@cuckoo.hpl.hp.com
>Resent-Sender: http-wg-request@hplb.hpl.hp.com
>
>
>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
>days.
>
>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
>
>
>
Carl-Uno Manros
Principal Engineer - Advanced Printing Standards - Xerox Corporation
701 S. Aviation Blvd., El Segundo, CA, M/S: ESAE-231
Phone +1-310-333 8273, Fax +1-310-333 5514
Email: manros@cp10.es.xerox.com