Si vous deviez stocker un agent utilisateur dans une base de données, quelle taille accepteriez-vous?
J'ai trouvé cet article technet qui recommande de garder UA sous 200. Il ne semble pas que cela soit défini dans la spécification HTTP, du moins pas que j'ai trouvé. Mon UA compte déjà 149 caractères, et il semble que chaque version de .NET y ajoutera.
Je sais que je peux analyser la chaîne et la décomposer, mais je préfère ne pas.
EDIT
Sur la base de ce blog, IE9 changera pour envoyer la courte chaîne UA. C'est un bon changement.
http
database-design
http-headers
user-agent
JoshBerke
la source
la source
Réponses:
La spécification HTTP ne limite pas du tout la longueur des en-têtes. Cependant, les serveurs Web limitent la taille d'en-tête qu'ils acceptent, en la jetant
413 Entity Too Largesi elle dépasse.Selon le serveur Web et leurs paramètres, ces limites varient de 4 Ko à 64 Ko (total pour tous les en-têtes).
la source
Mon point de vue sur ceci:
UNIQUE BINARY(32)(ou 64, ou 128 selon votre longueur de hachage) et hacher l'UserAgentCertaines chaînes UA peuvent devenir incroyablement longues. Cela devrait vous épargner les soucis. Appliquez également une longueur maximale dans votre INSERTer pour garder UA les chaînes sous 4 Ko. À moins que quelqu'un ne vous envoie un e-mail dans l'agent utilisateur, il ne doit pas dépasser cette longueur.
la source
J'ai remarqué quelque chose comme ça dans nos journaux Apache. Cela me semble anormal, mais je vois régulièrement de telles choses dans les journaux, principalement à partir des systèmes Windows.
la source
642chiffres. Les quatre premiers chiffres sont toujours6,7,8ou9. Le cinquième chiffre est toujours0. Les trois derniers sont toujours603,703,803ou903. Peut-être que quelqu'un pourrait reconnaître ce modèle? (Demi-vie 3 confirmée?)Comme c'est à des fins de base de données et qu'il n'y a pas de limite pratique, j'opterais pour une table UserAgents avec UserAgentId comme Int et UserAgentString comme NVarChar (MAX) et utiliser une clé étrangère sur la table d'origine.
la source
Comment est-ce pour les grands?:
la source
Il n'y a pas de limite indiquée, seulement la limite de la plupart des serveurs HTTP. Gardant cela à l'esprit cependant, j'implémenterais une colonne avec une longueur fixe raisonnable (utilisez Google pour trouver une liste d'agents utilisateurs connus, trouvez le plus grand et ajoutez 50%), et recadrez simplement tout agent utilisateur trop long - exceptionnellement l'agent utilisateur long est probablement assez unique même lorsqu'il est rogné, ou est le résultat d'une sorte de bogue ou d'une tentative de "piratage".
la source
J'ai reçu cet agent utilisateur aujourd'hui, débordant le champ de stockage de notre fournisseur:
Ridicule! 229 caractères?
Prenez donc cette taille, doublez-la, doublez-la à nouveau, et vous devriez être réglé jusqu'à la prochaine erreur de Microsoft (peut-être cette fois l'année prochaine).
Allez plus de 1000!
la source
Je vais vous donner la réponse standard:
Prenez la plus grande valeur possible que vous pouvez imaginer être, doublez-la, et c'est votre réponse.
la source
Supposons que la chaîne d'agent utilisateur n'a pas de limite sur sa longueur et préparez-vous à stocker une telle valeur. Comme vous l'avez vu, la longueur est imprévisible.
Dans Postgres, il existe un type de texte qui accepte des chaînes de longueur illimitée. Utiliser ça.
Cependant, vous devrez probablement commencer à tronquer à un moment donné. Appelez-le bon à un incrément raisonnablement utile (200, 1k, 4k) et jetez le reste.
la source
En voici un qui fait 257
la source
Pas une indication de la taille d'un agent utilisateur, car il y a beaucoup de réponses montrant les cas marginaux qu'ils ont rencontrés, mais la plus longue que l'on puisse trouver sur http://www.useragentstring.com/pages/useragentstring.php? name = Tout était de 250 octets.
la source