web-dev-qa-db-fra.com

Maximum sur les valeurs d'en-tête http?

Existe-t-il une taille maximale autorisée pour les en-têtes HTTP? Si oui, c'est quoi? Si ce n'est pas le cas, s'agit-il de serveurs spécifiques ou la norme acceptée d'autoriser les en-têtes de toutes tailles?

httphttp-headers
296
Cory

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 limite par défaut d'Apache = 8 Ko, dans IIS, c'est 16K . Le serveur renvoie l'erreur 413 Entity Too Large si la taille des en-têtes dépasse cette limite.

Question connexe: Quelle est la taille d’une chaîne d’agent utilisateur?

288
vartec

Comme le dit vartec ci-dessus, la spécification HTTP ne définit pas de limite, quel que soit le nombre de serveurs défini par défaut. Cela signifie que, dans la pratique, la limite inférieure est 8K . Pour la plupart des serveurs, cette limite s’applique à la somme de la ligne de requête et ALL champs d’en-tête (conservez donc vos cookies court).

Il convient de noter que nginx utilise par défaut la taille de la page système, qui correspond à 4 Ko 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.c puis exécutez ./pagesize. Mon serveur Ubuntu de Linode me dit consciencieusement que la réponse est 4k.

208
David Schoonover

HTTP ne fixe pas de limite prédéfinie sur la longueur de chaque champ d'en-tête ni sur la longueur de la section d'en-tête dans son ensemble, comme décrit à la section 2.5. Dans la pratique, on trouve diverses limitations ad hoc sur la longueur des champs d'en-tête individuels, souvent en fonction de la sémantique du champ.

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 volumineux qu'il ne souhaite traiter DOIT répondre avec un code d'état 4xx (erreur client) approprié. Ignorer de tels champs d'en-tête augmenterait la vulnérabilité du serveur face aux attaques de contrebande (Section 9.5).

Lorsque cela se produit, la plupart des serveurs renverront 413 Entity Too Large ou l'erreur 4xx appropriée.

Un client PEUT supprimer ou tronquer les champs d'en-tête reçus dont la taille est supérieure à celle que le client souhaite traiter si la sémantique du champ est telle que la ou les valeurs supprimées peuvent être ignorées en toute sécurité sans modifier l'encadrement du message ou la sémantique de la réponse.

La taille de l'en-tête HTTP non plafonné expose le serveur aux attaques et peut réduire sa capacité à gérer le trafic organique.

Source

4
realPK

J'ai également constaté que dans certains cas, la raison de 502/400 dans le cas d'en-têtes nombreux pourrait être due à un grand nombre d'en-têtes sans égard à la taille. des docs

tune.http.maxhdr Définit le nombre maximal d'en-têtes dans une demande. Lorsqu'une requête contient 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 requêtes incorrectes". De même, les réponses trop volumineuses 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 boguée de fonctionner au moment où elle est corrigée. N'oubliez pas que chaque nouvel en-tête consomme 32 bits de mémoire pour chaque session. Par conséquent, évitez de trop pousser cette limite.

https://cbonte.github.io/haproxy-dconv/configuration-1.5.html#3.2-tune.http.maxhdr

1
Shay Rybak