Frage Ist es möglich, HTTP-Komprimierung für Anfragen zu aktivieren?


Ich sehe viele Informationen über die Aktivierung der HTTP-Komprimierung für Serverantworten, aber was ist mit eingehenden Anfragen? Wäre es für die Browser nicht sinnvoll, große Formularposts vor dem Senden an den Server zu komprimieren?

Ein anderes Beispiel ist ein REST-Webdienst, den wir verwenden. Wir müssen häufige PUT-Anfragen mit großen XML-Dateien (10+ MB) senden und würden auf jeden Fall einige Bandbreiten- / Geschwindigkeitsvorteile auf beiden Seiten sehen.

Ist das also ein gelöstes Problem auf der Serverseite oder muss jede Webanwendung individuell damit umgehen?


32
2017-08-20 16:00


Ursprung




Antworten:


Zu PUT Daten zum komprimierten Server müssen Sie den Anfragetext komprimieren und den Content-Encoding: gzip Header. Der Header selbst muss unkomprimiert sein. Es ist dokumentiert in mod_deflate:

Das mod_deflate-Modul bietet auch a   filter zum dekomprimieren eines gzip   komprimierter Anfragetext Damit   Aktivieren Sie diese Funktion   Setzen Sie den DEFLATE Filter in die   Eingabefilterkette mit   SetInputFilter oder AddInputFilter.

...

Jetzt, wenn eine Anfrage eine enthält   Content-Encoding: gzip-Header, der   Körper wird automatisch sein   dekomprimiert. Wenige Browser haben die   Fähigkeit, Anfrage Körper zu gzip.   Allerdings einige spezielle Anwendungen   tatsächlich Supportanfrage   Komprimierung, zum Beispiel einige WebDAV   Kunden.

Und ein Artikel, der es beschreibt, ist Hier:

Also, wie machst du das? Hier ist ein Klappentext,   wieder von der Quelle mod_deflate   Code: nur Arbeit an Hauptanfrage / Nr   Unteranfragen. Das bedeutet, dass das Ganze   Körper der Anfrage muss gzip sein   komprimiert, wenn wir uns dafür entscheiden, es zu benutzen   ist es nicht möglich nur die zu komprimieren   Teil, der zum Beispiel die Datei enthält   in einer mehrteiligen Anfrage.

Unabhängig davon kann ein Browser anfordern, dass der Inhalt der Serverantwort durch Einstellung komprimiert wird Accept-Encoding Kopfzeile gemäß Hier:

GET /index.html HTTP/1.1
Host: www.http-compression.com
Accept-Encoding: gzip
User-Agent: Firefox/1.0

Dies wird komprimierte Daten an den Browser zurückgeben.


24
2017-08-20 16:14



+1 N. Du schreibst you must compress the whole request, inclusive of header. Aber die HTTP-Header dürfen nicht komprimiert werden. Die einzige Sache, die komprimiert werden muss (vollständig, wie der Artikel, den Sie richtig zitieren), ist der HTTP-Körper. - Eugene Beresovsky
Das ist falsch: Accept-Encoding teilt dem Server mit, welche Komprimierung der Client unterstützt. Der Header Content-Encoding beschreibt die Kompression des Körpers. - maaartinus
@ maaartinus siehe ersten Zitat zweiten Absatz. Ich habe die Antwort aus Gründen der Klarheit neu organisiert. - Andy


Beantworten des Teils über komprimierte Anfragen, nicht Antworten: Ja, es ist möglich, auch wenn es nicht weit verbreitet erscheint. Die clientseitige App muss den entsprechenden Content-Encoding-Header festlegen. Wie für die serverseitige App gibt es 2 Möglichkeiten:

  1. Die App unterstützt das erneute Auffüllen des Anfragekörpers. Eine Beispielbibliothek, die dies kann, ist die phpxmlrpc-Datei.

  2. Der Webserver bläht den Antworttext auf, bevor er ihn an die App weitergibt. Dies ist möglich unter Verwendung von z.B. der mod_deflate-Filter von Apache und das Einrichten eines inputFilter


4
2017-07-22 13:34





Nicht nativ von irgendeinem Browser, den ich kenne, müssten Sie ein Plugin finden, das es für Sie tun würde. Sie müssen im Grunde den Content-Encoding-HTTP-Header festlegen, damit der Server weiß, wie die Anfrage ankommt. Der Server muss natürlich mit dieser Codierung umgehen können.


2
2017-08-20 16:05





Dies ist NICHT erlaubt. Gemäß der HTTP-Spezifikation (RFC 2616) gehört Content-Encoding NICHT zu den möglichen Anfrage-Header-Feldern. Daher ist es nicht möglich, den Entity-Body der Anfrage zu komprimieren, da es keinen legalen Weg gibt, den Server darüber zu informieren. Eine beliebige Komprimierung des Anforderungshauptteils erfolgt nur als nicht standardmäßige Erweiterung.


1
2017-07-20 18:55



Diese Antwort ist falsch RFC 2616 erwähnt dies ausdrücklich If the content-coding of an entity in a request message is not acceptable to the origin server, the server SHOULD respond with a status code of 415 (Unsupported Media Type). weiterhin angezeigt durch Request and Response messages MAY transfer an entity if not otherwise restricted by the request method und Content-Encoding als eine Option in aufgeführt werden entity-header - PeterT