JS embed échoue avec "Job exception: invalid stored block lengths (Zlib::DataError)"

icaria36 · Novembre 22, 2021, 5:30

Bonjour, nous n’arrivons pas à faire fonctionner l’intégration JS dans notre configuration. J’ai lu tous les autres sujets similaires et j’ai déjà réussi à faire fonctionner cette intégration dans un projet complètement différent par le passé. Celui-ci semble être différent…

Sur le site externe, seul notre logo est visible, suivi de “loading discussion…”.

Sur Discourse, aucun sujet n’est créé, même si le journal d’erreurs indique que les requêtes arrivent.

Nous avons vérifié les URL. Nous avons également essayé d’ajouter une URL statique (au lieu d’une variable). Rien.

Le journal d’erreurs de Discourse contient cette erreur :

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 recherche de ce message d’erreur n’apporte rien ici, ni sur… le reste d’Internet ?

Des indices ?

Falco · Novembre 22, 2021, 5:40

On dirait une erreur liée à la compression de la page ? Pouvez-vous partager un lien vers la page que vous essayez d’intégrer ?

icaria36 · Novembre 22, 2021, 6:47

Merci de vous pencher sur ce problème !

Voici la page externe : Bitwig Preset: Phase-3 | Bitwiggers

Et voici la catégorie où les sujets devraient apparaître : Bitwiggers.com - Bitwish

(Nous avons supprimé le modèle après les tests échoués.)

Ce commentaire vous aide-t-il ? (ceci dépasse mes compétences techniques) :

Les réponses sont des succès 200, et d’après cette discussion, il semble qu’il échoue à gérer cette réponse lors du scraping de Bitwiggers, et il échoue spécifiquement lors de la tentative de gestion de la compression.

D’après inflate, il semble qu’il ait négocié pour utiliser le schéma de compression deflate, alors que je pense que le préféré serait gzip. Les requêtes de Firefox indiquent qu’il gérerait les deux, mais le serveur décide de gzip dans ce cas.

Falco · Novembre 22, 2021, 8:41

Il semble que si j’envoie une requête à votre serveur web comme ceci :

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

Je reçois une réponse compressée par deflate, alors que la plupart des serveurs web, lorsqu’ils reçoivent les deux options, préfèrent utiliser gzip. C’est étrange.

Je vois que je peux facilement reproduire cette erreur avec :

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

# échoue, par défaut dans excon
Zlib::Inflate.new(-Zlib::MAX_WBITS).inflate(response.body)

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

Ce code a plus de 8 ans dans Excon, donc je suppose que votre serveur web est en faute, mais je l’ai signalé en amont de toute façon :

github.com/excon/excon

Excon fails to inflate specific page

opened 08:40PM - 22 Nov 21 UTC

closed 01:45PM - 05 Dec 21 UTC

xfalcox

Just got a bug report on discourse about an error that I tracked back to excon. … ``` require 'excon' response = Excon.get('https://bitwiggers.com/presets/d1a7c2c7-848d-425c-9058-993317cbcc9c/', headers: {'accept-encoding' => 'deflate, gzip'}) # fails, default in excon at Zlib::Inflate.new(-Zlib::MAX_WBITS).inflate(response.body) #works Zlib::Inflate.new(0).inflate(response.body) ``` The default inflate is set at https://github.com/excon/excon/blob/bbb5bd791d0bb2251593b80e3bce98dbec6e8f24/lib/excon/middlewares/decompress.rb#L23 I don't know if the webserver is providing an invalid response or if excon is at fault here. Any ideas?

icaria36 · Novembre 22, 2021, 9:17

Intéressant, et merci d’avoir signalé le bug. Abonné.

Essayons de résumer nos réflexions :

Nous n’avons aucun contrôle sur cette gestion, mais nous ne pensons pas que ce soit le serveur web. Qu’en est-il de la construction des en-têtes à la place ? Si passé comme gzip, deflate, alors la réponse devrait être compressée. Selon les spécifications HTTP, le client doit présenter les options, pondérées ou non, dans l’ordre selon sa préférence. donc si la requête préfère deflate à gzip, alors elle reçoit un deflate. N’est-ce pas alors le problème dans le code/la requête, car elle a reçu un encodage qu’elle a demandé et n’a pas réussi à le gérer ?

Peut-être que le problème est lié à ceci ?

github.com/discourse/discourse

lib/final_destination.rb

53abcd825


      
            nil
          end
          
          protected
          
          def safe_get(uri)
            result = nil
            unsafe_close = false
          
            safe_session(uri) do |http|
              headers = request_headers.merge(
                'Accept-Encoding' => 'gzip',
                'Host' => uri.host
              )
          
              req = Net::HTTP::Get.new(uri.request_uri, headers)
          
              http.request(req) do |resp|
                if Net::HTTPRedirection === resp
                  result = :redirect, [resp['location'], resp['Set-Cookie']]
                end

Il y a un “merge” et ce qui semble être une attente pour gzip ?

L’administrateur de l’autre serveur examine comment forcer gzip de leur côté. Néanmoins, il serait intéressant de connaître vos réflexions à ce sujet.

(Pour référence, le serveur est AWS API Gateway ; ce n’est pas quelque chose que nous contrôlons, à part activer/désactiver la compression.)

icaria36 · Novembre 28, 2021, 2:28

Le développeur a répondu : Excon fails to inflate specific page · Issue #768 · excon/excon · GitHub

icaria36 · Décembre 2, 2021, 9:58

Quelqu’un pourrait-il aider à traduire la réponse du développeur Excon ? Je ne suis pas sûr d’où vient le problème et qui pourrait le résoudre.

Je me demande aussi si nous pourrions appliquer un correctif local à notre Discourse pour contourner ce problème de gzip/deflate. Les correctifs locaux sont douloureux, mais il est encore plus douloureux d’avoir une intégration de deux sites avec des centaines de pages à intégrer avec des discussions Discourse en attente à cause de ce problème.

icaria36 · Décembre 5, 2021, 7:24

Le mainteneur d’Excon a commité un correctif qui, en théorie, résout ce problème ! Une nouvelle version d’Excon devrait bientôt arriver, dit-il.

icaria36 · Décembre 8, 2021, 8:58

Et maintenant le mainteneur d’Excon a publié une nouvelle version de la bibliothèque incluant ce correctif.

Cela signifie-t-il que nous pouvons mettre à jour notre instance immédiatement, ou Discourse utilise-t-il son propre dépôt intermédiaire pour ces bibliothèques ? En me souvenant de la sortie des mises à niveau de Discourse, je pense qu’elles sont extraites directement des dépôts en amont, mais je préférerais demander avant de toucher à notre backend.

icaria36 · Décembre 10, 2021, 9:56

J’ai décidé de demander directement à Discourse en mettant à jour et en vérifiant les journaux. Après avoir vu ceci

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

nous avons réessayé et MAINTENANT L’INTÉGRATION FONCTIONNE !

Merci beaucoup @Falco pour votre rapport en amont. Vous aviez absolument raison, et j’ai ajouté du bruit qui n’était peut-être pas très utile. Mes excuses, et merci encore.

system · Janvier 9, 2022, 9:56

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

Sujet		Réponses	Vues
Cannot get embedding to work Support	11	2509	Août 31, 2021
Comments not embedding, 500 Error Feature pr-welcome	15	1947	Octobre 3, 2017
JavaScript embed won’t display embed, console log shows: Failed to execute postMessage on DOMWindow… Support	19	5671	Avril 26, 2022
Discourse Comments stuck on "Loading..." Support	22	1984	Septembre 18, 2024
Some pages on my site won't fully embed comments Support	11	1500	Septembre 27, 2017

JS embed échoue avec "Job exception: invalid stored block lengths (Zlib::DataError)"

Sujets connexes