IETF 78 - HTTPbis vs Content-Disposition
Julian Reschke, greenbytes
Problem Statement (1/2)
- RFC2616 includes "Content-Disposition" (RFC 2616, Section 19.5.1),
but also says:
RFC 1806 [35], from which the often implemented Content-Disposition (see Appendix 19.5.1) header field in HTTP is derived, has a number of very serious security considerations. Content-Disposition is not part of the HTTP standard, but since it is widely implemented, we are documenting its use and risks for implementers.
(RFC2616, Section 15.5)
-
Refers to RFC 1806 (definition of Content-Disposition), obsoleted by RFC 2183.
-
I18N for Content-Disposition (filename) relies on on MIME specs RFC 2047, augmented RFC 2184,
which itself was obsoleted by RFC 2231 ('MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations').
Problem Statement (2/2)
- RFC 2183 did not state that it obsoleted RFC 1806, making it hard to find the
up-to-date spec (fixed in RFC Index in the meantime)
- RFC 2231 specifies many features that are not needed in HTTP, but also
fails to REQUIRE common character sets for interoperability
- Interoperability suffers from all of this, see test cases at
http://greenbytes.de/tech/tc2231/ --
Firefox, Konqueror and Opera are fine, the other UAs do not support the I18N extensions
defined in RFC 2231.
Broken Record Warning
Yes, you have seen this before, but there is progress being made!
Current Status
-
Profile RFC 2231 for use in HTTP (remove ambiguities, fix grammar,
remove unneeded features, require a common character set:
draft-reschke-rfc2231-in-http-12).
(Note: does not normatively refer to RFC 2231 so it can evolve independently)
Approved by IESG on the Standards Track in April, to be published as RFC very soon.
-
Profile makes it easier for new HTTP header field definitions to "opt in"
(HTTP Link Header field / Web Linking specification, also in the RFC Editor queue, does this)
Work Left To Do
- Remove from HTTPbis (discussed during IETF-72 in Dublin)
- Move actual definition of Content-Disposition as HTTP header field into
a separate specification (work has started with
draft-reschke-rfc2183-in-http-00)
Volunteers for helping this getting done appreciated.
-
Mention the profile in a yet to be written section about defining new
HTTP headers.