Version 1 (modified by mnot@…, 8 years ago) (diff)


HTTP Frameworks and the Content-Disposition Header

The IETF HTTPbis Working Group has recently published RFC6266, "Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol."

This specification is the result of extensive testing (detail) of existing Web browsers and other clients, as well as ongoing work with browser vendors to improve their implementations.

This 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.

Why HTTP Frameworks Should Have a Content-Disposition API

While 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.

In simple cases, Content-Disposition looks something like this:

Content-Disposition: attachment; filename=example.html

However, when the filename has non-ASCII characters in it, it needs to be encoded as described in RFC5987. For example:

Content-Disposition: attachment;
                     filename="EURO rates";

Similarly, 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.

Note 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).

Sample API for Content-Disposition Generation

RFC6266 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.

For example, a Python framework might have a method that looks something like:

headers.addContentDisposition(disposition, filename, fallback_filename)

Note 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.

Frequently Asked Questions

Why shouldn't I just produce the C-D header in UTF-8 directly?