Hi Christoph,
> "(...) you should always use x-gzip and x-compress for these two
> specific encodings."
Wasn't this "x-" prefix reserved for proprietary values anyway?
> What's the motivation for this suggestion? I think it should be dropped.
+1
> Internet Explorer doesn't support "x-gzip", but "gzip".
> This is legal because of its "Accept-Encoding: gzip, deflate".
Mozilla behaves the same way:
pref("network.http.accept-encoding" ,"gzip,deflate,compress;q=0.9");
Opera 5, 6 and 7 support both gzip variants but no "compress":
ACCEPT_ENCODING: deflate, gzip, x-gzip, identity, *;q=0
> However, some proxy servers like WebWasher remove the Accept-Encoding
> header from all requests.
Cequrux is another of these filters that removes "Accept-Encoding".
In other cases these "personal firewalls" simply overwrite the
content of the "Accept-Encoding" headers with "XXXXX" strings
(thus they don't have to recalculate the size of the HTTP headers);
the popular "Zone Alarm" firewall is acting this way.
Unfortunately, these two behaviours have _different_ consequences
in respect to HTTP/1.1 (see below).
> According to
>
> "If the client didn't specifically request a particular form
> Apache will use the form given by the AddEncoding directive."
>
> Apache will then answer with an "Content-Encoding: x-gzip" if e.g.
> "AddEncoding x-gzip .gz" is set. IE is unable to uncompress such an
> entity and displays the download dialog.
RFC 2616 says:
1. If an Accept-Encoding field is present in a request, and if the
server cannot send a response which is acceptable according to
the Accept-Encoding header, then the server SHOULD send an error
response with the 406 (Not Acceptable) status code.
(this would apply to overwritten "Accept-Encoding" headers;
Apache would then have to reject the request, and in this
situation Apache already creates a document on the fly with
links to all available variants)
2. 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.
(this would apply to removed "Accept-Encoding" headers; it
seems to implicate that the server should do content negotia-
tion for the "Accept-Encoding:" header to comply to HTTP/1.1
the best possible way but is entitled to server any encoding)
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3)
> "AddEncoding gzip .gz" would work fine in this scenario, and I think
> the Apache documentation should contain this suggestion rather than
> the current one.
+1 from my side.
Even HTTP/1.1 considers the "x-" variants somewhat outdated:
For compatibility with previous implementations of HTTP,
applications SHOULD consider "x-gzip" and "x-compress" to be
equivalent to "gzip" and "compress" respectively.
(http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.5)
Regards, Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
