Erreur Curl lors de la connexion entre sites Discourse et WordPress locaux

Dev
1

Depuis un certain temps, je reçois l’erreur suivante lorsque j’essaie de connecter mes sites Discourse et WordPress locaux :

cURL error 61 : Type de codage de contenu non reconnu. libcurl comprend les codages de contenu deflate, gzip, br.

Le problème semble être qu’en environnement de développement local, Discourse définit l’en-tête suivant :

content-encoding: null

Mon serveur Apache local ne peut pas gérer l’en-tête content-encoding: null. Depuis mon shell wp, une requête vers wp_remote_get(\"http://localhost:4200/site.json\") échoue avec l’erreur que j’ai postée ci-dessus, tandis qu’une requête vers un site Discourse en production, par exemple wp_remote_get(\"https://meta.discourse.org/site.json\") fonctionne sans aucun problème.

Ma solution de contournement temporaire pour le problème est de commenter cette ligne sur mon installation Discourse locale : https://github.com/discourse/discourse/blob/main/app/assets/javascripts/bootstrap-json/index.js#L330. Ce n’est cependant pas une excellente solution. Quelqu’un a-t-il rencontré des problèmes similaires en se connectant à un site Discourse fonctionnant sur localhost ? Quelqu’un a-t-il des suggestions sur la façon de configurer un serveur Apache local pour accepter des réponses ayant l’en-tête content-encoding: null ?

J’aimerais savoir exactement quand le problème a commencé. Il est possible qu’il se produise depuis que Discourse a commencé à définir l’en-tête content-encoding: null.

Edit : le problème se produit sur Ubuntu 22.04.1. Version de Curl : curl 7.81.0. Version de PHP : 8.1.2. Ce n’est pas du tout urgent, mais je suis curieux de savoir ce qui se passe.

4 « J'aime »
2

Intéressant ! Cela me dit quelque chose de vague que je n’arrive pas à situer pour le moment. Mais je suppose que ma première question est : où et pourquoi Discourse définit-il l’en-tête content-encoding à null ?

Cela semble en effet être un problème “uniquement en développement”. Cela ressemble à ceci :

1 « J'aime »
3

Les numéros de ligne changent au fur et à mesure que le code est mis à jour. Pour référence future, la ligne dans le code Discourse que je dois commenter pour le développement local avec le plugin WP Discourse est :

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

Sans avoir entièrement retracé ce qui se passe dans le code Discourse, il semble que commenter cette ligne amène Discourse à gzip la réponse :

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

Cela ne semble pas causer de problèmes dans mon environnement de développement.

2 « J'aime »
4

Je dois revenir sur ce sujet à chaque fois que je veux connecter mes sites WordPress et Discourse locaux.

Pour ma propre référence, la ligne res.set("content-encoding", null); se trouve maintenant à :

Commenter la ligne résout le problème.

Si le problème n’affecte pas les autres, il est possible que quelque chose soit mal configuré dans mon environnement de développement local. Définir “content-encoding” à null semble toujours incorrect. Ce n’est pas une valeur valide pour l’en-tête.

5

En fait, j’ai également rencontré cela récemment dans le contexte du plugin ActivityPub lors du test de l’intégration ActivityPub entre le plugin Wordpress ActivityPub et Discourse localement.

J’ai déplacé la catégorie vers Dev ici car je pense qu’il s’agit uniquement d’un problème de développement avec discourse/discourse et qu’il ne se manifeste qu’avec un PHP distant (en raison de la façon dont les fonctions de requête PHP gèrent les choses ou quelque chose comme ça).

Je ne m’en souviens pas exactement maintenant, mais je pense que je suis arrivé à la conclusion que cela est défini ailleurs en production ? J’essaierai de m’en souvenir demain.

1 « J'aime »