Curl error connecting local Discourse and WordPress sites

Dev
1

For the past while I’ve been getting the following error when attempting to connect my local Discourse and WordPress sites:

cURL error 61: Unrecognized content encoding type. libcurl understands deflate, gzip, br content encodings.

The issue seems to be that in a local dev environment, Discourse is setting the following header:

content-encoding: null

My local Apache server is unable to handle the content-encoding: null header. From my wp shell, a request to wp_remote_get("http://localhost:4200/site.json") fails with the error I posted above, while a request to a Discourse production site, for example wp_remote_get("https://meta.discourse.org/site.json") works without any issues.

My temporary workaround for the issue is to comment out this line on my local Discourse install: https://github.com/discourse/discourse/blob/main/app/assets/javascripts/bootstrap-json/index.js#L330. That’s not a great solution though. Has anyone run into similar issues with connecting to a Discourse site running on localhost? Does anyone have suggestions for how to configure a local Apache server to accept responses that have the content-encoding: null header?

I wish I knew exactly when the issue started. Possibly it’s been occurring since Discourse started setting the content-encoding: null header.

Edit: the issue is happening on Ubuntu 22.04.1. Curl version: curl 7.81.0. PHP version: 8.1.2. This isn’t at all urgent, but I’m curious about what’s going on.

4 Likes
2

Interesting! This rings a faint bell that I can’t quite place at the moment. But I guess my first question is where and why is Discourse setting the content-encoding header to null?

This does indeed seem to be a “development-only” issue. This looks related

1 Like
3

Line numbers change as the code gets updated. For future reference, the line in the Discourse code I’m having to comment out for local development with the WP Discourse plugin is:

res.set("content-encoding", null);

Without having fully traced what’s going on in the Discourse code, it seems that commenting out that line is causing Discourse to gzip the response:

["content-encoding"]=>
  array(1) {
    [0]=>
    string(4) "gzip"
  }

This doesn’t seem to cause any issues in my dev environment.

2 Likes
4

I have to come back to this topic every time I want to connect my local WordPress and Discourse sites.

For my own reference, the res.set("content-encoding", null); line is now at:

Commenting out the line resolves the issue.

If the issue isn’t affecting others, possibly something is misconfigured in my local dev environment. Setting “content-encoding” to null still seems wrong though. It’s not a valid value for the header.

5

Actually I also encountered this recently in the context of the ActivityPub plugin while testing the ActivityPub integration between the Wordpress ActivityPub plugin and Discourse locally.

I’ve changed the category to dev here because I think it’s only a development issue with discourse/discourse and only manifests with a PHP remote (because of how the PHP request functions handle things or something like that).

I can’t recall exactly right now, but I think I came to the conclusion that this gets set elsewhere in production? I will try to remember tomorrow.

1 Like