Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Compression possible with Transfer-Encoding #1350

Open
bwbroersma opened this issue Mar 20, 2024 · 0 comments
Open

Compression possible with Transfer-Encoding #1350

bwbroersma opened this issue Mar 20, 2024 · 0 comments
Labels
bug Unexpected or unwanted behaviour of current implementations enhancement
Milestone

Comments

@bwbroersma
Copy link
Collaborator

bwbroersma commented Mar 20, 2024

Thanks to:

I noticed currently the compression is only checked by adding a Accept-Encoding:

put_headers = {"Accept-Encoding": "compress, deflate, exi, gzip, pack200-gzip, x-compress, x-gzip"}

To check if the server will return a Content-Encoding:
class HeaderCheckerContentEncoding:
"""
Class for checking the Content-Encoding HTTP header.
"""
def __init__(self):
self.name = "Content-Encoding"
def check(self, value, results, domain):
"""
Check if the header has any value.
"""
if value:
results["http_compression_enabled"] = True

However it's also possible to have compression with Transfer-Encoding (hop-by-hop), see HTTP/1.1 - 7.2. Transfer Codings for Compression - RFC 9112. Note that in HTTP/2, Transfer-Encoding MUST not be present, see HTTP/2 - 8.2.2. Connection-Specific Header Fields - RFC 9113.

The IANA registered values that should be checked for in HTTP/1.1 are: (x-)compress, deflate and (x)-gzip.

BTW 'officially' Content-Encoding shouldn't even be used for on-the-fly compression, but reality is different:

The HTTP syntax error has been fixed in trunk, but the problem motivating this report is a no-win situation no matter how it is "fixed". The only good answer is "don't use mod_deflate" because changing content-encoding on the fly in an inconsistent manner (neither "never" nor "always) makes it impossible for later requests regarding that content (e.g., PUT or conditional GET) to be handled correctly. This is, of course, why performing on-the-fly content-encoding is a stupid idea, and why I added Transfer-Encoding to HTTP as the proper way to do on-the-fly encoding without changing the resource.

See the 2009-02-12 comment by Roy T. Fielding (one of the HTTP authors).

It could be tested by (in case of HTTP/1.1) by also sending the header:

TE: compress, deflate, gzip, x-compress, x-gzip

And then check for any compression value (chunked is okay) in Transport-Encoding, see HTTP/1.1 - 7.4. Negotiating Transfer Codings - RFC 9112.

@bwbroersma bwbroersma added bug Unexpected or unwanted behaviour of current implementations enhancement labels Mar 20, 2024
@bwbroersma bwbroersma added this to the intake milestone Mar 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Unexpected or unwanted behaviour of current implementations enhancement
Development

No branches or pull requests

1 participant