1 |
|
2 |
HTTP Working Group Koen Holtman, TUE |
3 |
Internet-Draft |
4 |
Expires: January 29, 1998 July 29, 1997 |
5 |
|
6 |
|
7 |
The Safe Response Header Field |
8 |
|
9 |
draft-holtman-http-safe-02.txt |
10 |
|
11 |
|
12 |
STATUS OF THIS MEMO |
13 |
|
14 |
This document is an Internet-Draft. Internet-Drafts are |
15 |
working documents of the Internet Engineering Task Force |
16 |
(IETF), its areas, and its working groups. Note that other |
17 |
groups may also distribute working documents as |
18 |
Internet-Drafts. |
19 |
|
20 |
Internet-Drafts are draft documents valid for a maximum of |
21 |
six months and may be updated, replaced, or obsoleted by |
22 |
other documents at any time. It is inappropriate to use |
23 |
Internet-Drafts as reference material or to cite them other |
24 |
than as "work in progress". |
25 |
|
26 |
To learn the current status of any Internet-Draft, please |
27 |
check the "1id-abstracts.txt" listing contained in the |
28 |
Internet-Drafts Shadow Directories on ftp.is.co.za |
29 |
(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific |
30 |
Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US |
31 |
West Coast). |
32 |
|
33 |
Distribution of this document is unlimited. Please send |
34 |
comments to the HTTP working group at |
35 |
<http-wg@cuckoo.hpl.hp.com>. Discussions of the working |
36 |
group are archived at |
37 |
<URL:http://www.ics.uci.edu/pub/ietf/http/>. General |
38 |
discussions about HTTP and the applications which use HTTP |
39 |
should take place on the <www-talk@w3.org> mailing list. |
40 |
|
41 |
ABSTRACT |
42 |
|
43 |
This document proposes a HTTP response header field called Safe, |
44 |
which can be used to indicate that repeating the corresponding POST |
45 |
request is safe. Such an indication will allow user agents to |
46 |
present services which use safe POSTs in a more user-friendly way. |
47 |
Improving the user-friendliness of safe POSTs is considered |
48 |
important, because web internationalization will depend for a large |
49 |
part on the use of safe POSTs. |
50 |
|
51 |
|
52 |
1 Introduction |
53 |
|
54 |
This document proposes a HTTP response header field called Safe, |
55 |
which can be used to indicate that repeating the corresponding POST |
56 |
request is safe. Such an indication will allow user agents to |
57 |
present services which use safe POSTs in a more user-friendly way. |
58 |
Improving the user-friendliness of safe POSTs is considered |
59 |
important, because web internationalization will depend for a large |
60 |
part on the use of safe POSTs. |
61 |
|
62 |
2 Background |
63 |
|
64 |
According to Section 9.1.1 (Safe Methods) of the HTTP/1.1 draft |
65 |
specification [1], POST requests are assumed to be `unsafe' by |
66 |
default. `Unsafe' means `causes side effects for which the user will |
67 |
be held accountable'. |
68 |
|
69 |
If the POST request is unsafe, explicit user confirmation is |
70 |
necessary before the request is repeated. User agents will repeat |
71 |
POST requests when the user presses the RELOAD button while a POST |
72 |
result is displayed, or when the history function is used to |
73 |
redisplay a POST result which is no longer in the history buffer. |
74 |
|
75 |
The necessary confirmation dialog often takes the form of a `repost |
76 |
form data?' dialog box. The dialog is confusing to many users, and |
77 |
slows down navigation in any case. |
78 |
|
79 |
In theory, if the repeated POST request is safe, the user-unfriendly |
80 |
confirmation dialog can be omitted. However, up till now, HTTP has |
81 |
no mechanism by which agents can tell if POST requests are safe. |
82 |
This proposal adds such a mechanism. |
83 |
|
84 |
Many content authors have managed to avoid the confirmation dialog |
85 |
problem by using GETs for form submission instead of safe POSTs. |
86 |
However, this escape is not possible for forms |
87 |
|
88 |
a) which are (sometimes) used to submit large amounts of data |
89 |
b) which are (sometimes) used to submit data in a charset other |
90 |
than ISO-8859-1. |
91 |
|
92 |
Case b) will be the increasingly common; web internationalization [2] |
93 |
makes it necessary to use the POST method for form submission. |
94 |
|
95 |
Note: Actually, according to the authors of [2], web |
96 |
internationalization makes it necessary to use requests which |
97 |
request bodies. This rules out the use of the only methods which |
98 |
are safe under HTTP/1.1: GET and HEAD. A new GET-WITH-BODY method |
99 |
could be defined, but it would be unsafe by default under HTTP/1.1, |
100 |
so GET-WITH-HEAD would also need something like the Safe header. |
101 |
|
102 |
It is therefore considered important to eliminate the unnecessary |
103 |
confirmation dialogs for safe POSTs as soon as possible. They are a |
104 |
counter-incentive to the upgrading of GET based forms services (like |
105 |
search engines) to internationalized POST based forms services. |
106 |
|
107 |
3 The Safe response header |
108 |
|
109 |
This header is proposed as an addition to the HTTP/1.x suite. |
110 |
|
111 |
The Safe response header field indicates whether repeating the |
112 |
request in the corresponding request message is safe in the sense of |
113 |
Section 9.1.1 (Safe Methods) of the HTTP/1.1 specification [1]. |
114 |
|
115 |
Safe = "Safe" ":" safe-nature |
116 |
safe-nature = "yes" | "no" |
117 |
|
118 |
An example of the field is: |
119 |
|
120 |
Safe: yes |
121 |
|
122 |
If the Safe header field is absent in the response, the corresponding |
123 |
request must be considered unsafe, unless it is a GET or HEAD |
124 |
request. GET and HEAD requests are safe by definition, user agents |
125 |
must ignore a `Safe: no' header field in GET and HEAD responses. |
126 |
|
127 |
Note: User agents can use the received information about safety |
128 |
when repeating an earlier request. If the repeating the request |
129 |
is known to be safe, the request can be repeated automatically |
130 |
without asking for user confirmation. |
131 |
|
132 |
|
133 |
4 Smooth upgrade path |
134 |
|
135 |
That the Safe header provides a smooth upgrade path; if a service |
136 |
switches from GETs to safe POSTs, existing browsers will still be |
137 |
able to access the service. Its use requires little re-coding effort |
138 |
for service authors and user agent authors, and is optional in any |
139 |
case. |
140 |
|
141 |
|
142 |
5 About syntax |
143 |
|
144 |
This document mainly intends to recommend a _mechanism_; the syntax |
145 |
of the corresponding header is considered less important. One |
146 |
alternative to the addition of a Safe header would be the addition of |
147 |
a `safe' response directive to the Cache-Control header. |
148 |
|
149 |
|
150 |
6 Alternatives to the Safe header |
151 |
|
152 |
A number of alternative ways to solve the confirmation dialog problem |
153 |
have been proposed. These alternative solutions would make the |
154 |
introduction of the Safe header unnecessary. |
155 |
|
156 |
6.1 GET-WITH-BODY |
157 |
|
158 |
If a new HTTP/1.x GET-WITH-BODY is defined, one would not need the |
159 |
Safe header anymore, one could simply define GET-WITH-BODY as always |
160 |
safe. However, it has been shown that some ugly extensions to the |
161 |
HTML form syntax would be needed to provide the same level of |
162 |
downwards compatibility with existing browsers that Safe can provide, |
163 |
for example |
164 |
|
165 |
<form action="..." method=post preferred_method=get-with-body> |
166 |
.... |
167 |
</form>. |
168 |
|
169 |
One could say that a GET-WITH-BODY manages to keep HTTP clean at the |
170 |
cost of adding extensions to HTML. The author of this draft prefers |
171 |
to keep HTML clean by adding the Safe extension to HTTP. |
172 |
|
173 |
Note that the Safe header does not block the introduction of a |
174 |
GET-WITH-BODY in the long run. |
175 |
|
176 |
6.2 Link |
177 |
|
178 |
The need for a confirmation dialog can also be eliminated by offering |
179 |
the user agent an alternative to resubmitting the POST request |
180 |
altogether. A POST result could for example have a Link header which |
181 |
would contain an URL from which the result can be retrieved again |
182 |
with a GET request. However, this Link URL cannot be very long: it |
183 |
it were too long, request would fail due to user agent, proxy, or |
184 |
origin server limitations. This length restriction would make the |
185 |
Link solution hard to use in the general case. |
186 |
|
187 |
6.3 Conclusion |
188 |
|
189 |
The Safe header seems to be the best solution in the current |
190 |
framework. Though the existence of alternative solutions like the |
191 |
ones above has been asserted, the author of this draft has not seen |
192 |
any work on getting alternative solutions standardized. |
193 |
|
194 |
The Safe header would eliminate a counter-incentive to web |
195 |
internationalization, and the author feels that these |
196 |
counter-incentives need to be eliminated as soon as possible. It is |
197 |
therefore proposed to introduce the Safe header into HTTP/1.x without |
198 |
undue delay. |
199 |
|
200 |
The counter-incentive can be thought of as an interoperability |
201 |
problem between HTTP/1.1 [1] and [2]. These documents currently both |
202 |
have the Proposed Standard status. It may be possible to add the |
203 |
Safe header to [1] before it goes to Draft Standard. |
204 |
|
205 |
|
206 |
7 Security considerations |
207 |
|
208 |
This proposal adds no new HTTP security considerations. |
209 |
|
210 |
|
211 |
8 References |
212 |
|
213 |
[1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and |
214 |
T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC |
215 |
2068, HTTP Working Group, January, 1997. |
216 |
|
217 |
[2] Yergeau et al, Internationalization of the Hypertext Markup |
218 |
Language, Internet-Draft draft-ietf-html-i18n-05.txt, Network |
219 |
Working Group, August 7, 1996 |
220 |
|
221 |
|
222 |
9 Author's address |
223 |
|
224 |
Koen Holtman |
225 |
Technische Universiteit Eindhoven |
226 |
Postbus 513 |
227 |
Kamer HG 6.57 |
228 |
5600 MB Eindhoven (The Netherlands) |
229 |
Email: koen@win.tue.nl |
230 |
|
231 |
|
232 |
Expires: January 29, 1998 |
233 |
|