W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: HTTP/1.1 draft 12 aug 1996 and content encodings

From: Jamison Gulden <jamison@ncic.net>
Date: Mon, 16 Sep 1996 23:52:11 -0600
Message-Id: <199609170552.XAA31205@ns1.ncic.net>
To: janl@ifi.uio.no, john@math.nwu.edu
Cc: fielding@liege.ICS.UCI.EDU, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1585
OK, I'll through my $0.02 in even if it seems to be the underdog.

> From: John Franks <john@math.nwu.edu>
> On Mon, 16 Sep 1996, Nicolai Langfeldt wrote:
> > - Use of Content-Encoding in a reply where content-negociation has not
> >   happened because there was a direct mapping from the requested object
> >   into the servers object space is not useful, and making this practice
> >   forbiden will break nothing, remove no functionality.  If it is allowed
> >   a automated client will need to use file name heuristics to determine
> >   if content negociation has taken place or not, and based on this
> >   determination decide on a file name for local storage.
> > 
> > To conclude: I think that the Content-Encoding header should only be
> > used when according to the http servers native type rules the encoding
> > of the served object is different from the requested object.  I.e. when
> > the server object is at another place on the content-encoding axis
> > than the requested object.
> I think you missed the point Roy Fielding was making.  Filename
> extensions mean nothing to HTTP.  It is perfectly legal (though silly)
> for me to serve a Postscript file named foo.html.gz and it will work
> perfectly with all browsers as long as I get the Content-type header
> correct.  Likewise I can have a gzip'ed  html file and name it
> foo.ps and all will work perfectly if the Content-type and Content-encoding
> headers are correct.

I understand this point. I think you can remove the issue related to
filename semantics and still have a valid position to discuss. To me
the point is an ambiguity in the spec if interpreted as I think Roy does.

> This means that the ONLY way for a client to know that a file is gzip'ed
> is by the Content-encoding.  Thus if I serve a file (named foo.html.gz or
> named anything else) with content-type HTML and no content-encoding
> the browser MUST treat it as straight HTML and not try to uncompress it.

> The browser always knows exactly what it gets.  However the browser
> has no way of knowing the history of what it gets.  It might have been
> compressed a month ago or it might have been compressed on the fly when
> served.  These are server implementations.

This almost sounds like you are agreeing with Nicolai. Maybe I can
restate the argument slightly differently and see if it makes any
difference: (assume what you are transfering is a static file)

Should the content-encoding header ONLY be used when the SERVER
performs an encoding on the file?

Should the content-encoding header be used when the SERVER does not
perform an encoding on the file?

If you answer both question with a yes then I feel you have an
ambiguity in the protocol that has nothing to do with filenames.

If the server compressed a file with gzip before sending it (either
on the fly, or a month ago) then yes, I agree that the content-encoding
should be gzip. But, if the server didn't do the compression (the file
was already compressed) then I agree that the content-encoding should
be none because the server is serving a file without encoding it. Maybe
the file type is no longer text/html but that is a different issue.

Another way to ask it is: did I ask for a file that got encoded by the
server before sending it to me and the content-encoding header tells me
how it was encoded so that I can get it back to the file I asked for or,
did I ask for a compressed file and the server was trying to be polite
and tell me what type of file I asked for? If the server was just being
polite then that is file type information, not encoding information.

 If I asked for a file that was already
compressed with gzip does a content-encoding of gzip mean that the
server ran gzip on the file and that I have to unzip what was sent
to me so that I end up with the compressed file that I asked for
(double compression)?

Are the following two questions COMPLETELY unambiguous?

     If I ask for a file and it's returned with content-encoding of
     gzip do I get the file I asked for if I unzip it?

     If I ask for a file and it's returned with content-encoding of
     gzip do I get the file I asked for if I don't unzip it?

enough rambling...


PS. I give my comments with a grain of salt since I am not anywhere
close to being an expert on this. Actually, I'm more of a spectator
just watching the discussion.
Received on Monday, 16 September 1996 22:58:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:16:20 UTC