Re: multiple Content-Encoding

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
matter.
  > 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