Maximalwerte für HTTP-Header?

Question

Gibt es eine zulässige Höchstgröße für HTTP-Header? Wenn ja, wie groß ist sie? Wenn nicht, ist dies etwas, das serverspezifisch ist, oder ist der akzeptierte Standard, Header jeder Größe zuzulassen?

Answer 1

Nein, für HTTP gibt es keine Begrenzung. Die meisten Webserver begrenzen jedoch die Größe der Kopfzeilen, die sie akzeptieren. Zum Beispiel in Apache-Standardgrenze beträgt 8KB, in IIS ist 16K . Der Server gibt zurück 413 Entity Too Large Fehler, wenn die Kopfzeilengröße diese Grenze überschreitet.

Verwandte Frage: Wie groß kann ein User-Agent-String werden?

Answer 2

Wie vartec oben sagt, ist in der HTTP-Spezifikation kein Limit festgelegt, viele Server tun dies jedoch standardmäßig. Praktisch bedeutet dies, dass die untere Grenze bei 8K . Bei den meisten Servern gilt dieser Grenzwert für die Summe aus der Anforderungszeile und ALLE Kopfzeilenfelder (also halten Sie Ihre Kekse kurz).

• Apache 2.0 , 2.2 : 8K
• nginx : 4K - 8K
• IIS: variiert je nach Version , 8K - 16K
• Tomcat: variiert je nach Version , 8K - 48K (?!)

Es ist erwähnenswert, dass nginx standardmäßig die Systemseitengröße verwendet, die auf den meisten Systemen 4K beträgt. Sie können dies mit diesem kleinen Programm überprüfen:

pagesize.c:

#include <unistd.h>
#include <stdio.h>

int main() {
    int pageSize = getpagesize();
    printf("Page size on your system = %i bytes\n", pageSize);
    return 0;
}

Kompilieren mit gcc -o pagesize pagesize.c dann laufen ./pagesize . Mein Ubuntu Server von Linode informiert mich pflichtbewusst, dass die Antwort 4k lautet.

Answer 3

Hier ist die Grenze der beliebtesten Webserver

• Apache - 8K
• Nginx - 4K-8K
• IIS - 8K-16K
• Kater - 8K - 48K
• Knoten (<13) - 8K; (>13) - 16K

Answer 4

HTTP setzt keine vordefinierte Grenze für die Länge der einzelnen Header Feldes oder der Länge des Header-Abschnitts als Ganzes, wie in in Abschnitt 2.5 beschrieben. Verschiedene Ad-hoc-Beschränkungen für einzelne Header Feldlänge sind in der Praxis anzutreffen, oft abhängig von der spezifischen Feldsemantik.

HTTP-Header-Werte werden durch Serverimplementierungen eingeschränkt. Die HTTP-Spezifikation schränkt die Größe der Header nicht ein.

Ein Server, der ein Request-Header-Feld oder einen Satz von Feldern empfängt, die größer sind als er verarbeiten möchte, MUSS mit einem entsprechenden 4xx (Client Error) Statuscode antworten. Das Ignorieren solcher Header-Felder würde die Anfälligkeit des Servers für Request Smuggling-Angriffe erhöhen (Abschnitt 9.5).

Die meisten Server geben zurück 413 Entity Too Large oder ein entsprechender 4xx-Fehler, wenn dies geschieht.

Ein Client KANN empfangene Header-Felder verwerfen oder abschneiden, die größer sind als der Client verarbeiten möchte, wenn die Feldsemantik so ist so beschaffen ist, dass der/die verworfene(n) Wert(e) sicher ignoriert werden kann/können, ohne die ohne den Nachrichtenaufbau oder die Antwortsemantik zu verändern.

Wenn die Größe der HTTP-Header nicht begrenzt ist, bleibt der Server anfällig für Angriffe und kann seine Kapazität zur Bewältigung des organischen Datenverkehrs einschränken.

Quelle

Answer 5

RFC 6265 aus dem Jahr 2011 schreibt spezifische Einschränkungen für Cookies vor.

https://www.rfc-editor.org/rfc/rfc6265 6.1. Grenzwerte

Praktische User-Agent-Implementierungen haben Grenzen für die Anzahl und Größe der Cookies, die sie speichern können. Benutzeragenten für den allgemeinen Gebrauch SOLLTEN jede der folgenden Mindestfunktionen bieten:

o Mindestens 4096 Bytes pro Cookie (gemessen an der Summe der Länge von Name, Wert und Attributen des Cookies).

o Mindestens 50 Cookies pro Domain.

o Mindestens 3000 Kekse insgesamt.

Server SOLLTEN so wenige und so kleine Cookies wie möglich verwenden, um zu vermeiden diese Implementierungsgrenzen zu erreichen und das Netzwerk zu minimieren Bandbreite zu minimieren, da der Cookie-Header in jeder Anfrage enthalten ist.

Die Server SOLLTEN sich ordnungsgemäß zurückentwickeln, wenn der Benutzer-Agent nicht in der Lage ist ein oder mehrere Cookies im Cookie-Header nicht zurückgibt, weil der Benutzer-Agent jederzeit auf Anweisung des Benutzers ein Cookie löschen kann.

--

Das Zielpublikum des RFC ist das, was von einem User-Agent oder einem Server unterstützt werden muss. Um Ihren Server so einzustellen, dass er das unterstützt, was der Browser erlaubt, müssten Sie 4096*50 als Grenze konfigurieren. Wie der folgende Text andeutet, scheint dies weit über das hinauszugehen, was für eine typische Webanwendung benötigt wird. Es wäre sinnvoll, die aktuelle Grenze und die in RFC beschriebene Obergrenze zu verwenden und die Auswirkungen der höheren Konfiguration auf Speicher und IO zu vergleichen.