Curl-Fehler beim Verbinden lokaler Discourse- und WordPress-Seiten

Entwickler
1

Seit einiger Zeit erhalte ich die folgende Fehlermeldung, wenn ich versuche, meine lokalen Discourse- und WordPress-Sites zu verbinden:

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

Das Problem scheint zu sein, dass Discourse in einer lokalen Entwicklungsumgebung den folgenden Header setzt:

content-encoding: null

Mein lokaler Apache-Server kann den Header content-encoding: null nicht verarbeiten. Aus meiner wp-Shell schlägt eine Anfrage an wp_remote_get("http://localhost:4200/site.json") mit dem oben genannten Fehler fehl, während eine Anfrage an eine Discourse-Produktionsseite, z. B. wp_remote_get("https://meta.discourse.org/site.json"), ohne Probleme funktioniert.

Meine temporäre Problemumgehung besteht darin, diese Zeile in meiner lokalen Discourse-Installation auszukommentieren: https://github.com/discourse/discourse/blob/main/app/assets/javascripts/bootstrap-json/index.js#L330. Das ist jedoch keine gute Lösung. Sind schon einmal ähnliche Probleme beim Verbinden mit einer Discourse-Site auf localhost aufgetreten? Hat jemand Vorschläge, wie man einen lokalen Apache-Server so konfiguriert, dass er Antworten mit dem Header content-encoding: null akzeptiert?

Ich wünschte, ich wüsste genau, wann das Problem aufgetreten ist. Möglicherweise tritt es auf, seit Discourse begonnen hat, den Header content-encoding: null zu setzen.

Bearbeitung: Das Problem tritt unter Ubuntu 22.04.1 auf. Curl-Version: curl 7.81.0. PHP-Version: 8.1.2. Das ist überhaupt nicht dringend, aber ich bin neugierig, was vor sich geht.

4 „Gefällt mir“
2

Interessant! Das kommt mir vage bekannt vor, ich kann es aber im Moment nicht genau zuordnen. Aber ich schätze, meine erste Frage ist, wo und warum setzt Discourse den content-encoding-Header auf null?

Dies scheint tatsächlich ein Problem zu sein, das nur in der Entwicklung auftritt. Das sieht verwandt aus

1 „Gefällt mir“
3

Zeilennummern ändern sich, wenn der Code aktualisiert wird. Für zukünftige Referenz ist die Zeile im Discourse-Code, die ich für die lokale Entwicklung mit dem WP Discourse-Plugin auskommentieren muss:

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

Ohne den genauen Ablauf im Discourse-Code vollständig nachvollzogen zu haben, scheint das Auskommentieren dieser Zeile dazu zu führen, dass Discourse die Antwort komprimiert (gzip):

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

Dies scheint in meiner Entwicklungsumgebung keine Probleme zu verursachen.

2 „Gefällt mir“
4

Ich muss jedes Mal zu diesem Thema zurückkehren, wenn ich meine lokalen WordPress- und Discourse-Sites verbinden möchte.

Zu meiner eigenen Referenz befindet sich die Zeile res.set("content-encoding", null); jetzt unter:

Das Auskommentieren der Zeile behebt das Problem.

Wenn das Problem andere nicht betrifft, ist möglicherweise etwas in meiner lokalen Entwicklungsumgebung falsch konfiguriert. Das Setzen von “content-encoding” auf null erscheint mir jedoch immer noch falsch. Es ist kein gültiger Wert für den Header.

5

Ich bin kürzlich auch im Zusammenhang mit dem ActivityPub-Plugin darauf gestoßen, als ich die ActivityPub-Integration zwischen dem Wordpress ActivityPub-Plugin und Discourse lokal getestet habe.

Ich habe die Kategorie hier in Dev geändert, da ich denke, dass es sich nur um ein Entwicklungsproblem mit discourse/discourse handelt und es nur mit einem PHP-Remote auftritt (wegen der Funktionsweise der PHP-Anfragen oder so etwas).

Ich erinnere mich gerade nicht genau, aber ich glaube, ich kam zu dem Schluss, dass dies in der Produktion woanders gesetzt wird? Ich werde versuchen, mich morgen zu erinnern.

1 „Gefällt mir“