* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Ticket #259: i259.2.diff

File i259.2.diff, 4.9 KB (added by julian.reschke@gmx.de, 5 years ago)

Updated proposal for parsing advice

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

    127127  response payload locally. 
    130 <section title="Grammar"> 
     130<section title="Grammar" anchor="grammar"> 
    131131<figure><artwork type="abnf2616"> 
    132132  content-disposition = "Content-Disposition" ":" 
    133133                         disposition-type *( ";" disposition-parm ) 
    334334  this situation is going to improve soon. 
    340340<section title="Internationalization Considerations" anchor="i18n"> 
    342342  The "filename*" parameter (<xref target="disposition.parameter.filename"/>), 
     809<section title="Parsing" anchor="parsing"> 
     811  This document does not require any specific handling of invalid header 
     812  field values. With this in mind, the text below describes a simple 
     813  strategy for parsing the header field and detecting problems in general, 
     814  or in specific parameters. 
     817<section title="Combine Multiple Instances of Content-Disposition"> 
     819  If the HTTP message contains multiple instances of the Content-Disposition 
     820  header field, combine all field values into a single one as specified 
     821  in <xref target="RFC2616" x:fmt="of" x:sec="4.2"/>. 
     825<section title="Parsing for Disposition Type and Parameters" anchor="parsing.for.type.and.parameter"> 
     827<preamble>Using the simplified grammar below:</preamble> 
     828<artwork type="abnf2616"> 
     829  field-value = disp-type *( ";" param ) 
     830  disp-type   = token 
     831  param       = token "=" value 
     834  ...parse the octet sequence in the field value into a disp-type (disposition 
     835  type) and a sequence of parameters (pairs of name (token) and value).  
     839  Treat the result values as characters encoded using the ISO-8859-1 character 
     840  encoding (<xref target="ISO-8859-1"/>). 
     843  Lower-case all disposition types and parameter names (note that these 
     844  characters will all fall into the US-ASCII range by definition in the ABNF). 
     847  If the field value does not conform to the grammar (such as when not 
     848  exactly one disposition type is specified), ignore the whole header field. 
     852<section title="Checking Cardinality Constraints"> 
     854  If the parameter sequence contains multiple instances of the  
     855  same parameter name, ignore the whole header field. 
     859<section title="Post-Process Parameter Values"> 
     861  For each parameter, post-process the associated value part according to the grammar: 
     862  <list style="symbols"> 
     863    <t>According to <xref target="RFC5987" x:sec="3.2.1"/> for parameters 
     864    using the RFC 5987 syntax (such as "filename*"). If this fails, 
     865    just ignore this parameter.</t> 
     866    <t>According to the grammar for quoted-string (<xref target="RFC2616" x:fmt="of" x:sec="2.2"/>) 
     867    for values starting with a double quote character (").</t> 
     868    <t>Verbatim otherwise.</t> 
     869  </list> 
     873<section title="Extracting the Disposition Type"> 
     875  The parsing step (<xref target="parsing.for.type.and.parameter"/>) has 
     876  returned the disposition type (to be matched case-insensitively), which can 
     877  be "attachment", "inline", or an extension type. If the type is unknown, 
     878  treat it like "attachment" (see <xref target="disposition.type"/>). 
     882<section title="Determining the File Name"> 
     884  The parsing and post-processing steps resulted in a set of parameters 
     885  (name/value pairs). The suggested file name is the value of the "filename*" 
     886  parameter (when present), otherwise the value of the "filename" parameter. 
     889  If neither is given, the UA can determine a name based on the associated 
     890  URI; for instance based on the last path segment. 
     893  Otherwise, the UA ought to post-process the suggested filename according 
     894  following <xref target="disposition.parameter.filename"/>.  
     895  <cref>We could say here that UAs may reject filenames for security reasons, 
     896  such as those with a path separator character.</cref> 
    810903<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> 
    812905  Note: the issues names in the change log entries for draft-reschke-rfc2183-in-http 
    9091002      "Avoid passive voice in message requirements" 
    9101003    </t> 
    9111004    <t> 
     1005      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/259"/>: 
     1006      "'treat as invalid' not defined" 
     1007    </t> 
     1008    <t> 
    9121009      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/263"/>: 
    9131010      "text about historical percent-decoding unclear" 
    9141011    </t>