httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Hartill <>
Subject WWW Form Bug Report: ".gz and .Z yields both Content-Type and Content-Encoding" on SunOS 4.x (fwd)
Date Fri, 30 Aug 1996 16:23:50 GMT

Seems to be a long winded (not acked) request for something that's
now been done AFAIK.

----- Forwarded message from -----

Message-Id: <>
Date: Fri Aug 30  8:56:59 1996
Subject: WWW Form Bug Report: ".gz and .Z yields both Content-Type and Content-Encoding" on
SunOS 4.x

Submitter: andersa@DoCS.UU.SE
Operating system: SunOS 4.x, version: 4.1.3
Version of Apache Used: 1.1.1
Extra Modules used: cern_meta_module status_module info_module
URL exhibiting problem: 

Retrieving a file named (a Postscript
file compressed with gzip) results in the data
arriving with the following lines in the header:

Content-type: application/x-gzip
Content-encoding: x-gzip

Of course, the client is confused. I use the
conf/mime.types file as it comes with the 1.1.1
distribution.  In srm.conf, I have added the
suffixes Z and gz as indicators of x-compress and
x-gzip encoding, respectively.  I have also added
a number of content types, but not for Z or gz.
I use AddIconByEncoding once, for x-compress and
x-gzip (shouldn't matter, I think).

To eliminate the problem, I commented out the
application/x-gzip and application/x-compress
content types from the mime.types file, in spite
of your advice not to modify it (I don't see how
I should do it elseway, as there appears to be no
SubtractType configuration directive).  My server
now behaves as expected.

My conclusion: Either the application/x-gzip and
application/x-compress types are inappropriate in
the distributed mime.types file, or there is a
flaw in the algorithm by which Apache decodes the
file name.  I appreciate the simplicity of the
code (I took a quick look at that particular
piece), but I can't imagine a case where one would
want the same file name suffix to yield both a
content type and a content encoding (or a content
language, for that matter).  Examples to the
contrary would be most appreciated.

As things are, I don't want you to change the
algorithm to enforce a particular order of content
language, type, and encoding suffixes, because I
happen to disagree with the order which you have
chosen in your documentation (file.type.lang.enc).
To me, file.lang.type.enc is the most logical
arrangement (I'm told that industry standard in
L10N matters begs to differ, but I know better
than industry :-).  I'm happy if Apache supports
it either way.  I do encourage people to include
language indicators in their file names in a
uniform manner, as we occasionally want to present
the same information in English and Swedish,
although I haven't yet configured the server for
language negotiation.  We recently upgraded to
Apache 1.1.1 from CERN httpd 3.0, which also
supports content language.

However, I figure that if Apache has successfully
identified as a gzipped file, it should
consider only the part when it comes to
determining the content type.  Too bad then if it
decides that has a content type of
application/x-gzip, and then tries to find an
encoding or a language that matches (there
wouldn't be one in my configuration)...

To me, it seems like the best solution is to
remove application/x-{compress,gzip} from the
distributed mime.types file.



----- End of forwarded message from -----

Rob Hartill (  ... why wait for a clear night to see the stars?.

View raw message