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

Response compression does not work when the Accept-Encoding: * request header is used. #12324

Closed
toffeegryphon opened this issue Sep 27, 2024 · 6 comments
Assignees
Labels
Bug For general bugs on Jetty side Specification For all industry Specifications (IETF / Servlet / etc)

Comments

@toffeegryphon
Copy link

toffeegryphon commented Sep 27, 2024

Jetty version(s)
Up to 12.0.x

Jetty Environment
core

Java version/vendor (use: java -version)
Not relevant

OS type/version
Not relevant

Description
This doesn't really affect anything, but it is unexpected. According to RF9110 12.5.3,

The asterisk "*" symbol in an Accept-Encoding field matches any available content coding not explicitly listed in the field.

However, the HttpField class' contains method does not check for a lone * character. So when Accept-Encoding: * is passed as a request header, the GzipHandler's getDeflaterEntry believes that gzip is not accepted, and returns null.

How to reproduce?
Run a simple web server with the GzipHandler installed, and send a request with Accept-Encoding: *. The response will not contain the Content-Encoding: gzip header, and the body will not be compressed.

@toffeegryphon toffeegryphon added the Bug For general bugs on Jetty side label Sep 27, 2024
@joakime joakime added the Specification For all industry Specifications (IETF / Servlet / etc) label Sep 27, 2024
@joakime
Copy link
Contributor

joakime commented Sep 27, 2024

Legit bug.

The * value is valid for Accept-Encoding on the request side.
Used to be a common setting, seen in many browsers.

But since the world of gzip + brotli + zstandard is now a reality, that kind of usage has fallen out of favor as the user-agent (client) can get a Content-Encoding response it really doesn't understand what to do with.

That, and when we have multiple encodings that the server can support, we currently don't have a way to configure for preferred encoding.

I need to fix this * value and preferred encoding (with order) configuration to the #12075 effort (on Jetty 12.1.x)

Using * also would make supporting compression dictionaries really awkward, as those can be compression encoder specific.

@gregw
Copy link
Contributor

gregw commented Oct 1, 2024

As a work around until we fully support *, use a rewrite customiser that replaced the * with the servers preferred encoding

@gregw
Copy link
Contributor

gregw commented Oct 30, 2024

@joakime should we support this only in the new compression handler?

@joakime
Copy link
Contributor

joakime commented Oct 30, 2024

@gregw yes, I think that's a better place for supporting this issue.

@joakime joakime moved this to 🏗 In progress in Jetty 12.1.0 Oct 30, 2024
@joakime joakime self-assigned this Oct 30, 2024
@joakime joakime changed the title GzipHttpOutputInterceptor does not deflate when Accept-Encoding: * is in the request header. Response compression does not work when the Accept-Encoding: * request header is used. Oct 31, 2024
@joakime
Copy link
Contributor

joakime commented Oct 31, 2024

The fix for this is has been started for the CompressionHandler in Jetty 12.1.x on PR #12449

joakime added a commit that referenced this issue Nov 11, 2024
Support Accept-Encoding: * on CompressionHandler.
@joakime
Copy link
Contributor

joakime commented Nov 27, 2024

Merged

Fixed in CompressionHandler via a compressPreferredEncoderOrder configurable.

@joakime joakime closed this as completed Nov 27, 2024
@github-project-automation github-project-automation bot moved this from 🏗 In progress to ✅ Done in Jetty 12.1.0 Nov 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug For general bugs on Jetty side Specification For all industry Specifications (IETF / Servlet / etc)
Projects
Status: ✅ Done
Development

No branches or pull requests

3 participants