- From: Jamison Gulden <jamison@ncic.net>
- Date: Mon, 16 Sep 1996 23:52:11 -0600
- 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
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...
Jamie
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