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: Roy T. Fielding <fielding@liege.ICS.UCI.EDU>
Date: Tue, 17 Sep 1996 07:11:27 -0700
To: Jamison Gulden <jamison@ncic.net>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <9609170711.aa20104@paris.ics.uci.edu>
> Should the content-encoding header ONLY be used when the SERVER
> performs an encoding on the file?

No.  The server does not "perform an encoding on the file".  The server
sends a response which is in a data format indicated by content-type
and content-encoding. "file" is not relevant, nor is how the encoding
was originated.

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

If the response contains data which consists of one format encoded
within a second (third, fourth, ...) format, and it is desired that
the recipient know what the underlying data format is, then the server
should put the underlying data format in Content-Type and all layered
encodings in Content-Encoding.

If the server does not want to indicate the underlying data format,
then it should put the encoding format (its MIME type) in Content-Type
and no Content-Encoding.

*Why* such a decision is made is none of the client's business, nor
is it an issue for HTTP.  HTTP only describes the interface.

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

You have to understand this: You NEVER asked for a file.  HTTP is not FTP.
A GET is a request on an HTTP server object, and the server object sends
back a response (not a file) which consists of metainformation (headers)
and body data.  This is why you cannot "mirror" an HTTP server unless
you have some outside knowledge of how that server maps resources to
responses.  Without that knowledge, the only thing you can do is act
as a proxy cache (which, in any case, is a better solution than a mirror).

If you want to traverse HTTP responses on a normal filesystem, then you
will need to store them as application/http or message/http and teach
your browser how to interpret those new (not yet registered) MIME types.

 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
Received on Tuesday, 17 September 1996 07:19:34 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:13 EDT