Content compression detection is faulty when brotli is enabled

  • Resolved pgpagely

    (@pgpagely)


    1 year ago

    Right now, when displaying the “gzip status” of a site, content compression is detected by making 3 HTTP requests to the site with certain headers to simulate a web request.

    One issue with this is that the headers are not specific about what kind of compression is desired, and this results in a faulty status when brotli compression is enabled. brotli is considered to be superior to gzip and so whenever a webserver has it available and the client supports it, it will normally be used. The result of this is your outbound web request, which looks a bit like this when rewritten in curl:

    curl --compressed -sIL -X GET "https://<home-url>/?avoid-minify=true"

    Ends up returning content-encoding: br, which fails your checks and incorrectly warns the user that compression isn’t working properly.

    What you should really do to fix this is to change this:

    $headers   = array(
    'Content-Type' => 'text/plain',
);

    To this, indicating you only accept gzip:

    $headers   = array(
    'Content-Type' => 'text/plain',
    'Accept-Encoding' => 'gzip',
);

    Or alternatively, modify your checks to also accept br as a valid value for the content-encoding header.

Viewing 4 replies - 1 through 4 (of 4 total)
  • Plugin Support Williams – WPMU DEV Support

    (@wpmudev-support8)

    Hi @pgpagely

    I hope you’re well today!

    Yes, we are aware of that. It isn’t a bug but just lack of support for Brotli. Hummingbird currently only supports Gzip compression – in terms of both detection and possible configuration via .htaccess (on Apache servers).

    For Brotli it can’t yet detect or set it.

    Full support for Brotli is already scheduled to be added to plugin. I don’t have ETA yet but I would expect it to be included around release version 3.8.

    Kind regards,
    Adam

    Thread Starter pgpagely

    (@pgpagely)

    I understand – but I contest that it is a bug – the request is not to add brotli support to the plugin, but rather to adjust the headers you send on your request so that when you say you are checking for gzip support, you are actually checking for gzip support. Right now you are checking for any kind of compression on a response, and then failing when that compression doesn’t happen to be gzip.

    The server has gzip available and will gzip files where the client only supports gzip, but when the client supports both gzip and brotli, it’s going to choose brotli and then your code will flag that the server doesn’t support gzip. If you add an Accept-Encoding: gzip header to your request to the server then this won’t be an issue and your check will pass.

    • This reply was modified 1 year ago by pgpagely.
    Plugin Support Williams – WPMU DEV Support

    (@wpmudev-support8)

    Hi @pgpagely

    Thank you for response!

    I understand your point and I’m definitely not going to argue with that.

    Still, the entire issue is a consequence of the fact that back at the time when Gzip support was introduced to Hummingbird, Brotli really wasn’t that popular.

    But anyway, that’s just a side-note. It is going to be implemented (or fixed, if you prefer to call it that way) in Hummingbird as there is already support for Brotli planned to be added. And that includes also detecting correctly both types of compression.

    It will be there around version 3.8 (I don’t have exact update date though).

    Kind regards,
    Adam

    Plugin Support Amin – WPMU DEV Support

    (@wpmudev-support2)

    Hello @pgpagely ,

    We haven’t heard from you for a week now, so it looks like you don’t have more questions for us about the Brotli integration.

    Feel free to re-open this topic if needed.

    Kind regards
    Kasia

Viewing 4 replies - 1 through 4 (of 4 total)
  • The topic ‘Content compression detection is faulty when brotli is enabled’ is closed to new replies.