Ignore:
Timestamp:
Feb 21, 2011, 5:36:36 AM (9 years ago)
Author:
julian.reschke@…
Message:

consuming implementations -> recipients, sending implementations -> senders, some cases of U-A -> recipient; U-A only used when talking about speicific implementations, not protocol behavior

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.html

    r1134 r1135  
    551551         but it does not define special handling of these invalid field-values.
    552552      </p>
    553       <p id="rfc.section.3.p.3">Sending implementations <em class="bcp14">MUST NOT</em> generate Content-Disposition header fields that are invalid.
    554       </p>
    555       <p id="rfc.section.3.p.4">Consuming implementations <em class="bcp14">MAY</em> take steps to recover a usable field-value from an invalid header field, but <em class="bcp14">SHOULD NOT</em> reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such,
     553      <p id="rfc.section.3.p.3">Senders <em class="bcp14">MUST NOT</em> generate Content-Disposition header fields that are invalid.
     554      </p>
     555      <p id="rfc.section.3.p.4">Recipients <em class="bcp14">MAY</em> take steps to recover a usable field-value from an invalid header field, but <em class="bcp14">SHOULD NOT</em> reject the message outright, unless this is explicitly desirable behaviour (e.g., the implementation is a validator). As such,
    556556         the default handling of invalid fields is to ignore them.
    557557      </p>
     
    596596      </p>
    597597      <h2 id="rfc.section.4.2"><a href="#rfc.section.4.2">4.2</a>&nbsp;<a id="disposition.type" href="#disposition.type">Disposition Type</a></h2>
    598       <p id="rfc.section.4.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the user agent should prompt the user
     598      <p id="rfc.section.4.2.p.1">If the disposition type matches "attachment" (case-insensitively), this indicates that the recipient should prompt the user
    599599         to save the response locally, rather than process it normally (as per its media type).
    600600      </p>
     
    618618         more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see <a href="#examples" title="Examples">Section&nbsp;5</a> for an example).
    619619      </p>
    620       <p id="rfc.section.4.3.p.5">It is essential that user agents treat the specified filename as advisory only, thus be very careful in extracting the desired
     620      <p id="rfc.section.4.3.p.5">It is essential that recipients treat the specified filename as advisory only, thus be very careful in extracting the desired
    621621         information. In particular:
    622622      </p>
     
    788788      <ul>
    789789         <li>According to RFC 2616, the disposition type "attachment" only applies to content of type "application/octet-stream". This
    790             restriction has been removed, because user agents in practice do not check the content type, and it also discourages properly
     790            restriction has been removed, because recipients in practice do not check the content type, and it also discourages properly
    791791            declaring the media type.
    792792         </li>
Note: See TracChangeset for help on using the changeset viewer.