Changeset 1011
- Timestamp:
- 15/09/10 13:34:47 (12 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
r1009 r1011 476 476 </ul> 477 477 </li> 478 <li class="tocline0">4. <a href="# rfc.section.4">Examples</a></li>478 <li class="tocline0">4. <a href="#examples">Examples</a></li> 479 479 <li class="tocline0">5. <a href="#i18n">Internationalization Considerations</a></li> 480 480 <li class="tocline0">6. <a href="#security.considerations">Security Considerations</a></li> … … 574 574 being displayed). 575 575 </p> 576 <p id="rfc.section.3.3.p.3">The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.3"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, allowing the use of characters not present in the ISO-8859-1 character set (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>). When both "filename" and "filename*" are present, a recipient <em class="bcp14">SHOULD</em> pick "filename*" and ignore "filename" - this will make it possible to send the same header field value to clients that do 577 not support "filename*". 578 </p> 579 <p id="rfc.section.3.3.p.4">It is essential that user agents treat the specified filename as advisory only, thus be very careful in extracting the desired 576 <p id="rfc.section.3.3.p.3">The parameters "filename" and "filename*" differ only in that "filename*" uses the encoding defined in <a href="#RFC5987" id="rfc.xref.RFC5987.3"><cite title="Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters">[RFC5987]</cite></a>, allowing the use of characters not present in the ISO-8859-1 character set (<a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a>). 577 </p> 578 <p id="rfc.section.3.3.p.4">Many user agent implementations predating this specification do not understand the "filename*" parameter. Therefore, when 579 both "filename" and "filename*" are present in a single header field value, recipients <em class="bcp14">SHOULD</em> pick "filename*" and ignore "filename". This way, senders can avoid special-casing specific user agents by sending both the 580 more expressive "filename*" parameter, and the "filename" parameter as fallback for legacy recipients (see <a href="#examples" title="Examples">Section 4</a> for an example). 581 </p> 582 <p id="rfc.section.3.3.p.5">It is essential that user agents treat the specified filename as advisory only, thus be very careful in extracting the desired 580 583 information. In particular: 581 584 </p> … … 604 607 using Content-Disposition, such as MIME and HTTP. Therefore, not all registered values may make sense in the context of HTTP. 605 608 </p> 606 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> Examples 607 </h1> 609 <h1 id="rfc.section.4"><a href="#rfc.section.4">4.</a> <a id="examples" href="#examples">Examples</a></h1> 608 610 <div id="rfc.figure.u.4"></div> 609 611 <p>Direct UA to show "save as" dialog, with a filename of "example.html":</p> <pre class="text">Content-Disposition: Attachment; filename=example.html -
draft-ietf-httpbis-content-disp/latest/draft-ietf-httpbis-content-disp.xml
r1010 r1011 182 182 the encoding defined in <xref target="RFC5987"/>, allowing the use 183 183 of characters not present in the ISO-8859-1 character set (<xref target="ISO-8859-1"/>). 184 When both "filename" and "filename*" are present, a recipient &SHOULD; pick 185 "filename*" and ignore "filename" - this will make it possible to send the 186 same header field value to clients that do not support "filename*". 184 </t> 185 <t> 186 Many user agent implementations predating this specification 187 do not understand the "filename*" parameter. Therefore, when both "filename" 188 and "filename*" are present in a single header field value, recipients 189 &SHOULD; pick "filename*" and ignore "filename". This way, senders 190 can avoid special-casing specific user agents by sending both the 191 more expressive "filename*" parameter, and the "filename" parameter 192 as fallback for legacy recipients (see <xref target="examples"/> for 193 an example). 187 194 </t> 188 195 <t> … … 231 238 </section> 232 239 233 <section title="Examples" >240 <section title="Examples" anchor="examples"> 234 241 235 242 <figure>
Note: See TracChangeset
for help on using the changeset viewer.