y a-t-il une taille maximale à la longueur d'une entrée cachée en html?

92

en d'autres termes:

<input type="hidden" value="Can I put as much as I want in here, or is there a limit?" />

et si oui, qu'est-ce que c'est?

html input sprugman
la source
6
La meilleure méthode de demande que j'ai jamais vue.
Andrés Morales

Réponses:

59

Cela dépend de la méthode avec laquelle vous envoyez le formulaire.

Avec GET, il existe une limite généralement convenue d'environ 1 à 2 kilo-octets, en fonction des limitations du navigateur et du serveur.

Avec POST, il n'y a pas de limite technique dans le navigateur, mais généralement du côté serveur - voir par exemple Apache LimitRequestBody, PHP post_max_sizeet ainsi de suite.

Pekka
la source
Méfiez-vous des problèmes signalés par @naugtur ci-dessous pour les champs de saisie de texte - au moins pour ceux-ci, il existe des limites techniques imposées par différents navigateurs.
Oliver
Je viens de faire quelques tests sur 3 navigateurs quelque peu actuels (IE9, FF 10 ESR, Chrome 24) et ils ont tous soumis des valeurs d'entrée cachées de 100 Ko sans aucun problème. Les problèmes avec les entrées de texte ne semblent donc pas s'appliquer ici.
Oliver
et textareas?
Francisco Corrales Morales
@FranciscoCorralesMorales, peu importe le type de champ de saisie - ce qui compte, c'est le résultat final, la somme de toutes les données que vous envoyez
Pekka
J'ai trouvé que Safari tronquait l'entrée cachée. L'utilisation d'une zone de texte a résolu le problème.
Brendon Muir
29

Avertissement! J'ai rencontré des problèmes <input type="text">lorsque le texte est plus long que 65535 (taille max.

Le collage du texte semble provoquer un étrange débordement de contenu. Repéré dans le kit Web.

[Éditer]

La taille de la requête GET n'est pas exactement limitée de la manière dont Pekka a écrit. Il y a une limite de 2083 octets pour toute la chaîne de requête GET address?paramsdans Internet Explorer uniquement. Dans d'autres navigateurs, il n'y a pratiquement aucune limite, avec FireFox envoyant des requêtes GET de plus de 100 Ko par exemple. De toute évidence, le serveur doit les autoriser.

Ce n'est pas couvert dans la documentation, il faut donc le tester pour connaître les limites des autres navigateurs. IE: http://support.microsoft.com/kb/208427

Naugtur
la source
8
+1 J'ai créé ce jsFiddle pour tester ce qui se passe lorsque vous définissez une valeur d'entrée sur une très longue chaîne: jsfiddle.net/3TVPL/6 J'ai utilisé une chaîne de 65537 caractères. Dans mes tests, Crome 24.0.1312 et Safari 5.1.7 pour Windows affichent tous les deux des zones de saisie vides après avoir défini la valeur sur cette chaîne. Chrome affiche la valeur non vide appropriée si je réduis la chaîne à 65536 caractères. D'autres navigateurs (Firefox 17, IE8, IE9, IE10, Opera 12.12) n'ont eu aucun problème même avec des chaînes beaucoup plus longtemps (je suis allé jusqu'à environ 1,2 Mo de chaîne)
beluga
@beluga excellent travail. des réflexions sur la performance? Sur ma machine faible, c'était une longue attente. Je suppose que c'est pourquoi Webkit ne rend pas cela.
naugtur
Bon point, peut-être. Je n'ai fait aucun test de performance pour le moment. J'ai une machine assez robuste au travail et je n'ai remarqué aucun retard dans aucun des navigateurs.
beluga
Cela a rendu mon FF inutilisable pendant environ 5 minutes. Mettre autant de choses dans un champ de formulaire n'est pas une bonne idée de toute façon :)
naugtur
Les navigateurs mobiles et les proxies peuvent également tronquer les champs cachés
George Filippakos