Odpowiedzi:
Nie, HTTP nie określa żadnego limitu. Jednak większość serwerów WWW ogranicza rozmiar akceptowanych nagłówków. Na przykład w Apache domyślny limit to 8 KB, w IIS 16 KB . Serwer zwróci 413 Entity Too Largebłąd, jeśli rozmiar nagłówków przekroczy ten limit.
Powiązane pytanie: Jak duży może być ciąg agenta użytkownika?
Jak mówi vartec powyżej, specyfikacja HTTP nie określa limitu, jednak wiele serwerów domyślnie. Oznacza to, że praktycznie rzecz biorąc, dolna granica wynosi 8K . W przypadku większości serwerów limit ten dotyczy sumy wiersza żądania i WSZYSTKICH pól nagłówka (dlatego pliki cookie powinny być krótkie).
Warto zauważyć, że nginx domyślnie używa rozmiaru strony systemowej, który w większości systemów wynosi 4K. Możesz sprawdzić za pomocą tego małego programu:
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;
}
Skompiluj z gcc -o pagesize pagesize.cnastępnie uruchom ./pagesize. Mój serwer Ubuntu z Linode sumiennie informuje mnie, że odpowiedź to 4k.
LimitRequestLinei LimitRequestFieldSizedotyczy każdego wiersza nagłówka HTTP osobno ... nie „suma ...”
HTTP nie nakłada z góry określonego ograniczenia na długość każdego pola nagłówka ani na długość sekcji nagłówka jako całości, jak opisano w sekcji 2.5. W praktyce występują różne ograniczenia ad hoc dotyczące długości poszczególnych pól nagłówka, często w zależności od konkretnej semantyki pola.
Wartości nagłówka HTTP są ograniczone przez implementacje serwera. Specyfikacja HTTP nie ogranicza rozmiaru nagłówka.
Serwer, który odbiera pole nagłówka żądania lub zestaw pól, większe niż chce przetworzyć, MUSI odpowiedzieć odpowiednim kodem statusu 4xx (Błąd klienta). Zignorowanie takich pól nagłówka zwiększy podatność serwera na żądanie ataków przemytu (sekcja 9.5).
Większość serwerów zwróci 413 Entity Too Largelub usunie błąd 4xx, gdy to nastąpi.
Klient MOŻE odrzucić lub skrócić otrzymane pola nagłówka, które są większe niż klient chce przetworzyć, jeśli semantyka pola jest taka, że upuszczone wartości można bezpiecznie zignorować bez zmiany ramek wiadomości lub semantyki odpowiedzi.
Nieograniczony rozmiar nagłówka HTTP utrzymuje serwer narażony na ataki i może obniżyć jego zdolność do obsługi ruchu organicznego.
Odkryłem również, że w niektórych przypadkach przyczyną 502/400 w przypadku wielu nagłówków może być duża liczba nagłówków bez względu na rozmiar. z dokumentów
tune.http.maxhdr Ustawia maksymalną liczbę nagłówków w żądaniu. Gdy żądanie zawiera liczbę nagłówków większą niż ta wartość (w tym pierwszy wiersz), jest odrzucane z kodem statusu „400 Błędne żądanie”. Podobnie zbyt duże odpowiedzi są blokowane przez „502 Bad Gateway”. Wartość domyślna to 101, co wystarcza na wszystkie zastosowania, biorąc pod uwagę, że szeroko rozpowszechniony serwer Apache używa tego samego limitu. Przydatne może być zwiększenie tego limitu, aby tymczasowo zezwolić błędnej aplikacji na działanie do czasu jej naprawienia. Pamiętaj, że każdy nowy nagłówek zużywa 32 bity pamięci dla każdej sesji, więc nie zwiększaj tego limitu zbyt wysoko.
https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#3.2-tune.http.maxhdr