W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: Content encoding problem...

From: Roy T. Fielding <fielding@kiwi.ICS.UCI.EDU>
Date: Fri, 21 Feb 1997 16:55:46 -0800
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <9702211655.aa23797@paris.ics.uci.edu>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2528
>The problem is that HTTP/1.0 is already broken. HTTP/1.0 (for example the
>CERN server) happily sends out content-encoding and doesn't check before
>returning a cached object with any content-encoding.

Yeah, but we already knew that.  We can't do reliable caching with HTTP/1.0,
so anyone who needs reliable caching will have to upgrade.  If this wasn't
true, we could have standardized HTTP/1.0 and be done.

>>     If no Accept-Encoding field is present in a request, the server MAY
>>     assume that the client will accept any content coding.  However, if
>>     the response content is negotiated on the basis of Accept-Encoding,
>>     then the origin server SHOULD select a representation without any
>>     Content-Encoding if one is available; if all available
>>     representations use a non-identity content-coding, then
>>     preference should be given to those content-coding(s) commonly
>>     understood by older user agents, or known to be understood by the
>>     particular user agent that initiated the request.
>In my mind this will carry the bug over from HTTP/1.0 and involves too much
>heuristics. I would make a specific note about how HTTP/1.0 clients react
>to encodings and make HTTP/1.1 specification independent of this by
>treating it as you describe in the next section:
>"If, in this case, the identity content-coding is not available, then the
>server SHOULD send an error response with the 406 (Not Acceptable) status

But that would break my application.  Whereas seeing garbage on an old
browser is inconvenient, preventing an HTTP/1.0 mirror application from
working with HTTP/1.1 servers is simply not allowed within the design
goals of HTTP/1.1.  So, we live with the inconvenience rather than
break existing systems, and make it possible for HTTP/1.1 clients
(which should be required to handle unknown encodings correctly)
to work properly.

Keep in mind that this isn't a protocol version issue.  In the case

        HTTP/1.0         HTTP/1.1
    UA ---------> proxy ---------> OS

the origin server is receiving an HTTP/1.1 request without any
Accept-Encoding, and must deal with that request without breaking
the existing functionality of UA.  Besides, I guarantee that
HTTP/1.1 browsers will have "Save As..." functionality, and thus
it isn't possible for an HTTP/1.1 application to exhaustively list
all accepted content-codings in an Accept-Encoding field for every
type of GET request it will perform.

The real error that we are dealing with is one of UA implementation.
If a UA receives a response that includes a Content-Encoding value
which it is incapable of decoding, then the UA should be smart enough
to know that it cannot simply render the response.  There is no excuse
for failing to anticipate extensions of an extensible field value.

Received on Friday, 21 February 1997 17:20:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:19 UTC