Ошибка Curl при подключении локальных сайтов Discourse и WordPress

Разработка
1

В последнее время при попытке подключения моих локальных сайтов Discourse и WordPress я получаю следующую ошибку:

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

Похоже, проблема в том, что в локальной среде разработки Discourse устанавливает следующий заголовок:

content-encoding: null

Мой локальный сервер Apache не может обработать заголовок content-encoding: null. Из моей консоли wp shell запрос wp_remote_get("http://localhost:4200/site.json") завершается ошибкой, которую я привёл выше, тогда как запрос к продакшн-сайту Discourse, например wp_remote_get("https://meta.discourse.org/site.json"), выполняется без каких-либо проблем.

Мое временное решение проблемы — закомментировать эту строку в локальной установке Discourse: https://github.com/discourse/discourse/blob/main/app/assets/javascripts/bootstrap-json/index.js#L330. Однако это не самое лучшее решение. У кого-нибудь возникали подобные проблемы при подключении к сайту Discourse, работающему на localhost? Есть ли у кого-нибудь предложения, как настроить локальный сервер Apache для принятия ответов с заголовком content-encoding: null?

Жаль, что я не знаю точно, когда началась эта проблема. Возможно, она возникает с тех пор, как Discourse начал устанавливать заголовок content-encoding: null.

Редактирование: проблема возникает на Ubuntu 22.04.1. Версия Curl: curl 7.81.0. Версия PHP: 8.1.2. Это не срочно, но мне интересно, что именно происходит.

2

Интересно! Это звучит знакомо, но я пока не могу точно вспомнить, где именно. Но, думаю, мой первый вопрос: где и почему Discourse устанавливает заголовок content-encoding в значение null?

Действительно, это похоже на проблему, возникающую только в режиме разработки. Это, вероятно, связано с:

3

Номера строк меняются по мере обновления кода. Для справки: строка в коде Discourse, которую мне приходится закомментировать для локальной разработки с плагином WP Discourse, следующая:

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

Не проводя полного анализа того, что происходит в коде Discourse, кажется, что закомментирование этой строки заставляет Discourse сжимать ответ с помощью gzip:

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

В моей среде разработки это, похоже, не вызывает никаких проблем.

4

Мне приходится возвращаться к этой теме каждый раз, когда я хочу подключить свои локальные сайты WordPress и Discourse.

Для своей справки: строка res.set("content-encoding", null); теперь находится здесь:

Комментирование этой строки решает проблему.

Если эта проблема не затрагивает других, возможно, в моей локальной среде разработки что-то настроено неверно. Однако установка заголовка “content-encoding” в значение null всё ещё кажется неправильной. Это недопустимое значение для заголовка.

5

На самом деле я тоже недавно столкнулся с этим в контексте плагина ActivityPub при тестировании интеграции ActivityPub между плагином WordPress ActivityPub и Discourse локально.

Я изменил категорию на Development, потому что считаю, что это проблема только разработки в discourse/discourse, которая проявляется только с PHP-удалённым сервером (из-за того, как функции запросов PHP обрабатывают данные или что-то в этом роде).

Сейчас точно не помню, но, кажется, пришёл к выводу, что в продакшене это устанавливается в другом месте? Постараюсь вспомнить завтра.