-
Notifications
You must be signed in to change notification settings - Fork 48
/
Copy pathietf-77-http2231.xhtml
executable file
·104 lines (100 loc) · 3.98 KB
/
ietf-77-http2231.xhtml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>IETF 77 - HTTPbis vs RFC2231</title>
<style type="text/css">
body {
color: black;
font-family: verdana, helvetica, arial, sans-serif;
font-size: 18pt;
}
h1 {
font-size: 36pt;
}
li {
margin-top: 0.5em;
}
q {
font-style: italic;
}
.break {
page-break-before: always;
}
@page {
size: a4 landscape;
}
@page {
@bottom-left {
content: "Julian Reschke, greenbytes";
}
@bottom-right {
content: counter(page);
}
@top-center {
content: "IETF 77 - HTTPbis vs RFC2231";
}
}
</style>
</head>
<body>
<h1>IETF 77 - HTTPbis vs RFC2231</h1>
<p>
<a href="mailto:[email protected]">Julian Reschke</a>, greenbytes
</p>
<h2 class="break">Problem Statement (1/2)</h2>
<ul>
<li>RFC2616 includes "Content-Disposition" (<a href="http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.19.5.1">RFC 2616, Section 19.5.1)</a>,
but also says:
<br />
<q>RFC 1806 [35], from which the often implemented Content-Disposition (see Appendix 19.5.1) header 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.</q>
(<a href="http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.15.5">RFC2616, Section 15.5</a>)
</li>
<li>
Refers to RFC 1806 (definition of Content-Disposition), obsoleted by RFC 2183.
</li>
<li>
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').
</li>
</ul>
<h2 class="break">Problem Statement (2/2)</h2>
<ul>
<li>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)</li>
<li>RFC 2231 specifies many features that are not needed in HTTP, but also
fails to REQUIRE common character sets for interoperability</li>
<li>Interoperability suffers from all of this, see test cases at
<a href="http://greenbytes.de/tech/tc2231/">http://greenbytes.de/tech/tc2231/</a> --
Firefox, Konqueror and Opera are fine, the other UAs do not support the I18N extensions
defined in RFC 2231.
</li>
</ul>
<h2 class="break">Proposal</h2>
<ul>
<li>Remove from HTTPbis (discussed during IETF-72 in Dublin)</li>
<li>
Profile RFC 2231 for use in HTTP (remove ambiguities, fix grammar,
remove unneeded features, require a common character set:
<a href="http://greenbytes.de/tech/webdav/draft-reschke-rfc2231-in-http-10.html">draft-reschke-rfc2231-in-http-10</a>).
<br/>
<small>(Note: does not normatively refer to RFC 2231 so it can evolve independently)</small>
<br/>
<em><b>In IETF Last Call - ending 2010-03-22 (yes, today!)</b></em>
</li>
<li>
Profile makes it easier for new HTTP header definitions to "opt in"
(HTTP Link Header / Web Linking specification, past IETF LC, does this)
</li>
<li>Get feedback from "other" UA vendors (I was told that profiling RFC 2231 made it more reasonable to implement)</li>
<li>Move actual definition of Content-Disposition as HTTP header into
a separate specification (work has started with
<a href="http://greenbytes.de/tech/webdav/draft-reschke-rfc2183-in-http-00.html">draft-reschke-rfc2183-in-http-00</a>)
</li>
<li>
Mention the profile in a yet to be written section about defining new
HTTP headers.
</li>
</ul>
</body>
</html>