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

Re: multiple Content-Encoding

From: Dave Kristol <dmk@allegra.att.com>
Date: Wed, 16 Aug 95 15:57:49 EDT
Message-Id: <199508162007.AA216313656@hplb.hpl.hp.com>
To: fielding@beach.w3.org
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Roy Fielding <fielding@beach.w3.org> wrote:
  > dmk@allegra.att.com (Dave Kristol) wrote:
  > >Section 8.7 of draft-ietf-http-v10-spec-01.ps says:
  > >
  > >	If multiple encodings have been applied to a resource, the
  > >	encoding-mechanisms must be listed in the order in which they
  > >	were applied.
  > >	====
  > >
  > >I think this is backward.  I think they should be listed in the order
  > >in which they must be applied by the client in the order they're listed.
  > >	      ==== ==
  > >
  > >Consider foo.gz.Z.  Gzip was applied first, then compress.  NCSA HTTP
  > >1.3 produces this header:
  > >	Content-Encoding: x-compress, x-gzip
  > >(It looks like the old CERN code I have doesn't support multiple
  > >encodings.)
  > I didn't think anyone did, but that interpretation is ugly.
Ugly or not, it exists.  Whether anyone actually uses it is another
  > Message header field values should be "added" via an append
  > operation.  Thus, each encoding becomes layered, and
  >      Content-Encoding: first
  >      Content-Encoding: second
  > has the same semantics as
  >      Content-Encoding: first, second
  > If we reverse the order, then added headers must be prepended.

That makes sense (aesthetically) if you assume that these encodings are
applied dynamically.  Often they have already been applied to static
files (e.g., my example), in which case you have to reconstruct the
encodings outside-in.  From an implementation standpoint, it's easier
to do it the way NCSA has done it.

Dave Kristol
Received on Wednesday, 16 August 1995 13:09:28 UTC

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