# Curl error connecting local Discourse and WordPress sites
**URL:** https://meta.discourse.org/t/curl-error-connecting-local-discourse-and-wordpress-sites/248722
**Category:** Development
**Created:** [December 12, 2022, 11:39pm UTC](https://meta.discourse.org/t/curl-error-connecting-local-discourse-and-wordpress-sites/248722 "2022-12-12T23:39:25Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [December 12, 2022, 11:39pm UTC](https://meta.discourse.org/t/curl-error-connecting-local-discourse-and-wordpress-sites/248722/1 "2022-12-12T23:39:26Z")
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](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.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [December 14, 2022, 9:32am UTC](https://meta.discourse.org/t/curl-error-connecting-local-discourse-and-wordpress-sites/248722/2 "2022-12-14T09:32:35Z")
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
> [@Developing on the mobile version of Discourse](https://meta.discourse.org/t/developing-on-the-mobile-version-of-discourse/216643/5):
>
> After doing some digging through the source, I found two environment variables that help: PRINT\_EXCEPTIONS - shows all exceptions, maybe too noisy to be valuable but it helped RAILS\_LOGS\_STDOUT - logs everything to console which is what I was looking for above These helped confirm that there wasn’t an error occurring within Rails nor my theme’s SCSS. Apparently there was some gzip component stuck between ember and Rails. I’m not sure how this got there, but when the headers Content-Encoding …
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [August 3, 2023, 10:38pm UTC](https://meta.discourse.org/t/curl-error-connecting-local-discourse-and-wordpress-sites/248722/3 "2023-08-03T22:38:26Z")
> [@simon](#):
>
> My temporary workaround for the issue is to comment out this line on my local Discourse install: [discourse/index.js at main · discourse/discourse · GitHub](https://github.com/discourse/discourse/blob/main/app/assets/javascripts/bootstrap-json/index.js#L330).
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](https://github.com/discourse/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:
```plaintext
["content-encoding"]=>
array(1) {
[0]=>
string(4) "gzip"
}
```
This doesn’t seem to cause any issues in my dev environment.
---
### Author:  [@simon](https://meta.discourse.org/u/simon)
#### Post date: [May 28, 2024, 6:23pm UTC](https://meta.discourse.org/t/curl-error-connecting-local-discourse-and-wordpress-sites/248722/4 "2024-05-28T18:23:02Z")
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.
---
### Author:  [@angus](https://meta.discourse.org/u/angus)
#### Post date: [May 28, 2024, 7:12pm UTC](https://meta.discourse.org/t/curl-error-connecting-local-discourse-and-wordpress-sites/248722/5 "2024-05-28T19:12:08Z")
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 #Development 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.