* 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, 4 years ago)

Updated proposal for parsing advice

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

     
    127127  response payload locally. 
    128128</t> 
    129129 
    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. 
    335335</postamble> 
    336336</figure> 
    337  
    338337</section> 
    339338 
     339 
    340340<section title="Internationalization Considerations" anchor="i18n"> 
    341341<t> 
    342342  The "filename*" parameter (<xref target="disposition.parameter.filename"/>), 
     
    806806 
    807807</section> 
    808808 
     809<section title="Parsing" anchor="parsing"> 
     810<t> 
     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. 
     815</t> 
    809816 
     817<section title="Combine Multiple Instances of Content-Disposition"> 
     818<t> 
     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"/>. 
     822</t> 
     823</section> 
     824 
     825<section title="Parsing for Disposition Type and Parameters" anchor="parsing.for.type.and.parameter"> 
     826<figure> 
     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 
     832</artwork> 
     833<postamble> 
     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).  
     836</postamble> 
     837</figure> 
     838<t> 
     839  Treat the result values as characters encoded using the ISO-8859-1 character 
     840  encoding (<xref target="ISO-8859-1"/>). 
     841</t> 
     842<t> 
     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). 
     845</t> 
     846<t> 
     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. 
     849</t> 
     850</section> 
     851 
     852<section title="Checking Cardinality Constraints"> 
     853<t> 
     854  If the parameter sequence contains multiple instances of the  
     855  same parameter name, ignore the whole header field. 
     856</t> 
     857</section> 
     858 
     859<section title="Post-Process Parameter Values"> 
     860<t> 
     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> 
     870</t> 
     871</section> 
     872 
     873<section title="Extracting the Disposition Type"> 
     874<t> 
     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"/>). 
     879</t> 
     880</section> 
     881 
     882<section title="Determining the File Name"> 
     883<t> 
     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. 
     887</t> 
     888<t> 
     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. 
     891</t> 
     892<t> 
     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> 
     897</t> 
     898 
     899</section> 
     900 
     901</section> 
     902 
    810903<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> 
    811904<t> 
    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>