26/02/11 10:54:51 (12 years ago)

add sender advice appendix, remove fallback bug note from earlier part of the spec

1 edited


  • draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml

    r1141 r1142  
    355   Note: as of February 2011, those user agents that do not support the RFC 5987
    356   encoding ignore "filename*" when it occurs after "filename". Unfortunately,
    357   one user agent that does support RFC 5987 picks the "filename" rather
    358   than the "filename*" parameter when it occurs first; it is expected that
    359   this situation is going to improve soon.
     355  Note: those user agents that do not support the RFC 5987 encoding ignore
     356  "filename*" when it occurs after "filename".
     831<section title="Advice on Generating Content-Disposition Header Fields" anchor="advice.generating">
     833  To successfully interoperate with existing and future user agents, senders of
     834  the Content-Disposition header field are advised to:
     837  <list style="symbols">
     838    <t>Include a 'filename' parameter when US-ASCII is sufficiently
     839    expressive.</t>
     840    <t>Use the 'token' form of the filename parameter only when it does not
     841    contain disallowed characters (e.g., spaces); in such cases, the
     842    quoted-string form should be used.</t>
     843    <t>Avoid including the percent character followed by two hexadecimal
     844    characters (e.g., %A9) in the filename parameter, since some existing
     845    implementations consider it to be an escape character, while others will
     846    pass it through unchanged.</t>
     847    <t>Avoid including the "\" character in the quoted-string form of the
     848    filename parameter, as escaping is not implemented by some user agents,
     849    and can be considered as an illegal path character.</t>
     850    <t>Avoid using non-ASCII characters in the filename parameter. Although
     851    most existing implementations will decode them as ISO-8859-1, some
     852    will apply heuristics to detect UTF-8, and thus might fail on certain names.</t>
     853    <t>Include a 'filename*' parameter where the desired filename cannot be
     854    expressed faithfully using the 'filename' form. Note that legacy user
     855    agents will not process this, and will fall back to using the 'filename'
     856    parameter's content.
     857    </t>
     858    <t>When a 'filename*' parameter is sent, to also generate a 'filename'
     859    parameter as a fallback for user agents that do not support the 'filename*'
     860    form, if possible. This can be done by substituting characters with
     861    US-ASCII sequences (e.g., Unicode character point U+00E4 (LATIN SMALL
     862    LETTER A WITH DIARESIS) by "ae"). Note that this may not be possible in
     863    some locales.
     864    </t>
     865    <t>When a 'filename' parameter is included as a fallback (as per above),
     866    'filename' should occur first, due to parsing problems in some existing
     867    implementations.
     868    <cref anchor="fallbackbug" source="jre">
     869    Firefox is known to pick the wrong parameter; a bug fix is scheduled for
     870    Firefox 5.</cref>
     871    </t>
     872    <t>Use UTF-8 as the encoding of the 'filename*' parameter, when present,
     873    because at least one existing implementation only implements that encoding.</t>
     874  </list>
     877  Note that this advice is based upon UA behaviour at the time of writing, and
     878  might be superseded.
     879  <eref target="http://purl.org/NET/http/content-disposition-tests"/> provides
     880  an overview of current levels of support in various implementations.
    835884<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log">
    9841033  notes with respect to the fallback behavior.
     1036  Added appendix "Advice on Generating Content-Disposition Header Fields".
Note: See TracChangeset for help on using the changeset viewer.