Si fuera a almacenar un agente de usuario en una base de datos, ¿para qué tamaño acomodaría?
Encontré este artículo de Technet que recomienda mantener UA por debajo de 200. No parece que esto esté definido en la especificación HTTP, al menos no lo que encontré. Mi UA ya tiene 149 caracteres, y parece que cada versión de .NET se agregará.
Sé que puedo analizar la cadena y descomponerla, pero prefiero no hacerlo.
EDITAR
Basado en este blog IE9 cambiará para enviar la cadena UA corta. Este es un buen cambio.
http
database-design
http-headers
user-agent
JoshBerke
fuente
fuente
Respuestas:
La especificación HTTP no limita la longitud de los encabezados en absoluto. Sin embargo, los servidores web limitan el tamaño del encabezado que aceptan, arrojando
413 Entity Too Largesi excede.Dependiendo del servidor web y su configuración, estos límites varían de 4KB a 64KB (total para todos los encabezados).
fuente
Mi opinión sobre esto:
UNIQUE BINARY(32)(o 64, o 128 dependiendo de la longitud de hash) y hash el UserAgentAlgunas cadenas de UA pueden volverse obscenamente largas. Esto debería ahorrarte las preocupaciones. También aplique una longitud máxima en su INSERTer para mantener las cadenas UA por debajo de 4KB. A menos que alguien le envíe un correo electrónico en el agente de usuario, no debe exceder esa longitud.
fuente
Noté algo como esto en nuestros registros de apache. A mí me parece anormal, pero regularmente veo esas cosas en los registros principalmente de los sistemas Windows.
fuente
642numeros Los primeros cuatro números son siempre6,7,8, o9. El quinto número es siempre0. Los tres últimos son siempre603,703,803, o903. ¿Quizás alguien podría reconocer ese patrón? (Half-life 3 confirmado?)Dado que es para fines de base de datos y no hay un límite práctico, elegiría una tabla UserAgents con UserAgentId como Int y UserAgentString como NVarChar (MAX) y usaría una clave foránea en la tabla original.
fuente
¿Cómo es esto para grande?
fuente
No hay un límite establecido, solo el límite de la mayoría de los servidores HTTP. Sin embargo, teniendo esto en cuenta, implementaría una columna con una longitud fija razonable (use Google para encontrar una lista de agentes de usuario conocidos, encuentre el más grande y agregue 50%), y simplemente recorte cualquier agente de usuario que sea demasiado largo, excepcionalmente El agente de usuario largo es probablemente lo suficientemente único incluso cuando se recorta, o es el resultado de algún tipo de error o intento de "pirateo".
fuente
Hoy obtuve este agente de usuario, desbordando el campo de almacenamiento de nuestro proveedor:
¡Ridículo! 229 caracteres?
Así que tome ese tamaño, duplíquelo, duplíquelo nuevamente, y debería estar listo hasta el próximo error de Microsoft (tal vez esta vez el próximo año).
¡Ve más grande que 1000!
fuente
Te daré la respuesta estándar:
Tome el mayor valor posible que pueda imaginar, duplíquelo, y esa es su respuesta.
fuente
Suponga que la cadena del agente de usuario no tiene límite en su longitud y prepárese para almacenar dicho valor. Como has visto, la longitud es impredecible.
En Postgres, hay un texto. tipo de que acepta cadenas de longitud ilimitada. Usa eso.
Sin embargo, lo más probable es que tengas que empezar a truncar en algún momento. Llámalo bueno con un incremento razonablemente útil (200, 1k, 4k) y tira el resto.
fuente
Aquí hay uno que es 257
fuente
No es una indicación de cuán grande puede llegar a ser un agente de usuario, ya que hay muchas respuestas que muestran los casos límite que han encontrado, pero ¿el más largo que podría encontrar en http://www.useragentstring.com/pages/useragentstring.php? nombre = Todo era de 250 bytes.
fuente