Changes between Initial Version and Version 1 of ContentDispositionProducerAdvice


Ignore:
Timestamp:
Jul 13, 2011, 5:13:36 AM (8 years ago)
Author:
mnot@…
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • ContentDispositionProducerAdvice

    v1 v1  
     1
     2= HTTP Frameworks and the Content-Disposition Header =
     3
     4The [WikiStart IETF HTTPbis Working Group] has recently published RFC6266, "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol."
     5
     6This specification is the result of extensive testing ([http://greenbytes.de/tech/tc2231/ detail]) of existing Web browsers and other clients, as well as ongoing work with browser vendors to improve their implementations.
     7
     8This RFC now defines the syntax and semantics of Content-Disposition headers. This page has been written to help authors of server-side HTTP libraries and frameworks produce Content-Disposition headers that are interoperable with the broadest number of implementations, based on that RFC.
     9
     10
     11== Why HTTP Frameworks Should Have a Content-Disposition API ==
     12
     13While it's possible for content developers to produce their own Content-Disposition headers (and currently many frameworks require them to do so), there are some details that are important to get right for interoperability. Many of these issues surround internationalisation.
     14
     15In simple cases, Content-Disposition looks something like this:
     16
     17{{{
     18Content-Disposition: attachment; filename=example.html
     19}}}
     20
     21However, when the filename has non-ASCII characters in it, it needs to be encoded as described in RFC5987. For example:
     22
     23{{{
     24Content-Disposition: attachment;
     25                     filename="EURO rates";
     26                     filename*=utf-8''%e2%82%ac%20rates
     27
     28}}}
     29
     30Similarly, there are a number of other "gotcha" issues, such as including backslash characters and quoting parameters with spaces in them. By providing an API for developers to easily produce Content-Disposition headers, HTTP frameworks can help them avoid these common problems, and also more painlessly evolve as browser implementations improve.
     31
     32Note that as the Web has evolved, HTTP's use of headers has diverged from MIME, so it's not adequate to just use a MIME library any more (for Content-Disposition or many other purposes).
     33
     34
     35== Sample API for Content-Disposition Generation ==
     36
     37RFC6266 Appendix D describes an approach to producing Content-Disposition headers that interoperates with as many browsers and other clients as possible. This advice should form the basis of a Content-Disposition API.
     38
     39For example, a Python framework might have a method that looks something like:
     40
     41{{{
     42headers.addContentDisposition(disposition, filename, fallback_filename)
     43}}}
     44
     45Note here that both a filename and fallback filename can be passed as parameters, so that both {{{filename}}} and {{{filename*}}} can be populated, even if there isn't a programmatic way to generate the former from the latter.
     46
     47
     48== Frequently Asked Questions ==
     49
     50=== Why shouldn't I just produce the C-D header in UTF-8 directly? ===
     51