- Timestamp:
- 21/02/11 13:36:36 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml
r1134 r1135 131 131 </t> 132 132 <t> 133 Send ing implementations &MUST-NOT; generate Content-Disposition header fields134 that areinvalid.135 </t> 136 <t> 137 Consuming implementations &MAY; take steps to recover a usable field-value133 Senders &MUST-NOT; generate Content-Disposition header fields that are 134 invalid. 135 </t> 136 <t> 137 Recipients &MAY; take steps to recover a usable field-value 138 138 from an invalid header field, but &SHOULD-NOT; reject the message outright, 139 139 unless this is explicitly desirable behaviour (e.g., the implementation is a … … 204 204 <t> 205 205 If the disposition type matches "attachment" (case-insensitively), this 206 indicates that the user agent should prompt the user to save the response206 indicates that the recipient should prompt the user to save the response 207 207 locally, rather than process it normally (as per its media type). 208 208 </t> … … 247 247 </t> 248 248 <t> 249 It is essential that user agents treat the specified filename as advisory249 It is essential that recipients treat the specified filename as advisory 250 250 only, thus be very careful in extracting the desired information. 251 251 In particular: … … 666 666 According to RFC 2616, the disposition type "attachment" only applies to 667 667 content of type "application/octet-stream". This restriction has been 668 removed, because user agents in practice do not check the content type, and668 removed, because recipients in practice do not check the content type, and 669 669 it also discourages properly declaring the media type. 670 670 </t>
Note: See TracChangeset
for help on using the changeset viewer.