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: Larry Masinter <masinter@parc.xerox.com>
Date: Sat, 14 Sep 1996 19:08:35 PDT
To: janl@ifi.uio.no
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <96Sep14.190835pdt."2733"@golden.parc.xerox.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1576
> * Firstly, the Accept-Encoding header.  It is used for content
> negociation.  It's absense implies that any Content-Encoding is
> acceptable to the client.  There seems to be no way to specify that
> the client wishes only unencoded documents returned.  To me this seems
> to be a desierable feature.  Thus the value 'none' might be
> acceptable, and result in a non-encoded document to be sent.

This seems like a protocol design error, and doesn't really match
HTTP/1.0 practice. No "Accept-encoding" header means that the server
guesses what's acceptable to the client; the "MAY assume" is nonsense,
since in fact, if the server knows some novel, new encodings, it's
certain that there are clients that don't send Accept-encoding and yet
don't know about them.

> * Secondly about the usage of the Content-Encoding header.  I have
> seen, in various places, that the correct Content-Encoding for a file
> named, index.html.gz should be 'gzip'.  At first glance this is
> reasonable.  But in a content negociation context it's confusing and
> results in needles complexety.

Your two scenarios are not mutually exclusive.  The name of the file
is irrelevant. What is being described is the content of the data

If you have a file index.html.gz which is gzipped HTML, and you
deliver the data without transformation, then the result should be

content-type: text/html
content-encoding: gzip

no matter whether you're returning the data as a result of requesting
"index.html.gz" or "index.html". The correct behavior in the client is
to interpret the data returned according to the content- labelling of
the result.

If a client wants to save the results to a disk file, the client might
want to make up a convenient file name; however, the file name it
makes up need not look like the URL that was requested. Presumably,
though, "save to file" would save the contents AFTER it was unencoded.
IF you have local conventions that text/html files are saved with
".html" at the end, THEN you might want to process the URL in order to
generate that as a sample file name.


Received on Saturday, 14 September 1996 19:11:01 UTC

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