Issue #6831
closedContent App incorrectly sets "content-encoding" headers
Description
Some background: https://docs.microsoft.com/en-us/archive/blogs/wndp/content-encoding-content-type
Python package source distributions use the .tar.gz file extension. When the pulp content app sees this extension it automatically [0] sets the content-encoding header with value "gzip", which is inappropriate. As described in the article:
Content-Encoding is used solely to specify any additional encoding done by the server before the content was transmitted to the client. Although the HTTP RFC outlines these rules pretty clearly, some web sites respond with "gzip" as the Content-Encoding even though the server has not gzipped the content.
Our testing has shown this problem to be limited to some sites that serve Unix/Linux style "tarball" files. Tarballs are gzip compressed archives files. By setting the Content-Encoding header to "gzip" on a tarball, the server is specifying that it has additionally gzipped the gzipped file. This, of course, is unlikely but not impossible or non-compliant.
Unlike the provided example which is double-gzipped, what is happening here is that we are telling the client we have gzipped a (.tar.gz) file which we have not gzipped, thus, the client tries to automatically decode the response by un-gzipping it rather than accepting it unmodified.
Because we are serving unmodified files, we should not be setting the content-encoding header.
Updated by pulpbot over 4 years ago
- Status changed from NEW to POST
Added by dkliban@redhat.com over 4 years ago
Updated by dkliban@redhat.com over 4 years ago
- Status changed from POST to MODIFIED
Applied in changeset pulpcore|4765ef463f9387623a4e7285d4d21262714e3a10.
Updated by dkliban@redhat.com over 4 years ago
- Status changed from MODIFIED to CLOSED - CURRENTRELEASE
Removes Content-Encoding header from pulpcore-content responses.
This header is not needed because the server is not actually encoding the response.
fixes: #6831 https://pulp.plan.io/issues/6831