httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael.Schro...@telekurs.de
Subject Antwort: Why x-gzip rather than gzip?
Date Wed, 12 Mar 2003 15:31:07 GMT

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: docs-unsubscribe@httpd.apache.org
For additional commands, e-mail: docs-help@httpd.apache.org


Mime
View raw message