bug report Worker.py: Encoding announced as gzip, but deflate is used

[justcoding]

Es geht um die Schnittstelle

Code: Alles auswählen

/rpc?{methoden und parameter} 

Wer diese Schnittstelle mit Angular oder jQuery benutzen will, wird zunächst von der verwendeten Kompression eingeholt. Akzeptiert der Browser gzip, wird komprimiert, allerdings mit deflate.

Ursache ist ein kleiner bug on Worker.py: die Kompression wird als gzip angekündigt, tatsächlich wird zlib.compress verwendet:

Code: Alles auswählen

 result.stream = stream.IByteStream(zlib.compress(toJson(response).encode('utf-8'), level)) 

(use the source, luke )
zlib.compress kann indes nur deflate, und nicht gzip.

Weiter vorn werden die Browser capabilities abgefragt, und zwar erst deflate, und dann gzip. Kann der Browser beides, wird gzip gemeldet, und das finden die Browser (alle) nicht witzig.
Nebenbei bemerkt scheint es sowohl dem OPSI Client Agent als auch dem Winst sch...egal zu sein, ob deflate, gzip oder nix angemeldet wird - sie rechnen mir deflate und basta. Wird nämlich die Kompression ganz abgeschaltet, kommen die Browser klar, aber der Winst bricht ab. Nich gut

Mein Patch also:

Code: Alles auswählen

--- a/Service/Worker.py
+++ b/Service/Worker.py
@@ -561,10 +561,11 @@ class WorkerOpsiJsonRpc(WorkerOpsi):
                
                encoding = None
                try:
-                       if ('deflate' in self.request.headers.getHeader('Accept-Encoding')):
-                               encoding = 'deflate'
+                       # UH 2015-04 the encoding done by zlib below does deflate OLNY - so please answer "deflate"
                        if ('gzip' in self.request.headers.getHeader('Accept-Encoding')):
                                encoding = 'gzip'
+                       if ('deflate' in self.request.headers.getHeader('Accept-Encoding')):
+                               encoding = 'deflate'
                except Exception, e:
                        pass
                if not encoding:

Die Erkennung der Accept-Encoding Header wird umgekehrt. Jetzt wird (korrekt) deflate gemeldet, wenn deflate akzeptiert wird. Der Browser kommt klar, Winst auch.
(Ungelöst: wenn der Browser nur gzip akzeptiert, wird weiter gzip gemeldet, aber deflate gesendet. Vielleicht sollte man gzip ganz streichen - was Winst dan macht, habe ich nicht getestet.)

happy patching!

[n.wenselowski]

Guten Morgen,

vielen Dank für Bugreport samt Patch!

Ich habe das intern als Ticket aufgenommen und hoffe das ganze für 4.0.6 ausliefern zu können.


Viele Grüße

Niko

[_NiHiL_]

Guten Morgen,

ich konnte das Problem umgehen mit "Accept-Encoding: identity".
Dann werden die Nachrichten zwar nicht mehr komprimiert, aber der HttpClient bekommt eine lesbare Response (Content-Type: application/json;charset=utf-8).

Bei „Accept-Encoding: deflate“ kommt der falsche Content-Type zurück (gzip-application/json;charset=utf-8).
Wurde ja schon geschrieben

Auch Versuche den HttpResponeInterceptor zu überschreiben, den Header zu ignorieren und die Response stumpf mit dem Java-Inflater zu entpacken, sind gescheitert.
Ganz egal ob ich den Content mit
nowrap = true // GZIP
oder
nowrap = false // PKZIP / GZIP ohne ZLIB
dekomprimiert habe.
Allerdings ist der Content in irgendeiner Form komprimiert. Das konnte ich sehen

VG, Jan

[n.wenselowski]

Moin,

ich habe mir das ganze angeschaut und glaube das Problem ist eigentlich nicht die Reihenfolge, sondern dass später, egal welches Encoding (von gzip / deflate) gesetzt ist, zlib.compress verwendet wird.
Es sollte aber bei "deflate" zlib.compress verwendet werden, bei "gzip" korrekterweise mittels gzip komprimierte Daten. Einwände?

Eine heikle Ecke, besonders da justcoding schon gemerkt hat, dass andere Komponenten möglicherweise Probleme mit dem geänderten Verhalten bekommen.


Viele Grüße

Niko

Memo an mich selbst: RFC 2616: Accept-Encoding, RFC 2616: Content Encodings.

[justcoding]

Moin,

ich habe mir das ganze angeschaut und glaube das Problem ist eigentlich nicht die Reihenfolge, sondern dass später, egal welches Encoding (von gzip / deflate) gesetzt ist, zlib.compress verwendet wird.
Es sollte aber bei "deflate" zlib.compress verwendet werden, bei "gzip" korrekterweise mittels gzip komprimierte Daten. Einwände?

Eine heikle Ecke, besonders da justcoding schon gemerkt hat, dass andere Komponenten möglicherweise Probleme mit dem geänderten Verhalten bekommen.

Guter Einwand: nicht um die Reihenfolge der Auswertung geht es. Die Frage ist eher: warum wird in Worker.py auf Accept-Encoding "gzip" überhaupt reagiert? Da beschlich mich die Vermutung, daß opsiclientagent oder Winst möglicherweise "gzip" anfordern, und "deflate" erwarten könnten, nachdem Winst schon mit einem Patch für Worker.py, der einfach immer unkomprimiert geantwortet hat, nicht klar kam (!).
Gern mal ausprobieren, "gzip" ganz zu ignorieren. Aber dann mit Regression über alle möglichen Clients.. Das habe ich mir zunächst gespart.

happy coding!

[n.wenselowski]

Mooooin

Ich habe mal das allmächtige SVN kontaktiert und habe folgende Erkenntnisse:
Bis Mitte 2011 wurde bei Accept-Encoding gzip das ganze deflatet. Anderes gab es nicht. Ab dann wurde eingeführt, dass auch deflate kommen kann - hier bleibt es beim deflate. Ursache für die Änderung war laut Commit-Message, dass Firefox sich (richtigerweise) beschwerte, wenn da plötzlich als Encoding gzip gemeldet wurde, aber der Inhalt deflated zurück kam.

Wegen winst (und natürlich auch Configed), werde ich noch mal mit den Kollegen sprechen. Ich bin hier lieber einmal zu zögerlich bei einer Änderung, bevor ich es zwar korrekt implementiere aber als Seiteneffekt vielleicht große Umgbungen mit alten Client-Versionen lahm lege


Viele Grüße

Niko

[n.wenselowski]

Hallo,

hier wird gerade eine neue Version von python-opsi gebaut, in welcher der Fehler hoffentlich behoben ist und der den alten Clients die Daten so ausliefert, wie sie es erwarten. Nach der Installation des Pakets muss der Dienst opsiconfd neu gestartet werden.
Das ist eine experimentelle Version, weshalb sie nicht produktiv eingesetzt werden sollte!

Ich bitte um Feedback!
Dabei ist für mich interessant welche Version von Python eingesetzt wird, auf welchem OS der opsiconfd läuft und welche Version configed/opsi-client-agent/opsi-winst haben.

Code: Alles auswählen

python -V
lsb_release -a
opsi-package-manager --list "opsi-winst" "opsi-client-agent" "opsi-configed"

Viele Grüße

Niko

[n.wenselowski]

Hallo,

FYI: mit 4.0.6 (momentan in Testing) kommt der Fix.
Da es aber Probleme mit alten Komponenten geben kann, muss er explizit aktivert werden. Wie das geht steht in den Releasenotes zu 4.0.6.
Ab 4.0.6 kommen unsere Komponenten auch mit korrektem und inkorrektem Verhalten klar.


Viele Grüße

Niko