Antworten:
Nein, HTTP definiert keine Begrenzung. Die meisten Webserver begrenzen jedoch die Größe der von ihnen akzeptierten Header. In Apache beträgt das Standardlimit beispielsweise 8 KB, in IIS 16 KB . Der Server gibt einen 413 Entity Too LargeFehler zurück, wenn die Größe der Header diesen Grenzwert überschreitet.
Verwandte Frage: Wie groß kann eine Benutzeragentenzeichenfolge werden?
Wie oben von vartec angegeben, definiert die HTTP-Spezifikation kein Limit, jedoch standardmäßig viele Server. Dies bedeutet praktisch, dass die Untergrenze 8 K beträgt . Bei den meisten Servern gilt diese Begrenzung für die Summe der Felder für die Anforderungszeile und ALLE Header (halten Sie Ihre Cookies also kurz).
Es ist erwähnenswert, dass nginx standardmäßig die Systemseitengröße verwendet, die auf den meisten Systemen 4 KB beträgt. Sie können mit diesem winzigen 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.cdann ausführen ./pagesize. Mein Ubuntu-Server von Linode informiert mich pflichtbewusst über die Antwort 4k.
LimitRequestLineund LimitRequestFieldSizegilt für diese ... nicht für die "Summe von ..."
HTTP begrenzt die Länge jedes Headerfelds oder die Länge des Headerabschnitts insgesamt nicht vordefiniert, wie in Abschnitt 2.5 beschrieben. In der Praxis gibt es verschiedene Ad-hoc-Einschränkungen für die Länge einzelner Headerfelder, häufig abhängig von der spezifischen Feldsemantik.
HTTP-Header-Werte werden durch Serverimplementierungen eingeschränkt. Die HTTP-Spezifikation schränkt die Headergröße nicht ein.
Ein Server, der ein Anforderungsheaderfeld oder eine Reihe von Feldern empfängt, die größer sind als er verarbeiten möchte, MUSS mit einem geeigneten 4xx-Statuscode (Clientfehler) antworten. Das Ignorieren solcher Headerfelder würde die Anfälligkeit des Servers erhöhen, Schmuggelangriffe anzufordern (Abschnitt 9.5).
Die meisten Server geben 413 Entity Too Largein diesem Fall einen entsprechenden 4xx-Fehler zurück.
Ein Client kann empfangene Headerfelder verwerfen oder abschneiden, die größer sind, als der Client verarbeiten möchte, wenn die Feldsemantik so ist, dass die abgelegten Werte sicher ignoriert werden können, ohne den Nachrichtenrahmen oder die Antwortsemantik zu ändern.
Die Größe des nicht begrenzten HTTP-Headers hält den Server Angriffen ausgesetzt und kann seine Kapazität zur Bereitstellung von organischem Datenverkehr verringern.
Ich fand auch heraus, dass in einigen Fällen der Grund für 502/400 bei vielen Headern in einer großen Anzahl von Headern ohne Rücksicht auf die Größe liegen könnte. aus den Dokumenten
tune.http.maxhdr Legt die maximale Anzahl von Headern in einer Anforderung fest. Wenn eine Anforderung eine Anzahl von Headern enthält, die größer als dieser Wert sind (einschließlich der ersten Zeile), wird sie mit dem Statuscode "400 Bad Request" abgelehnt. Ebenso werden zu große Antworten mit "502 Bad Gateway" blockiert. Der Standardwert ist 101, was für alle Verwendungen ausreicht, wenn man bedenkt, dass der weit verbreitete Apache-Server dasselbe Limit verwendet. Es kann nützlich sein, diese Grenze weiter zu verschieben, damit eine fehlerhafte Anwendung vorübergehend funktioniert, wenn sie behoben ist. Beachten Sie, dass jeder neue Header für jede Sitzung 32 Bit Speicher benötigt. Schieben Sie diese Grenze also nicht zu hoch.
https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#3.2-tune.http.maxhdr