Tengo dos secciones de código en conflicto. Uno produce:

Content-Type: text/html; name=foo_foo2.blah
Content-Disposition: attachment; filename=foo_foo2.blah

Otro produce:

Content-Type: text/html; name="foo_foo2.blah"
Content-Disposition: attachment; filename="foo_foo2.blah"

El que no tiene comillas provoca un comportamiento inesperado por parte de una aplicación receptora. ¿Se requieren cotizaciones?

En RFC 2183 no veo un requisito explícito:

En la notación BNF extendida de [RFC 822], la disposición de contenido
el campo de encabezado se define de la siguiente manera:

 disposition := "Content-Disposition" ":"
                disposition-type
                *(";" disposition-parm)

 disposition-type := "inline"
                   / "attachment"
                   / extension-token
                   ; values are not case-sensitive

 disposition-parm := filename-parm
                   / creation-date-parm
                   / modification-date-parm
                   / read-date-parm
                   / size-parm
                   / parameter

 filename-parm := "filename" "=" value

 creation-date-parm := "creation-date" "=" quoted-date-time

 modification-date-parm := "modification-date" "=" quoted-date-time

 read-date-parm := "read-date" "=" quoted-date-time

 size-parm := "size" "=" 1*DIGIT

 quoted-date-time := quoted-string
                  ; contents MUST be an RFC 822 `date-time'
                  ; numeric timezones (+HHMM or -HHMM) MUST be used

Quizás estoy ciego sin embargo. ¿Alguien puede confirmar?

1
Mike B 19 ene. 2018 a las 21:39

3 respuestas

La mejor respuesta

Justo debajo del BNF está este pasaje:

El 'token de extensión', el 'parámetro', los 'tspeciales' y el 'valor' se definen de acuerdo con [RFC 2045] (que hace referencia a [RFC 822] en la definición de algunos de estos tokens). 'string-citado' y 'DIGIT' se definen en [RFC 822].

2045 tiene esta definición en la sección 5.1 (que sin embargo describe Content-type:):

  value := token / quoted-string

 token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
             or tspecials>

 tspecials :=  "(" / ")" / "<" / ">" / "@" /
               "," / ";" / ":" / "\" / <">
               "/" / "[" / "]" / "?" / "="
               ; Must be in quoted-string,
               ; to use within parameter values

Por lo tanto, no es necesario citar un nombre de archivo que sea token; pero si contiene alguno de los tspecials (o caracteres de control o espacios en blanco), debe citarlo después de todo.

Solo para abordar específicamente el caso del guión bajo, no es un carácter que requiere citar de acuerdo con el RFC (no es control, espacio en blanco o enumerado como uno de los tspecials), sino el tal como están las cosas en la naturaleza, probablemente sea mejor citar todo por si acaso. (¿Deberíamos llamar a esto anti-Postel? Sea indebidamente conservador sobre lo que transmite, y no sea demasiado liberal en lo que cree que puede inferir acerca de una entrada obviamente inválida).

Como un poco aparte, los nombres de archivo MIME en el correo electrónico son en la práctica completamente el Salvaje Oeste; muchas aplicaciones populares simplemente ignoran RFC2231 y usan la codificación RFC2047 aquí en su lugar, o no codifican, o sus propios brebajes ad hoc "pensé que esto podría funcionar y nadie se ha quejado".

3
tripleee 20 ene. 2018 a las 09:46

Como un aparte

De RFC2183

filename-parm := "filename" "=" value


token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
             or tspecials>

De RFC2045

value := token / quoted-string

tspecials :=  "(" / ")" / "<" / ">" / "@" /
                "," / ";" / ":" / "\" / <">
                "/" / "[" / "]" / "?" / "="
                ; Must be in quoted-string,
                ; to use within parameter values

De RFC822

SPACE       =  <ASCII SP, space>            ; (     40,      32.)
CTL         =  <any ASCII control           ; (  0- 37,  0.- 31.)
                character and DEL>          ; (    177,     127.)

¿Eso no significa que un encabezado como

Content-Disposition: attachment; filename=ja    r.jar

Con un carácter HTAB (pestaña horizontal) justo en el medio de jar.jar es un encabezado válido que no requiere que cite ja r.jar con comillas dobles?

0
Fulvio Scapin 19 oct. 2018 a las 16:25

No, no es obligatorio

Rfc2183 dice:

`Extension-token', `parameter', `tspecials' and `value' are defined
according to [RFC 2045] (which references [RFC 822] in the definition
of some of these tokens).  `quoted-string' and `DIGIT' are defined in
[RFC 822].

Y rfc2045 define value como lo siguiente:

value := token / quoted-string

token := 1*<any (US-ASCII) CHAR except SPACE, CTLs,
            or tspecials>

tspecials :=  "(" / ")" / "<" / ">" / "@" /
              "," / ";" / ":" / "\" / <">
              "/" / "[" / "]" / "?" / "="
              ; Must be in quoted-string,
              ; to use within parameter values

Esto significa que no es necesario citar el parámetro filename siempre que se ajuste a la definición de token.

Dicho esto, agregar comillas alrededor del parámetro de nombre de archivo es probablemente una buena forma de aumentar la compatibilidad con el software existente. Como ha descubierto, no todo el software implementa estas especificaciones correctamente, a menudo haciendo suposiciones (incorrectas) sobre cuál es el formato.

2
jstedfast 19 ene. 2018 a las 19:03