simon
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シェルでは、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で実行する際に、同様の問題に遭遇した人はいますか? content-encoding: nullヘッダーを持つレスポンスを受け入れるように、ローカルApacheサーバーを設定する方法について提案はありますか?
問題がいつ始まったのか正確にはわかりません。おそらく、Discourseがcontent-encoding: nullヘッダーを設定し始めてから発生している可能性があります。
編集:問題はUbuntu 22.04.1で発生しています。Curlのバージョン:curl 7.81.0。PHPのバージョン:8.1.2。これは全く緊急ではありませんが、何が起こっているのか興味があります。
「いいね!」 4
angus
(Angus McLeod)
2
面白いですね!かすかに聞き覚えがあるような気がしますが、今は思い出せません。しかし、Discourse が content-encoding ヘッダーを null に設定しているのは、どこで、なぜなのでしょうか?
これは確かに「開発専用」の問題のようです。これに関連しているようです。
「いいね!」 1
simon
3
行番号はコードの更新によって変更されます。将来の参照のために、WP Discourseプラグインを使用したローカル開発でコメントアウトする必要があるDiscourseコードの行は次のとおりです。
res.set("content-encoding", null);
Discourseコードで何が起こっているのかを完全にトレースすることなく、その行をコメントアウトすると、Discourseがレスポンスをgzipしているようです。
["content-encoding"]=>
array(1) {
[0]=>
string(4) "gzip"
}
これは私の開発環境では問題を引き起こしていないようです。
「いいね!」 2
simon
4
ローカルのWordPressサイトとDiscourseサイトを接続するたびに、このトピックに戻ってこなければなりません。
自分の参考のために、res.set("content-encoding", null); の行は現在次の場所にあります。
この行をコメントアウトすると、問題は解決します。
もし他の人がこの問題の影響を受けていないのであれば、私のローカル開発環境で何かが誤って設定されている可能性があります。しかし、「content-encoding」を null に設定するのは、やはり間違っているように思えます。ヘッダーの有効な値ではありません。
angus
(Angus McLeod)
5
実際、Wordpress ActivityPubプラグインとDiscourseをローカルでテストする際に、ActivityPubプラグインのコンテキストで最近これに遭遇しました。
これはdiscourse/discourseの開発上の問題であり、PHPリクエスト関数が処理する方法(またはそれに類するもの)のためにPHPリモートでのみ発生すると考えられるため、カテゴリを#devに変更しました。
今すぐ正確には思い出せませんが、本番環境ではこれが他の場所で設定されるという結論に至ったと思います。明日思い出してみます。
「いいね!」 1