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

Ticket #259: i259.diff

File i259.diff, 4.7 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 field value into a disp-type (disposition type) and a 
     835  sequence of parameters (pairs of name (token) and value). Lower-case 
     836  all disposition types and parameter names. 
     837</postamble> 
     838</figure> 
     839<t> 
     840  If the field value does not conform to the grammar (such as when not 
     841  exactly one disposition type is specified), ignore the whole header field. 
     842</t> 
     843</section> 
     844 
     845<section title="Checking Cardinality Constraints"> 
     846<t> 
     847  If the parameter sequence contains multiple instances of the  
     848  same parameter name, ignore the whole header field. 
     849</t> 
     850</section> 
     851 
     852<section title="Post-Process Parameter Values"> 
     853<t> 
     854  For each parameter, post-process the associated value part according to the grammar: 
     855  <list style="symbols"> 
     856    <t>According to <xref target="RFC5987" x:sec="3.2.1"/> for parameters 
     857    using the RFC 5987 syntax (such as "filename*"). If this fails, 
     858    just ignore this parameter.</t> 
     859    <t>According to the grammar for quoted-string (<xref target="RFC2616" x:fmt="of" x:sec="2.2"/>) 
     860    for values starting with a double quote character (").</t> 
     861    <t>Verbatim otherwise.</t> 
     862  </list> 
     863</t> 
     864<t> 
     865  Note that this step starts with an octet sequence obtained from the HTTP 
     866  message, and results in a sequence of Unicode characters. 
     867</t> 
     868</section> 
     869 
     870<section title="Extracting the Disposition Type"> 
     871<t> 
     872  The parsing step (<xref target="parsing.for.type.and.parameter"/>) has 
     873  returned the disposition type (to be matched case-insensitively), which can 
     874  be "attachment", "inline", or an extension type. If the type is unknown, 
     875  treat it like "attachment" (see <xref target="disposition.type"/>). 
     876</t> 
     877</section> 
     878 
     879<section title="Determining the File Name"> 
     880<t> 
     881  The parsing and post-processing steps resulted in a set of parameters 
     882  (name/value pairs). The suggested file name is the value of the "filename*" 
     883  parameter (when present), otherwise the value of the "filename" parameter. 
     884</t> 
     885<t> 
     886  If neither is given, the UA can determine a name based on the associated 
     887  URI; for instance based on the last path segment. 
     888</t> 
     889<t> 
     890  Otherwise, the UA ought to post-process the suggested filename according 
     891  following <xref target="disposition.parameter.filename"/>.  
     892  <cref>We could say here that UAs may reject filenames for security reasons, 
     893  such as those with a path separator character.</cref> 
     894</t> 
     895 
     896</section> 
     897 
     898</section> 
     899 
    810900<section title="Change Log (to be removed by RFC Editor before publication)" anchor="change.log"> 
    811901<t> 
    812902  Note: the issues names in the change log entries for draft-reschke-rfc2183-in-http 
     
    909999      "Avoid passive voice in message requirements" 
    9101000    </t> 
    9111001    <t> 
     1002      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/259"/>: 
     1003      "'treat as invalid' not defined" 
     1004    </t> 
     1005    <t> 
    9121006      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/263"/>: 
    9131007      "text about historical percent-decoding unclear" 
    9141008    </t>