JS-Einbettung schlägt fehl mit "Job exception: ungültige gespeicherte Blocklängen (Zlib::DataError)"

icaria36 · 22. November 2021 um 17:30

Hallo, wir können JS-Einbettung in unserem Setup nicht zum Laufen bringen. Ich habe alle anderen ähnlichen Themen gelesen und diese Einbettung in einem völlig anderen Projekt bereits zum Laufen gebracht. Dieses hier scheint etwas anders zu sein…

Auf der externen Website ist nur unser Logo gefolgt von „Diskussion wird geladen…“ zu sehen.

Auf Discourse werden keine Themen erstellt, auch wenn das Fehlerprotokoll zeigt, dass die Anfragen eingehen.

Wir haben die URLs überprüft. Wir haben auch versucht, eine statische URL (anstelle einer Variablen) hinzuzufügen. Nichts.

Das Discourse-Fehlerprotokoll enthält diesen Fehler:

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'

Die Suche nach dieser Fehlermeldung bringt hier nichts, weder im… Rest des Internets?

Irgendwelche Hinweise?

Falco · 22. November 2021 um 17:40

Sieht aus wie ein Fehler im Zusammenhang mit der Seitenkomprimierung? Können Sie einen Link zu der Seite teilen, die Sie einbetten möchten?

icaria36 · 22. November 2021 um 18:47

Vielen Dank für Ihre Prüfung!

Dies ist die externe Seite: Bitwig Preset: Phase-3 | Bitwiggers

Und dies ist die Kategorie, in der die Themen erscheinen sollen: Bitwiggers.com - Bitwish

(Wir haben die Vorlage nach den fehlgeschlagenen Tests entfernt.)

Hilft dieser Kommentar? (das ist außerhalb meiner technischen Liga):

Die Antworten sind erfolgreich 200er, und basierend auf dieser Diskussion scheint es, dass es beim Scrapen von Bitwiggers nicht in der Lage ist, diese Antwort zu verarbeiten, und es scheitert speziell bei dem Versuch, die Komprimierung zu verarbeiten.

Basierend auf inflate scheint es, dass es die deflate-Komprimierung vereinbart hat, während ich denke, dass die bevorzugte gzip wäre. Firefox-Anfragen deuten darauf hin, dass es beides handhaben würde, aber der Server entscheidet in diesem Fall auf gzip.

Falco · 22. November 2021 um 20:41

Es sieht so aus, als ob ich eine deflate-komprimierte Antwort erhalte, wenn ich eine Anfrage an Ihren Webserver sende wie

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

wobei die meisten Webserver, wenn sie die beiden Optionen erhalten, gzip bevorzugen würden. Das ist seltsam.

Ich sehe, dass ich diesen Fehler leicht reproduzieren kann mit

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

# schlägt fehl, Standard in excon
Zlib::Inflate.new(-Zlib::MAX_WBITS).inflate(response.body)

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

Dieser Code ist über 8 Jahre alt in Excon, daher vermute ich, dass Ihr Webserver hier schuld ist, aber ich habe es trotzdem an den Betreuer gemeldet

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 · 22. November 2021 um 21:17

Interessant, und danke für die Meldung des Fehlers. Abonniert.

Versuchen wir, unsere Gedanken zusammenzufassen:

Wir haben keine Kontrolle über diese Handhabung, aber wir glauben nicht, dass es am Webserver liegt. Was ist mit der Konstruktion der Header stattdessen? Wenn sie als gzip, deflate übergeben werden, sollte die Antwort komprimiert werden. Gemäß den HTTP-Spezifikationen sollte der Client die Optionen, gewichtet oder nicht, in der Reihenfolge seiner Präferenz angeben. Wenn die Anfrage also deflate gegenüber gzip bevorzugt, erhält sie deflate. Liegt das Problem dann nicht im Code/in der Anfrage, weil sie eine Kodierung erhalten hat, nach der sie gefragt hat, und diese nicht verarbeiten konnte?

Vielleicht hängt das Problem damit zusammen?

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

Es gibt ein “merge” und was wie eine Erwartung für gzip aussieht?

Der Administrator des anderen Servers prüft, wie gzip auf seiner Seite erzwungen werden kann. Dennoch wäre es interessant, Ihre Gedanken dazu zu erfahren.

(Zur Referenz: Der Server ist AWS API Gateway; wir haben keine Kontrolle darüber, außer die Komprimierung zu aktivieren/deaktivieren.)

icaria36 · 28. November 2021 um 14:28

Der Entwickler hat geantwortet: Excon fails to inflate specific page · Issue #768 · excon/excon · GitHub

icaria36 · 2. Dezember 2021 um 21:58

Könnte mir jemand bei der Übersetzung der Antwort des Excon-Entwicklers helfen? Ich bin mir nicht sicher, wo das Problem liegt und wer es beheben könnte.

Ich frage mich auch, ob wir einen lokalen Patch auf unser Discourse anwenden könnten, um dieses gzip/deflate-Problem zu umgehen. Lokale Patches sind schmerzhaft, aber es ist noch schmerzhafter, eine Integration von zwei Websites mit Hunderten von Seiten zu haben, die wegen dieses Problems mit eingebetteten Discourse-Diskussionen blockiert ist.

icaria36 · 5. Dezember 2021 um 19:24

Der Excon-Maintainer hat einen Patch committet, der dieses Problem theoretisch lösen sollte! Eine neue Excon-Version sollte bald erscheinen, sagt er.

icaria36 · 8. Dezember 2021 um 08:58

Und jetzt hat der Excon-Maintainer eine neue Version der Bibliothek veröffentlicht, die diesen Patch enthält.

Bedeutet das, dass wir unsere Instanz sofort aktualisieren können, oder verwendet Discourse sein eigenes Staging-Repository für diese Bibliotheken? Wenn ich mich an die Ausgabe von Discourse-Upgrades erinnere, glaube ich, dass sie direkt aus Upstream-Repositorys bezogen werden, aber ich frage lieber nach, bevor ich unseren Backend anfasse.

icaria36 · 10. Dezember 2021 um 21:56

Ich habe mich entschieden, Discourse direkt zu fragen indem ich ein Upgrade durchgeführt und die Protokolle überprüft habe. Nachdem ich Folgendes gesehen habe:

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

haben wir es erneut versucht und JETZT FUNKTIONIERT DAS EINBETTEN!

Vielen Dank, @Falco, für deinen Bericht an die Entwickler. Du hattest absolut Recht, und ich habe einige Dinge hinzugefügt, die vielleicht nicht so nützlich waren. Meine Entschuldigung und nochmals vielen Dank.

system · 9. Januar 2022 um 21:56

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

Thema		Antworten	Aufrufe
Cannot get embedding to work Support	11	2508	31. August 2021
Comments not embedding, 500 Error Feature pr-welcome	15	1947	3. Oktober 2017
JavaScript embed won’t display embed, console log shows: Failed to execute postMessage on DOMWindow… Support	19	5671	26. April 2022
Discourse Comments stuck on "Loading..." Support	22	1984	18. September 2024
Some pages on my site won't fully embed comments Support	11	1500	27. September 2017

JS-Einbettung schlägt fehl mit "Job exception: ungültige gespeicherte Blocklängen (Zlib::DataError)"

Verwandte Themen