GzipHttpOutputInterceptor does not deflate when Accept-Encoding: * is in the request header.

[toffeegryphon]

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]

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.