HTTP-RPC-Schnittstelle: Falsches Content-Encoding

[jkan]

Hallo,

beim Aufruf der HTTP-RPC-Schnittstelle wird in der Version 4.0.6.28 oder schon früher das falsche Content-Encoding zurückgegeben bzw. die zurückgegeben Daten falsch komprimiert:

Code: Alles auswählen

jk@opsis01:~# wget --post-data '{ "id": 1, "method": "getOpsiInformation_hash", "params": [] }' --no-check-certificate https://localhost:4447/rpc --http-user=userdesk --http-password=****** -S -O out.raw
--2015-10-20 13:35:09--  https://localhost:4447/rpc
Auflösen des Hostnamen »localhost (localhost)«... 127.0.0.1
Verbindungsaufbau zu localhost (localhost)|127.0.0.1|:4447... verbunden.
WARNUNG: Dem Zertifikat von »localhost« wird nicht vertraut.
WARNUNG: Das Zertifikat von »»localhost«« wurde von einem unbekannten Austeller herausgegeben.
Der Zertifikat-Eigentümer paßt nicht zum Hostname »»localhost««.
HTTP-Anforderung gesendet, warte auf Antwort...
  HTTP/1.1 401 Unauthorized
  Date: Tue, 20 Oct 2015 11:35:09 GMT
  Content-Length: 219
  Content-Type: text/html;charset=utf-8
  WWW-Authenticate: basic realm="OPSI Service"
  Server: Twisted/12.0.0 TwistedWeb/[OPSI.web2, version 0.2.0]
Wiederverwendung der bestehenden Verbindung zu localhost:4447.
HTTP-Anforderung gesendet, warte auf Antwort...
  HTTP/1.1 200 OK
  Content-Length: 94
  Content-Encoding: gzip
  Set-Cookie: OPSISID=I0l7rDEsLCAQAgT3Z9rVomtynkHTyD9p; path=/
  Accept-Ranges: bytes
  Server: Twisted/12.0.0 TwistedWeb/[OPSI.web2, version 0.2.0]
  Date: Tue, 20 Oct 2015 11:35:10 GMT
  Content-Type: gzip-application/json;charset=utf-8
Länge: 94 [gzip-application/json]
In »»out.raw«« speichern.

In diesem Testaufruf wird als Content-Encoding gzip zurückgegeben. Ein Entpacken der Daten mit gzip schlägt aber fehl:

Code: Alles auswählen

jk@opsis01:~# gzip -dc < out.raw

gzip: stdin: not in gzip format

Das Entpacken mit zlib funktioniert allerdings:

Code: Alles auswählen

root@opsis01:~# openssl zlib -d < out.raw
{"id": 1, "result": {"opsiVersion": "4.0.6.28", "realmodules": {}, "modules": {"valid": false}}, "error": null}

Es handelt sich also um deflate-Kompression, obwohl das anders im Header steht.
Wir würden ungern einen entsprechenden Workaround in unserer Anwendung einbauen.
Betriebssystem ist Debian Jessie.

[n.wenselowski]

Hallo,

das Problem ist hier zuerst gemeldet worden und dabei gibt es noch ein paar Infos.
Es ist seit 4.0.6 möglich, dass der Dienst korrekte Antworten zurückliefert, aber dieses Verhalten muss, damit eventuell vorhandene alte Clients weiterhin ihre Arbeit verrichten können, explizit aktiviert werden. Mehr Informationen dazu gibt es in den Releasenotes, wenn man nach "RFC 2616" sucht.

Ich würde generell empfehlen die Header zu prüfen:
Kommt im Header als MIME-Type irgendwas mit gzip-application zurück, wird deflate geliefert.
Ansonsten kann man sich auf den content-encoding-Header verlassen.

Hope that helps


Viele Grüße

Niko