gzipFilter in WildFly 30.0.0.Beta1

[Thomas Weberndorfer]

Hi everyone,

When upgrading from WildFly 27.0.1 to 30.0.0.Beta1 I noticed that the predicate of gzipFilter is not working any more:

<subsystem xmlns="urn:jboss:domain:undertow:14.0" default-virtual-host="default-host" default-servlet-container="default" default-server="default-server" statistics-enabled="${wildfly.undertow.statistics-enabled:${wildfly.statistics-enabled:false}}">
<byte-buffer-pool name="default"/>
<buffer-cache name="default"/>
<server name="default-server">
<http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true" proxy-address-forwarding="true"/>
<https-listener name="https" socket-binding="https" worker="default" buffer-pool="default" ssl-context="applicationSSC" enable-http2="true" proxy-address-forwarding="true"/>
<host name="default-host" alias="localhost">
<filter-ref name="gzipFilter" predicate="not request-smaller-than(5000)"/>
<http-invoker/>
</host>
</server>
<servlet-container name="default">
<jsp-config/>
<websockets/>
</servlet-container>
<filters>
<gzip name="gzipFilter"/>
</filters>
</subsystem>

Independent of the response size, the gzip compression is always applied.

Are there any configuration changes necessary?

 

[Bartosz Baranowski]

Hey.
Im not aware of anything. I will have to check.

[Bartosz Baranowski]

Hmm. Im looking at something weird, but this might be due to my setup of POC.
Could you share how messages exchanged/flow + code handling this one?

[Thomas Weberndorfer]

Hi,

Here is my simple example with failing predicate evaluation:

I downloaded WildFly 30.0.0.Beta1 from the WildFly page and adapted the standalone.xml file:

        <subsystem xmlns="urn:jboss:domain:undertow:14.0" default-virtual-host="default-host" default-servlet-container="default" default-server="default-server" statistics-enabled="${wildfly.undertow.statistics-enabled:${wildfly.statistics-enabled:false}}" default-security-domain="other">

            <byte-buffer-pool name="default"/>
            <buffer-cache name="default"/>
            <server name="default-server">

                <http-listener name="default" socket-binding="http" redirect-socket="https" enable-http2="true"/>
                <https-listener name="https" socket-binding="https" ssl-context="applicationSSC" enable-http2="true"/>

                <host name="default-host" alias="localhost">

                    <location name="/" handler="welcome-content"/>
                    <filter-ref name="gzipFilter" predicate="not request-smaller-than(500)"/>
                    <http-invoker http-authentication-factory="application-http-authentication"/>

                </host>
            </server>
            <servlet-container name="default">
                <jsp-config/>
                <websockets/>
            </servlet-container>

            <handlers>
                <file name="welcome-content" path="${jboss.home.dir}/welcome-content"/>
            </handlers>

            <filters>
                <gzip name="gzipFilter"/>
            </filters>

            <application-security-domains>
                <application-security-domain name="other" security-domain="ApplicationDomain"/>
            </application-security-domains>
        </subsystem>

Next, I created a very simple demo application:

@Path("test")
@ApplicationPath("rest")
@Produces(MediaType.APPLICATION_JSON)
@Consumes(MediaType.APPLICATION_JSON)
public class DemoApplication extends Application {

public record Data(String data) {}

  @GET
  @Path("short")
  public Data shortContent() {
    return new Data("short text");
  }

  @GET
  @Path("long")
  public Data longContent() {
    return new Data("long text".repeat(1000));
  }
}

When I call the "short" resource, I get the following response:

So GZIP is used, although the content length is below 500 bytes. With WildFly 27.0.1, this was not the case.

Please find the demo application attached to this post.

Is something wrong with my configuration?

[negora]

I've a similar problem, but it happens when I use the Content-Type response header in the predicate. In my case the predicate started to misbehave from version 28.0.0.Final, I believe. I've tested the gzip filter again in version 30.0.1.Final and the issue still persists.

After some trial-and-error, I think I've found out the cause. It looks like some (or maybe all) response headers are not available at the time a gzip filter takes action. Why do I think this? Because of the following. If I try such a simple predicate like this, based on the Content-Type response header, it doesn't work:

<filter-ref name="gzip-filter" predicate="regex (pattern='.*', value='%{o,Content-Type}', full-match=false)"/>

However, if I try the same predicate, but based on the Accept-Encoding request header, it works:

<filter-ref name="gzip-filter" predicate="regex (pattern='.*', value='%{i,Accept-Encoding}', full-match=false)"/>

The same problem happens with any other header that is returned in the response: Content-Length, Date, etc. They seem not to exist at this stage.

My next trial has been to replace the gzip filter with other filter type. Specifically, one of type response-header . The result has been the same. This makes me think that this issue affects every existing filter whose predicate uses a response header. I've not tested the max-content-size predicate, but if it reads the Content-Length header to obtain the size, I guess it might be affected too.

[negora]

I believe this bug report is related to this issue: https://issues.redhat.com/browse/WFLY-18813 .

[Thomas Weberndorfer]

With WildFly 31.0.0.Final, it is working again.

Thank You!

[negora]

Thank you for informing me, Thomas!