search

jetty / jetty.project

Eclipse Jetty® - Web Container & Clients - supports HTTP/2, HTTP/1.1, HTTP/1.0, websocket, servlets, and more
https://eclipse.dev/jetty
Other
3.86k stars 1.91k forks source link

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

Open toffeegryphon opened 1 month ago

toffeegryphon commented 1 month ago

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.

joakime commented 1 month ago

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 commented 1 month ago

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

gregw commented 2 weeks ago

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

joakime commented 2 weeks ago

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

joakime commented 2 weeks ago

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