Bug 66149 - Apache httpd 2.4 mod_deflate input decompression interferes with Content-Encoding header in response
Summary: Apache httpd 2.4 mod_deflate input decompression interferes with Content-Enco...
Status: NEW
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_deflate (show other bugs)
Version: 2.4.53
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-06-28 21:35 UTC by I.
Modified: 2022-06-28 21:35 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description I. 2022-06-28 21:35:49 UTC
It seems like there is a bug introduced (in mod_deflate?) between Apache 2.2 and 2.4 wrt. how/when the Content-Encoding header is returned when input decompression is used.

E.g. When using an apache httpd "minimal" configuration that contains these lines:

...
LoadModule deflate_module modules/mod_deflate.so
LoadModule mime_module modules/mod_mime.so

<IfModule mime_module>
    TypesConfig /etc/mime.types
    AddEncoding x-gzip .gz .tgz
    AddType application/x-gzip .gz .tgz
</IfModule>

<IfModule mod_deflate.c>
  SetInputFilter DEFLATE
</IfModule>
...

The http server behaves differently in 2.2 vs. 2.4 when returning a *.tar.gz file: Notably the "Content-Encoding: x-gzip" header is missing from the response in 2.4. My understanding is that the "SetInputFilter DEFLATE" (which is to decompress client requests, as per the apache documentation [1]) should have no bearing as to what headers are returned in the httpd server's response, however when that input deflate filter is turned off, Apache httpd 2.4 also starts returning the "Content-Encoding: x-gzip" in the response.

[1] https://httpd.apache.org/docs/2.4/mod/mod_deflate.html#input

-------------------------------------------------------------------

Example (using an httpd configuration with the above lines for both httpd 2.2 (running on port 8081) and 2.4 (running on port 8080), requesting the same test.tar.gz file. Also note the size and contents of the *.tar.gz file seems to make no difference regarding this issue):

#
# apache 2.2
#

$ curl -v -o /dev/null http://localhost:8081/gzip_tests/test.tar.gz
...
* Connected to localhost (::1) port 8081 (#0)
> GET /gzip_tests/test.tar.gz HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8081
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Tue, 28 Jun 2022 20:53:48 GMT
< Server: Apache/2.2.9 (Unix)
< Last-Modified: Tue, 28 Jun 2022 20:51:05 GMT
< ETag: "40e4010-91-5e28831ffb564"
< Accept-Ranges: bytes
< Content-Length: 145
< Content-Type: application/x-gzip
< Content-Encoding: x-gzip
< 
...

#
# apache 2.4
#

$ curl -v -o /dev/null http://localhost:8080/gzip_tests/test.tar.gz
...
* Connected to localhost (::1) port 8080 (#0)
> GET /gzip_tests/test.tar.gz HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8080
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Tue, 28 Jun 2022 20:54:42 GMT
< Server: Apache/2.4.54 (Unix)
< Last-Modified: Tue, 28 Jun 2022 20:51:05 GMT
< ETag: "91-5e28831ffb564"
< Accept-Ranges: bytes
< Content-Length: 145
< Content-Type: application/x-gzip
< 
...