Réponses:
Non, HTTP ne définit aucune limite. Cependant, la plupart des serveurs Web limitent la taille des en-têtes qu'ils acceptent. Par exemple, dans Apache, la limite par défaut est de 8 Ko, dans IIS, elle est de 16 Ko . Le serveur renverra une 413 Entity Too Largeerreur si la taille des en-têtes dépasse cette limite.
Question connexe: quelle taille peut avoir une chaîne d'agent utilisateur?
Comme le dit vartec ci-dessus, la spécification HTTP ne définit pas de limite, mais de nombreux serveurs le font par défaut. Cela signifie, pratiquement, que la limite inférieure est de 8K . Pour la plupart des serveurs, cette limite s'applique à la somme de la ligne de demande et de TOUS les champs d'en-tête (donc gardez vos cookies courts).
Il convient de noter que nginx utilise la taille de page système par défaut, qui est 4K sur la plupart des systèmes. Vous pouvez vérifier avec ce petit programme:
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;
}
Compilez avec gcc -o pagesize pagesize.cpuis exécutez ./pagesize. Mon serveur Ubuntu de Linode m'informe consciencieusement que la réponse est 4k.
LimitRequestLineet LimitRequestFieldSizes'applique à chaque ligne d'en-tête HTTP individuellement ... pas la "somme de ..."
HTTP ne place pas de limite prédéfinie sur la longueur de chaque champ d'en-tête ou sur la longueur de la section d'en-tête dans son ensemble, comme décrit dans la section 2.5. On trouve en pratique diverses limitations ad hoc sur la longueur de champ d'en-tête individuel, souvent en fonction de la sémantique de champ spécifique.
Les valeurs d'en-tête HTTP sont limitées par les implémentations de serveur. La spécification HTTP ne limite pas la taille de l'en-tête.
Un serveur qui reçoit un champ d'en-tête de demande, ou un ensemble de champs, plus grand qu'il ne souhaite traiter DOIT répondre avec un code d'état 4xx (erreur client) approprié. Ignorer ces champs d'en-tête augmenterait la vulnérabilité du serveur à la demande d'attaques de contrebande (section 9.5).
La plupart des serveurs renvoient 413 Entity Too Largeou une erreur 4xx appropriée lorsque cela se produit.
Un client PEUT éliminer ou tronquer les champs d'en-tête reçus qui sont plus grands que le client souhaite traiter si la sémantique des champs est telle que la ou les valeurs supprimées peuvent être ignorées en toute sécurité sans modifier le cadrage du message ou la sémantique des réponses.
La taille d'en-tête HTTP non plafonnée maintient le serveur exposé aux attaques et peut réduire sa capacité à servir le trafic organique.
J'ai également constaté que, dans certains cas, la raison de 502/400 dans le cas de nombreux en-têtes pouvait être due à un grand nombre d'en-têtes sans égard à la taille. des documents
tune.http.maxhdr Définit le nombre maximal d'en-têtes dans une demande. Lorsqu'une demande est livrée avec un nombre d'en-têtes supérieur à cette valeur (y compris la première ligne), elle est rejetée avec un code d'état "400 Bad Request". De même, les réponses trop importantes sont bloquées avec "502 Bad Gateway". La valeur par défaut est 101, ce qui est suffisant pour toutes les utilisations, étant donné que le serveur Apache largement déployé utilise la même limite. Il peut être utile de pousser cette limite plus loin pour permettre temporairement à une application de bug de fonctionner au moment où elle est corrigée. Gardez à l'esprit que chaque nouvel en-tête consomme 32 bits de mémoire pour chaque session, alors ne poussez pas cette limite trop haut.
https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#3.2-tune.http.maxhdr