Changeset 1299
- Timestamp:
- 27/05/11 10:20:15 (11 years ago)
- Location:
- draft-ietf-httpbis-content-disp/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.html
r1298 r1299 487 487 the requirements associated with its role. 488 488 </p> 489 <p id="rfc.section.3.p.2">This specification also defines certain forms of the header field -value to be invalid, using both ABNF and prose requirements490 (<a href="#header.field.definition" id="rfc.xref.header.field.definition.1" title="Header Field Definition">Section 4</a>), but it does not define special handling of these invalid field -values.489 <p id="rfc.section.3.p.2">This specification also defines certain forms of the header field value to be invalid, using both ABNF and prose requirements 490 (<a href="#header.field.definition" id="rfc.xref.header.field.definition.1" title="Header Field Definition">Section 4</a>), but it does not define special handling of these invalid field values. 491 491 </p> 492 492 <p id="rfc.section.3.p.3">Senders <em class="bcp14">MUST NOT</em> generate Content-Disposition header fields that are invalid. 493 493 </p> 494 <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 behavior (e.g., the implementation is a validator). As such,494 <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 behavior (e.g., the implementation is a validator). As such, 495 495 the default handling of invalid fields is to ignore them. 496 496 </p> -
draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml
r1298 r1299 137 137 </t> 138 138 <t> 139 This specification also defines certain forms of the header field -value to be139 This specification also defines certain forms of the header field value to be 140 140 invalid, using both ABNF and prose requirements (<xref target="header.field.definition"/>), 141 but it does not define special handling of these invalid field -values.141 but it does not define special handling of these invalid field values. 142 142 </t> 143 143 <t> … … 146 146 </t> 147 147 <t> 148 Recipients &MAY; take steps to recover a usable field -value148 Recipients &MAY; take steps to recover a usable field value 149 149 from an invalid header field, but &SHOULD-NOT; reject the message outright, 150 150 unless this is explicitly desirable behavior (e.g., the implementation is a
Note: See TracChangeset
for help on using the changeset viewer.