One day last week or so, seemingly out of the blue, logged in sessions started to throw content encoding errors. The site still works fine for anonymous users.

useless error

There's nothing in error_log, clearing caches and sessions didn't change anything and throttling the page loading speed shows it actually manages to draw the admin (and CiviCRM) toolbar and part of the page before giving up. The running PHP of course supports zlib and compression has been enabled for years. The dbs are acting normally.

The dev tools network tab appears to be useless when trying to determine which request response was bad. I've downloaded a few database snapshots and diffed them, but nothing stands out (though they're huge, so it's possible I missed something). I've made a minor version bump to Drupal to ensure the code is ok (8.9.20); no change. This thread had some helpful suggestions, but nothing brought me closer to finding the cause. One thing I haven't tried yet is to reimport older db backups to see if they work, to rule out a data issue. It's a heavy hammer, so I'm interested in:

How would you approach debugging this, pinpointing the source?

Edit: some more information: it's not a browser issue, since it didn't change and both firefox and chromium hit the same wall. It's hit on all pages, whether admin or on the frontend. When I say that the network tab is useless in identifying the failing request it's because not all are listed or if it's the main html one, the request headers are not set (even with persistent logs enabled). And compression clearly works, since some css files get through successfully before everything breaks.

I tried logging in via curl and comparing good and bad pages, but there was nothing obviously wrong in the requests upon diffing them. Just for posterity, the commands were:

curl -v -L $(drush uli --uid 99) --cookie-jar cookie.txt
curl --cookie cookie.txt -v --trace-ascii - good-url > good
curl --cookie cookie.txt -v --trace-ascii - bad-url > bad
  • If you were to enhance this question with any information about the errors perhaps we could offer answers. As written there is none.
    – cilefen
    Jan 2, 2023 at 18:31
  • There is no useful error, that's the problem. A "content encoding error" is a generic error browsers show, redirecting to blank page. Eg. firefox only adds "An error occurred during a connection to example.com" ... You can look at the linked SO question to see some manifestations. Jan 2, 2023 at 18:47
  • With the information you've given, it's hard to tell whether your issue is a Drupal issue, a server issue, or a browser issue, or where this error is coming from. You'll need to provide something to debug with, for the users here to be able to provide any assistance, as at the moment you've only given a vague description of a problem.
    – Jaypan
    Jan 2, 2023 at 23:27
  • I've added some more info, but yeah, that's the core problem, how to drill deeper. Jan 3, 2023 at 7:06
  • Can you check your services.yml? Maybe the http.response.debug_cacheability_headers is enabled? If so, try setting it to false, clear cache and reload the page.
    – TheDrot
    Jan 4, 2023 at 20:35

1 Answer 1


Because the question is "how would you approach debugging this?", then this is a valid answer:

For a given request that reproduces the error, I would copy the cURL command syntax of the request using the browser tools, and execute the cURL command in a terminal so as to get a better idea of what is going on.

I would pass the -I option to curl to examine the response headers separately too.

  • If I could identify the request, that would be golden already. But thanks anyway, I guess I could try logging in via curl and seeing if it's any more verbose. Jan 3, 2023 at 7:09
  • After trying a curl-based inspection yesterday night and some other tweaks that good immediately reverted due to not showing any change ... this morning the site is back to fully operational. Infuriating, since I can't explain this either and the answer appeared to be "just wait", but it's a relief nonetheless. I'm pinning it down to a temporary problem higher up the stack. Jan 4, 2023 at 20:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.