- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Mon, 28 Jul 97 10:22:19 MDT
- To: mau@beatles.cselt.it
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
% If no Accept-Encoding field is present in a request, the server MAY
% assume that the client will accept any content coding. In this
% case, if "identity" is one of the available content-codings, then
% the server SHOULD use the "identity" content-coding, unless
% it has additional information that a different content-coding
% is meaningful to the client.
While the SHOULD make sense to me, I don't understand the reason for
the first MAY. What else could a server do? Reject the request
altogether?
One alternative interpretation would be that the server could only
send the "identity" coding (i.e., no Content-Encoding response header)
if the client sends no Accept-Encoding field. After some discussion
a few months ago, we rejected this because it would break some
existing applications (for example, "robot" clients that are used
to retrieve the contents of an entire site). Hence, the specification
explicitly allows the server to send something when it doesn't have
an "identity" content-coding available.
We added the advice that if you have a choice of encodings, and one of
those choices is "identity", and the client hasn't indicated an
ability to decode anything else, then you should normally send
"identity". This should eliminate the possibility that a client
receives something which it doesn't understand, unless nothing
else is available.
-Jeff
Received on Monday, 28 July 1997 10:30:06 UTC