Errore Curl durante la connessione tra i siti Discourse e WordPress locali

Sviluppatore
1

Da un po’ di tempo ricevo il seguente errore quando tento di connettere i miei siti locali di Discourse e WordPress:

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

Il problema sembra essere che in un ambiente di sviluppo locale, Discourse imposta l’intestazione seguente:

content-encoding: null

Il mio server Apache locale non è in grado di gestire l’intestazione content-encoding: null. Dal mio wp shell, una richiesta a wp_remote_get("http://localhost:4200/site.json") fallisce con l’errore che ho postato sopra, mentre una richiesta a un sito di produzione Discourse, ad esempio wp_remote_get("https://meta.discourse.org/site.json") funziona senza problemi.

La mia soluzione temporanea al problema è commentare questa riga sulla mia installazione locale di Discourse: https://github.com/discourse/discourse/blob/main/app/assets/javascripts/bootstrap-json/index.js#L330. Tuttavia, non è una buona soluzione. Qualcuno ha riscontrato problemi simili nel connettersi a un sito Discourse in esecuzione su localhost? Qualcuno ha suggerimenti su come configurare un server Apache locale per accettare risposte che hanno l’intestazione content-encoding: null?

Vorrei sapere esattamente quando è iniziato il problema. Possibilmente si verifica da quando Discourse ha iniziato a impostare l’intestazione content-encoding: null.

Modifica: il problema si verifica su Ubuntu 22.04.1. Versione Curl: curl 7.81.0. Versione PHP: 8.1.2. Non è affatto urgente, ma sono curioso di sapere cosa sta succedendo.

4 Mi Piace
2

Interessante! Mi ricorda vagamente qualcosa che al momento non riesco a collocare. Ma immagino che la mia prima domanda sia dove e perché Discourse sta impostando l’header content-encoding su null?

Questo sembra effettivamente essere un problema “solo per lo sviluppo”. Sembra correlato a

1 Mi Piace
3

I numeri di riga cambiano man mano che il codice viene aggiornato. Per riferimento futuro, la riga nel codice Discourse che devo commentare per lo sviluppo locale con il plugin WP Discourse è:

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

Senza aver tracciato completamente cosa sta succedendo nel codice Discourse, sembra che commentare quella riga faccia sì che Discourse esegua il gzip della risposta:

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

Questo non sembra causare problemi nel mio ambiente di sviluppo.

2 Mi Piace
4

Devo tornare su questo argomento ogni volta che voglio connettere i miei siti WordPress e Discourse locali.

Per mia informazione, la riga res.set("content-encoding", null); si trova ora qui:

Commentare la riga risolve il problema.

Se il problema non sta interessando altri, forse c’è qualcosa di mal configurato nel mio ambiente di sviluppo locale. Impostare “content-encoding” su null sembra comunque sbagliato. Non è un valore valido per l’header.

5

In realtà, ho riscontrato questo problema di recente anche nel contesto del plugin ActivityPub durante il test dell’integrazione ActivityPub tra il plugin ActivityPub di Wordpress e Discourse localmente.

Ho spostato la categoria in Dev qui perché penso che sia solo un problema di sviluppo con discourse/discourse e si manifesti solo con un remoto PHP (a causa di come le funzioni di richiesta PHP gestiscono le cose o qualcosa del genere).

Non ricordo esattamente in questo momento, ma penso di essere giunto alla conclusione che questo venga impostato altrove in produzione? Cercherò di ricordarmelo domani.

1 Mi Piace