2011-11-23 13 views
5

En un formulario de varias partes (es decir, Content-Type=multipart/form-data), ¿hay un límite superior en la longitud de la cadena límite que debe aceptar un servidor HTTP?Formulario multiparte HTML: ¿longitud máxima de la cadena "límite"?

Por lo que yo puedo decir, los RFC pertinentes dicen 70 caracteres:

  • RFC2616 (HTTP/1.1) sección "3.7 Tipos de papel", dice que los tipos permitidos en la cabecera Content-Type es definido por RFC1590 (Procedimiento de registro del tipo de medio).
  • RFC1590 actualizaciones RFC-1521 (MIME).
  • RFC1521 dice que un límite "no debe tener más de 70 caracteres, sin contar los dos guiones principales".
  • El mismo texto también aparece en RFC2046 que supuestamente obsoletos RFC1521.

¿Puedo estar seguro de que todos los principales navegadores HTTP/1.1 que existen hoy cumplen con este límite? ¿Hay navegadores (u otros clientes/bibliotecas HTTP) que superen este límite?

¿Hay alguna otra especificación o regla general que me falta que diga que la cadena será más corta que 70 caracteres? En Chrome (ium) obtengo algo como esto: ----WebKitFormBoundaryLu4dNSGEhJZUgoe5, que obviamente es más corto que 70 caracteres.

Estoy haciendo esta pregunta porque mi servidor se ejecuta en un entorno extremadamente limitado por la memoria, por lo que "malloc un búfer lo suficientemente grande como para contener toda la cadena de encabezado" no es una respuesta ideal.

+0

Solicite un límite superior. Por supuesto, es posible que no obtenga el límite superior completo pero menos (relacionado con el límite de Chrome). –

+0

no debería haber problema si usa AJAX y procesa los datos en su archivo PHP directamente –

+0

"mantener toda la cadena del encabezado"? ¿Por qué todo el encabezado, si solo necesitas el límite? –

Respuesta

5

Como observa, RFC 2046 actualizó la especificación MIME, pero mantuvo la restricción de la cadena de límite máxima en 70 caracteres, sin contar los dos guiones principales.

Creo que es una suposición razonable que la especificación es seguida por todos los navegadores principales (y todos los clientes que usan MIME, como los programas de correo) ya que de lo contrario pasar datos multiparte sería muy arriesgado.

Para estar seguro, he verificado experimentalmente que para usted, utilizando las últimas versiones de:

  • rizo: ----------------------------5a56a6c893f2 (40)
  • Chrome 30 (WebKit): ----WebKitFormBoundarym0vCJKBpUYdCIWQG (38)
  • Safari 6 (WebKit, y mismo que Chrome): ----WebKitFormBoundaryFHUXvJBZwO2JKkNa (38)
  • FireFox 24: ---------------------------7096603861379320641089344535 (55)
  • IE 10: ---------------------------7dd1961640278 (40) - misma técnica que enrollamiento !
  • Apache HttpClient: -----------------------------1294919323195 (42)

De este modo no sólo se conforma cada gran navegador/cliente, pero todos le permitiría ahorrar 15 bytes asignados por límite al búfer del máximo teórico. Si pudiera cambiar trivialmente el agente de usuario, podría exprimir aún más el rendimiento.;-)

+0

¿Activar usuario-agente? ¿En serio? –

+0

No es tan grave. – mjk

Cuestiones relacionadas