- From: John Franks <john@math.nwu.edu>
- Date: Sat, 13 Dec 1997 11:44:20 -0600 (CST)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Fri, 12 Dec 1997, Jeffrey Mogul wrote: > John Franks wrote: > This raises the whole issue of stacked transfer encodings. > Are you suggesting that arbitrary stackings be allowed, or > just two, the second of which is chunked? > > I'm not "suggesting" anything. It's already in the spec, and > has been there since at least RFC2068: > > 14.40 Transfer-Encoding > > The Transfer-Encoding general-header field indicates what (if any) > type of transformation has been applied to the message body in order > to safely transfer it between the sender and the recipient. This > differs from the Content-Encoding in that the transfer coding is a > property of the message, not of the entity. > > Transfer-Encoding > = "Transfer-Encoding" ":" 1#transfer-coding > > the BNF clearly allows any number of transfer-codings. > > The current -rev-01 draft adds: > If multiple encodings have been applied to an entity, the transfer > codings MUST be listed in the order in which they were applied. > Interesting. I wonder how many current implementations can handle Transfer-Encoding: chunked, chunked, chunked I know mine can't. John Franks john@math.nwu.edu
Received on Saturday, 13 December 1997 09:58:39 UTC