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

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.

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.


John Franks 	Dept of Math. Northwestern University
		john@math.nwu.edu

Received on Monday, 16 September 1996 06:51:48 UTC