it-swarm.com.de

Warum kann der Browser keine gzip-Anforderung senden?

Wenn der Webserver eine gzip-Antwort senden kann, warum kann der vom Browser gesendete gzip-Request nicht gesendet werden?

66
Herman

Client und Server müssen sich darauf verständigen, wie kommuniziert werden soll. Teil davon ist, ob die Kommunikation komprimiert werden kann. HTTP wurde als Anforderungs-/Antwortmodell entwickelt, und bei der ursprünglichen Erstellung waren fast immer kleine Anfragen und möglicherweise große Antworten vorgesehen. Die Komprimierung ist nicht required, um HTTP zu implementieren. Es gibt sowohl Server als auch Clients, die dies nicht unterstützen.

Die HTTP-Komprimierung wird implementiert, indem der Client angibt, dass er die Komprimierung unterstützen kann. Wenn der Server dies in der Anforderung erkennt und die Komprimierung unterstützt, kann er die Antwort komprimieren. Um die Anforderung zu komprimieren, müsste der Client über eine "Voranforderung" verfügen, über die tatsächlich ausgehandelt wurde, dass die Anforderung komprimiert wurde OR, und es müsste eine Komprimierung als unterstützte Codierung für ALLE Anforderungen erforderlich sein.

* UPDATE Feb '17 * Es ist schon 8 Jahre her, aber @ Phil_1984_ stellt fest, dass eine dritte mögliche Lösung darin besteht, dass Client und Server die Komprimierungsunterstützung aushandeln und diese dann für nachfolgende Anforderungen verwenden. In der Tat funktionieren Dinge wie HSTS genau so mit dem Client-Caching, von dem der Server erwartet, dass er nur TLS spricht und nicht verschlüsselte Links ignoriert. HTTP wurde explizit als zustandslos entwickelt, aber wir sind an dieser Stelle noch weiter gegangen.

58
Peter Oehlert

Ein Client kann nicht im Voraus wissen, dass ein Server eine gzippte Anforderung versteht, der Server kann jedoch wissen, dass der Client eine Anfrage akzeptiert.

27
Paul Dixon

Es könnte, vorausgesetzt es könnte garantieren, dass der Server es akzeptieren würde. Dies kann bedeuten, dass eine OPTIONS-Anfrage verwendet wird.

Es gibt viele Dinge, die Webbrowser (z. B. Pipelining) tun könnten, die sie nicht tun. Webbrowser-Entwickler berücksichtigen die Auswirkungen einer Änderung auf die Kompatibilität. 

In einer heterogenen Umgebung gibt es viele verschiedene Webserver und Konfigurationen. Wenn Sie Änderungen an der Funktionsweise eines Kunden vornehmen, kann dies zu einem Bruch führen.

Möglicherweise akzeptieren nur 1% der Server gezippte Anforderungen, aber einige von ihnen geben dies zwar an, können dies jedoch nicht richtig akzeptieren. Benutzer könnten also keine Dateien auf diese Sites hochladen.

In der Vergangenheit gab es viele defekte Client/Server-Implementierungen - lange Zeit waren gzipierte Antworten in großen Webbrowsern defekt (zum Glück sind diese jetzt meistens verschwunden).

Sie erhalten also schwarze Listen mit Benutzeragenten oder Servern (oder Domänennamen), bei denen diese Optionen automatisch deaktiviert wurden. Dies ist unangenehm.

7
MarkR

Weil es nicht weiß, dass der Server es akzeptieren kann. Bei einer HTTP-Transaktion wird eine einzelne Anforderung vom Client gesendet, gefolgt von einer Antwort. Der Client sendet unter anderem, welche Codierung/Komprimierung er unterstützen kann. Der Server kann dann entscheiden, wie die Antwort komprimiert wird. Der Kunde hat diesen Luxus nicht.

3
Yuliy

Wenn Sie eine Webanwendung schreiben, gehe ich davon aus, dass Sie die Kontrolle darüber haben, was an den Client gesendet wird und was vom Client zurückgesendet wird.

Es wäre leicht genug, eine gzip-Implementierung in Javascript zu schreiben, die die Post-Daten komprimiert, die an den Server gesendet werden. Der Server könnte über einen Filter (j2ee term) verfügen, der weiß, dass Clientdaten komprimiert gesendet werden. Dieser Filter dekomprimiert die Daten und gibt sie an das Servlet (oder die Aktionsklassen in Struts) weiter, die die Daten wie üblich lesen, z. request.getParameter (...).

Dies scheint vollkommen logisch und machbar, wenn Sie die Kontrolle haben. Wie bereits in anderen Beiträgen erwähnt, können Sie sich nicht darauf verlassen, dass der Browser dies automatisch ausführt. Da Sie jedoch die Webseiten schreiben, können Sie den Browser dazu bringen, die gewünschte Komprimierung durchzuführen (mit etwas Arbeit).

Andy.

2
Andy

HTTP ist folgendermaßen aufgebaut:

  • Der Kunde sagt seine Anfrage in Klartext (einschließlich ob er komprimierte Antworten versteht)
  • Der Server antwortet mit der richtigen Codierung (komprimiert oder nicht)

ABER IN DIESEM DESIGN kann der Client keine komprimierten Anforderungen senden, da er nicht weiß, ob der Server sie im Voraus versteht.