JS embed fallisce con "Job exception: invalid stored block lengths (Zlib::DataError)"

Supporto
1

Ciao, non riusciamo a far funzionare JS embed nella nostra configurazione. Ho letto tutti gli altri argomenti simili e in passato sono riuscito a far funzionare questo embedding in un progetto completamente diverso. Questo sembra essere qualcosa di diverso…

Sul sito esterno, si vede solo il nostro logo seguito da “caricamento discussione…”

Su Discourse, non vengono creati argomenti, anche se il log degli errori mostra che le richieste stanno arrivando.

Abbiamo controllato gli URL. Abbiamo anche provato ad aggiungere un URL statico (invece di una variabile). Niente.

Il log degli errori di Discourse contiene questo Errore:

Job exception: invalid stored block lengths (Zlib::DataError)  

excon-0.88.0/lib/excon/middlewares/decompress.rb:23:in `inflate'

excon-0.88.0/lib/excon/middlewares/decompress.rb:23:in `response_call'

excon-0.88.0/lib/excon/middlewares/base.rb:26:in `response_call'

excon-0.88.0/lib/excon/middlewares/instrumentor.rb:44:in `response_call'

excon-0.88.0/lib/excon/middlewares/base.rb:26:in `response_call'

excon-0.88.0/lib/excon/middlewares/expects.rb:20:in `response_call'

excon-0.88.0/lib/excon/middlewares/response_parser.rb:12:in `response_call'

excon-0.88.0/lib/excon/connection.rb:451:in `response'

excon-0.88.0/lib/excon/connection.rb:282:in `request'

excon-0.88.0/lib/excon.rb:250:in `get'

/var/www/discourse/lib/final_destination.rb:206:in `public_send'

/var/www/discourse/lib/final_destination.rb:206:in `resolve'

/var/www/discourse/app/models/topic_embed.rb:120:in `find_remote'

/var/www/discourse/app/models/topic_embed.rb:192:in `import_remote'

/var/www/discourse/lib/topic_retriever.rb:52:in `fetch_http'

/var/www/discourse/lib/topic_retriever.rb:39:in `perform_retrieve'

/var/www/discourse/lib/topic_retriever.rb:12:in `retrieve'

/var/www/discourse/app/jobs/regular/retrieve_topic.rb:15:in `execute'

/var/www/discourse/app/jobs/base.rb:232:in `block (2 levels) in perform'

rails_multisite-4.0.0/lib/rails_multisite/connection_management.rb:80:in `with_connection'

/var/www/discourse/app/jobs/base.rb:221:in `block in perform'

/var/www/discourse/app/jobs/base.rb:217:in `each'

/var/www/discourse/app/jobs/base.rb:217:in `perform'

sidekiq-6.3.1/lib/sidekiq/processor.rb:196:in `execute_job'

sidekiq-6.3.1/lib/sidekiq/processor.rb:164:in `block (2 levels) in process'

sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:138:in `block in invoke'

/var/www/discourse/lib/sidekiq/pausable.rb:138:in `call'

sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:140:in `block in invoke'

sidekiq-6.3.1/lib/sidekiq/middleware/chain.rb:143:in `invoke'

sidekiq-6.3.1/lib/sidekiq/processor.rb:163:in `block in process'

sidekiq-6.3.1/lib/sidekiq/processor.rb:136:in `block (6 levels) in dispatch'

sidekiq-6.3.1/lib/sidekiq/job_retry.rb:112:in `local'

sidekiq-6.3.1/lib/sidekiq/processor.rb:135:in `block (5 levels) in dispatch'

sidekiq-6.3.1/lib/sidekiq.rb:39:in `block in <module:Sidekiq>'

sidekiq-6.3.1/lib/sidekiq/processor.rb:131:in `block (4 levels) in dispatch'

sidekiq-6.3.1/lib/sidekiq/processor.rb:257:in `stats'

sidekiq-6.3.1/lib/sidekiq/processor.rb:126:in `block (3 levels) in dispatch'

sidekiq-6.3.1/lib/sidekiq/job_logger.rb:13:in `call'

sidekiq-6.3.1/lib/sidekiq/processor.rb:125:in `block (2 levels) in dispatch'

sidekiq-6.3.1/lib/sidekiq/job_retry.rb:79:in `global'

sidekiq-6.3.1/lib/sidekiq/processor.rb:124:in `block in dispatch'

sidekiq-6.3.1/lib/sidekiq/logger.rb:11:in `with'

sidekiq-6.3.1/lib/sidekiq/job_logger.rb:33:in `prepare'

sidekiq-6.3.1/lib/sidekiq/processor.rb:123:in `dispatch'

sidekiq-6.3.1/lib/sidekiq/processor.rb:162:in `process'

sidekiq-6.3.1/lib/sidekiq/processor.rb:78:in `process_one'

sidekiq-6.3.1/lib/sidekiq/processor.rb:68:in `run'

sidekiq-6.3.1/lib/sidekiq/util.rb:43:in `watchdog'

sidekiq-6.3.1/lib/sidekiq/util.rb:52:in `block in safe_thread'

La ricerca di questo messaggio di errore non porta nulla qui, né… sul resto di Internet?

Qualche suggerimento?

2 Mi Piace
2

Sembra un errore relativo alla compressione della pagina? Puoi condividere un link alla pagina che stai cercando di incorporare?

3 Mi Piace
4

Grazie per averci dato un’occhiata!

Questa è la pagina esterna: Bitwig Preset: Phase-3 | Bitwiggers

E questa è la categoria in cui dovrebbero apparire gli argomenti: Bitwiggers.com - Bitwish

(Abbiamo rimosso il template dopo i test falliti.)

Questo commento aiuta? (è al di fuori della mia competenza tecnica):

Le risposte sono 200 di successo e, in base a quella discussione, sembra che non riesca a gestire quella risposta durante lo scraping di Bitwiggers, e fallisce specificamente quando tenta di gestire la compressione.

Sulla base di inflate, sembra che abbia negoziato per utilizzare lo schema di compressione deflate, mentre penso che la preferenza sarebbe gzip. Le richieste di Firefox indicano che gestirebbe entrambi, ma il server decide su gzip in quel caso.

2 Mi Piace
5

Sembra che se invio una richiesta al tuo webserver come

curl 'https://bitwiggers.com/presets/d1a7c2c7-848d-425c-9058-993317cbcc9c/' -H 'accept-encoding: deflate, gzip' -vv

ottengo una risposta compressa deflate, dove la maggior parte dei webserver, date le due opzioni, preferirebbe usare gzip. È strano.

Vedo che posso riprodurre facilmente questo errore con

require 'excon'
response = Excon.get('https://bitwiggers.com/presets/d1a7c2c7-848d-425c-9058-993317cbcc9c/',
 headers: {'accept-encoding' => 'deflate, gzip'})

# fallisce, predefinito in excon
Zlib::Inflate.new(-Zlib::MAX_WBITS).inflate(response.body)

# funziona
Zlib::Inflate.new(0).inflate(response.body)

Questo codice ha oltre 8 anni in Excon, quindi suppongo che il tuo webserver sia il colpevole, ma l’ho comunque segnalato a monte

3 Mi Piace
8

Interessante, e grazie per aver segnalato il bug. Iscritto.

Proviamo a riassumere i nostri pensieri:

Non abbiamo controllo su quella gestione, ma non pensiamo sia il webserver. Che ne dici della costruzione degli header invece? Se passati come gzip, deflate, allora la risposta dovrebbe essere compressa in gzip. Secondo le specifiche HTTP, il client dovrebbe presentare le opzioni, pesate o meno, in ordine secondo la sua preferenza. quindi se la richiesta preferisce deflate rispetto a gzip, allora riceve un deflate. Non è quindi il problema nel codice/richiesta, perché ha ricevuto una codifica che ha richiesto e non è riuscito a gestirla?

Forse il problema è correlato a questo?

C’è un “merge” e quella che sembra essere un’aspettativa per gzip?

L’amministratore dell’altro server sta esaminando come forzare gzip dalla loro parte. Tuttavia, sarebbe interessante conoscere i tuoi pensieri a riguardo.

(Per riferimento, il server è AWS API Gateway; non è qualcosa che possiamo controllare, a parte abilitare/disabilitare la compressione.)

2 Mi Piace
9

Lo sviluppatore ha risposto: Excon fails to inflate specific page · Issue #768 · excon/excon · GitHub

2 Mi Piace
10

Potrebbe qualcuno aiutarmi a tradurre la risposta dello sviluppatore di Excon? Non sono sicuro di quale sia il problema e chi potrebbe risolverlo.

Mi chiedo anche se potremmo applicare una patch locale al nostro Discourse per aggirare questo problema di gzip/deflate. Le patch locali sono dolorose, ma è ancora più doloroso avere un’integrazione di due siti con centinaia di pagine da incorporare con discussioni di Discourse in sospeso a causa di questo problema.

1 Mi Piace
11

Il maintainer di Excon ha effettuato un commit di una patch che in teoria risolve questo problema! :tada: A breve dovrebbe arrivare una nuova release di Excon, dice.

2 Mi Piace
12

E ora il maintainer di Excon ha pubblicato una nuova versione della libreria che include questa patch. :tada:

Ciò significa che possiamo aggiornare la nostra istanza subito, o Discourse sta usando il proprio repository staged per queste librerie? Ricordando l’output degli upgrade di Discourse, credo che vengano prelevati direttamente dai repository upstream, ma preferirei chiedere prima di toccare il nostro backend. :slight_smile:

1 Mi Piace
13

Ho deciso di chiedere direttamente a Discourse :slight_smile: aggiornando e controllando i log. Dopo aver visto questo

Installing excon 0.89.0
www/discourse/vendor/bundle/ruby/2.7.0/specifications/excon-0.89.0.gemspec

abbiamo riprovato e ORA L’EMBEDDING FUNZIONA!

Grazie mille @Falco per la tua segnalazione upstream. Avevi assolutamente ragione, e ho aggiunto del rumore che forse non era così utile. Mi scuso e ti ringrazio ancora.

4 Mi Piace
14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.