Longueur maximale de la requête HTTP GET


488

Quelle est la longueur maximale d'une requête HTTP GET ?

Y a-t-il une erreur de réponse définie que le serveur peut / devrait renvoyer s'il reçoit une demande GET qui dépasse cette longueur?

C'est dans le contexte d'une API de service Web, bien qu'il soit intéressant de voir également les limites du navigateur.



7
@KillianDS Cela n'a absolument rien à voir avec la longueur maximale d'une URL. La question concerne la longueur maximale d'une demande envoyée à une URL.
Marquis de Lorne

2
@EJP le contenu «données» d'un GET n'est pas plus qu'un URI.
KillianDS

@JimAho votre commentaire est aussi un double du premier commentaire .....
Jun711

Réponses:


464

La limite dépend à la fois du serveur et du client utilisé (et, le cas échéant, également du proxy utilisé par le serveur ou le client).

La plupart des serveurs Web ont une limite de 8192 octets (8 Ko), qui est généralement configurable quelque part dans la configuration du serveur. En ce qui concerne le côté client, la spécification HTTP 1.1 prévient même à ce sujet. Voici un extrait du chapitre 3.2.1 :

Remarque: Les serveurs doivent être prudents quant à la longueur d'URI supérieure à 255 octets, car certaines implémentations client ou proxy plus anciennes peuvent ne pas prendre correctement en charge ces longueurs.

La limite dans Internet Explorer et Safari est d'environ 2 Ko, dans Opera d'environ 4 Ko et dans Firefox d'environ 8 Ko. Nous pouvons donc supposer que 8 Ko est la longueur maximale possible et que 2 Ko est une longueur plus abordable sur laquelle s'appuyer côté serveur et que 255 octets est la longueur la plus sûre pour supposer que l'URL entière entrera.

Si la limite est dépassée dans le navigateur ou le serveur, la plupart tronqueront simplement les caractères en dehors de la limite sans aucun avertissement. Cependant, certains serveurs peuvent envoyer une erreur HTTP 414 . Si vous devez envoyer des données volumineuses, utilisez mieux POST au lieu de GET. Sa limite est beaucoup plus élevée, mais plus dépendante du serveur utilisé que du client. Habituellement, jusqu'à 2 Go environ sont autorisés par le serveur Web moyen. Ceci est également configurable quelque part dans les paramètres du serveur. Le serveur moyen affichera une erreur / exception spécifique au serveur lorsque la limite POST est dépassée, généralement sous la forme d'une erreur HTTP 500.


6
Vous répondez à la question en termes de limitations du navigateur. Savez-vous s'il existe des différences entre GET et POST (en termes de taille de demande problématique) si, par exemple, HttpClient est utilisé pour interagir avec un serveur REST?
aioobe

3
Bien sûr, POST utilise le corps pour envoyer les données. La spécification HTTP n'impose pas de limite de taille spécifique pour les publications.
Ignacio A. Poletti

1
Il est parfaitement permis par les spécifications Http de mettre un corps dans les requêtes GET et DELETE. Je l'ai testé en Java et ça marche. Malheureusement, là encore, certains mandataires ont pu couper le corps entier.
Nicolas Zozol

12
La méthode Get and Post a une signification très spécifique, donc utiliser un POST pour effectuer un GET équivaut à utiliser un marteau pour casser un œuf.
nohros

18
@nohros C'est idéalement vrai, mais GET a aussi des limitations que POST / PUT n'a pas. Par exemple, supposons que vous souhaitiez effectuer une requête très longue impliquant un groupe d'identifiants; si vous sélectionnez des centaines d'identifiants, cela peut dépasser la limite de la taille d'URL autorisée, tandis que le fait de placer cette requête dans un POST peut éviter cela, même si cela n'a pas autant de sens conceptuellement. Personnellement, je souhaite que HTTP autorise les requêtes GET à avoir des corps comme PUT et POST.
devios1

143

Vous posez ici deux questions distinctes:

Quelle est la longueur maximale d'une requête HTTP GET?

Comme déjà mentionné, HTTP lui-même n'impose aucune limite codée en dur sur la longueur de la demande; mais les navigateurs ont des limites allant de 2 Ko à 8 Ko (255 octets si l'on compte les très anciens navigateurs).

Y a-t-il une erreur de réponse définie que le serveur peut / devrait renvoyer s'il reçoit une demande GET dépassant cette longueur?

C'est à cela que personne n'a répondu.

HTTP 1.1 définit le code d'état 414 Request-URI Too Longpour les cas où une limite définie par le serveur est atteinte. Vous pouvez voir plus de détails sur RFC 2616 .

Dans le cas des limites définies par le client, il est inutile que le serveur renvoie quelque chose, car le serveur ne recevra pas du tout la demande.


23

Les limites du navigateur sont les suivantes:

Browser           Address bar    document.location
                                 or anchor tag
---------------------------------------------------
Chrome                32779           >64k
Android                8192           >64k
Firefox                >64k           >64k
Safari                 >64k           >64k
Internet Explorer 11   2047           5120
Edge 16                2047          10240

Vouloir plus? Voir cette question sur Stack Overflow .



3

Techniquement, j'ai vu que HTTP GET aura des problèmes si la longueur de l'URL dépasse 2000 caractères. Dans ce cas, il est préférable d'utiliser HTTP POST ou de diviser l'URL.


2

Comme déjà mentionné, HTTP lui-même n'impose aucune limite codée en dur sur la longueur de la demande; mais les navigateurs ont des limites allant sur le caractère 2048 autorisé dans la méthode GET.


-6

OBTENIR UNE DEMANDE à l'aide du navigateur Chrome

Oui. Il n'y a aucune limite sur une demande GET.

Je peux envoyer environ 4000 caractères dans le cadre de la chaîne de requête à l'aide du navigateur Chrome et de la commande curl.

J'utilise le serveur Tomcat 8.x qui a renvoyé la réponse attendue 200 OK.

Voici la capture d'écran d'une demande HTTP Google Chrome (masquant le point de terminaison que j'ai essayé pour des raisons de sécurité):

RÉPONSE

OBTENEZ à l'aide du navigateur Chrome

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.