Changes between Version 23 and Version 24 of ContentDispositionErrorHandling


Ignore:
Timestamp:
Dec 13, 2010, 2:35:21 AM (9 years ago)
Author:
ietf@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ContentDispositionErrorHandling

    v23 v24  
    3838    }}}
    3939
    40 2. If the string is the first disposition-type considered, the string is the the Disposition Type of the header field.
     402. If the string is the first disposition-type considered:
     41
     42  a. Let the canonicalized-disposition-type be the string with any ACII upper-case characters replaced with their lower-case equivalents and with all leading and trailing LWS removed.
     43
     44  b. The nominal disposition type of the header field is the canonicalized-disposition-type.
    4145
    42463. If the string is a name-value-pair:
     
    4650  b. This is the first name-value-pair with this canonicalized-name, then the canonicalized-name parameter of the header field is value.
    4751
    48 == Post-Process Parameter Values ==
    49 
    50   For each parameter, post-process the associated value part according
    51   to the grammar:
    52 
    53   o  According to Section 3.2.1 of [RFC5987] for parameters using the
    54      RFC 5987 syntax (such as "filename*").  If this fails, just ignore
    55      this parameter.
    56 
    57   o  According to the grammar for quoted-string (Section 2.2 of
    58      [RFC2616]) for values starting with a double quote character (").
    59 
    60   o  Verbatim otherwise.
    61 
    62   Note that this step starts with an octet sequence obtained from the
    63   HTTP message, and results in a sequence of Unicode characters.
    64 
    6552== Extracting the Disposition Type ==
    6653
    67   The parsing step (Appendix 5.2) has returned the disposition type (to
    68   be matched case-insensitively), which can be "attachment", "inline",
    69   or an extension type.  If the type is unknown, treat it like
    70   "attachment" (see Section 3.2).
     54If the header field has a nominal disposition type of "inline" or the header field does not have a nominal disposition type, then the header field's disposition type is "inline".  Otherwise, the header field's disposition type is "attachment".
    7155
    7256== Determining the File Name ==
    7357
    74   The parsing and post-processing steps resulted in a set of parameters
    75   (name/value pairs).  The suggested file name is the value of the
    76   "filename*" parameter (when present), otherwise the value of the
    77   "filename" parameter.
     58If the header field has a "filename*" parameter and the value of the "filename*" parameter is an RFC5987-value, then the header field's file name is the the RFC5987-decoding of the value of the "filename*" parameter.
    7859
    79   If neither is given, the UA can determine a name based on the
    80   associated URI; for instance based on the last path segment.
     60Otherwise, if the header field has a "filename" parameter, then the header field's file name is the filename-decoding (defined below) of the value of the "filename" parameter.
    8161
    82   Otherwise, the UA ought to post-process the suggested filename
    83   according following Section 3.3. [[anchor10: We could say here that
    84   UAs may reject filenames for security reasons, such as those with a
    85   path separator character.]]
    86 
    87 = Old text (to be integrated) =
    88 
    89 == Extracting Parameter Values From Header Fields ==
    90 
    91 To extract the value for a given parameter-name from an unparsed-string, parse
    92 the unparsed-string using the following grammar:
    93 
    94 {{{
    95 unparsed-string  = unbalanced-block / block * ( ";" block ) [ ";" unbalanced-block ]
    96 block            = *run
    97 unbalanced-block = *run unbalanced-run
    98 run              = unquoted-run / quoted-run
    99 unquoted-run     = non-quote *boring-octet
    100 quoted-run       = <"> *non-quote <">
    101 unbalanced-run   = <"> *non-quote
    102 non-quote        = <OCTET, except <"> >
    103 boring-octet     = <OCTET, except <"> and ";">
    104 }}}
    105 
    106 Parse each block, in turn, (including the unbalanced-block, if present) using the following grammar:
    107 
    108 {{{
    109 block = *LWS name *LWS "=" value
    110 value = OCTET
    111 }}}
    112 
    113 where the name production is a gramatical production that is a case-insensitive match for the given parameter-name.  If any block can be parsed by the grammar, let the raw-value be the characters produced by the value production of the first such block.  Otherwise, let the raw-value be the empty string.
    114 
    115 If the raw-value both begins an ends with a <"> character, return the value stripped of those <"> characters.  Otherwise return the raw-value.
    116 
    117 ''jre: this changes the interpretation of escape sequences in quoted-string, thus changes the interpretation of valid header fields''
    118 
    119 == Decoding the File Name ==
     62== Decoding Filename Parameter Values ==
    12063
    12164To filename-decode an encoded-string, use the following algorithm:
     
    12366 1. If the encoded-string contains non-ASCII characters, emit the encoded-string (decoded as ISO-8859-1) and abort these steps.
    12467 2. Let the url-unescaped-string be the encoded-string %-unescaped.
    125  3. Emit the url-unescaped-string (decoded as UTF-8).  (There's actually more sadness here if the url-unescaped-string isn't valid UTF-8.)
     68 3. Emit the url-unescaped-string (decoded as UTF-8).
    12669
    127 The emitted characters are the decoded file name.
    128 
    129 ''jre: percent-unescaping is only done by Chrome and IE, and breaks the semantics of valid header fields''
    130 
    131 == Determining the File Name ==
    132 
    133 To determine the file name indicated by a Content-Disposition header field, use
    134 the following algorithm:
    135 
    136  1. Let filename-star be the value extracted from the Content-Disposition header field for for the "filename*" parameter.
    137  2. If filename-star parses as a RFC5987-value, return the RFC5987-value of filename-star and abort these steps.
    138  3. Let filename be the value extracted from the Content-Disposition header field for the "filename" parameter.
    139  4. If filename is empty, instead let filename be the value extracted from the Content-Disposition header field for the "name" parameter.
    140  5. If filename is empty, return the empty string and abort these steps.
    141  6. Return the filename-decoding of filename.
    142 
    143 ''jre: 'name' is only supported by FF and Chrome, see http://greenbytes.de/tech/tc2231/#attwithnamepct''
    144 
    145 == Determining the Disposition ==
    146 
    147 To determine the disposition-type, parse the Content-Disposition header field using
    148 the following grammar:
    149 
    150 {{{
    151 unparsed-string = *LWS nominal-type *OCTET
    152 nominal-type    = "inline" / "filename" / "name" / ";"
    153 }}}
    154 
    155 If the Content-Disposition header field is non-empty and fails to parse, then
    156 the disposition type is "attachment".  Otherwise, the disposition-type is
    157 "inline".
    158 
    159 ''jre: (a) the instructions are very confusing, because the grammar doesn't mention the actual disposition types, (b) it's not clear what problem is solved here; what illegal header fields is this parsing that occur in practice?''
    160 
    161 == Processing the Content-Disposition Header Field ==
    162 
    163 To process the Content-Disposition header field, use the following algorithm:
    164 
    165  1. Determine the disposition-type.
    166  2. If the disposition-type is "inline", then ...
    167  3. If the disposition-type is "attachment", then let filename be the file name indicated by the header field.  ...
     70Note that this algorithm starts with a sequence of octets obtained from the HTTP message, and results in a sequence of Unicode characters.