2004/id/draft-holtman-http-safe-02.txt


HTTP Working Group                                     Koen Holtman, TUE
Internet-Draft
Expires: January 29, 1998                                  July 29, 1997


                     The Safe Response Header Field

                     draft-holtman-http-safe-02.txt


STATUS OF THIS MEMO

        This document is an Internet-Draft. Internet-Drafts are
        working documents of the Internet Engineering Task Force
        (IETF), its areas, and its working groups. Note that other
        groups may also distribute working documents as
        Internet-Drafts.

        Internet-Drafts are draft documents valid for a maximum of
        six months and may be updated, replaced, or obsoleted by
        other documents at any time. It is inappropriate to use
        Internet-Drafts as reference material or to cite them other
        than as "work in progress".

        To learn the current status of any Internet-Draft, please
        check the "1id-abstracts.txt" listing contained in the
        Internet-Drafts Shadow Directories on ftp.is.co.za
        (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
        Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
        West Coast).

        Distribution of this document is unlimited.  Please send
        comments to the HTTP working group at
        <http-wg@cuckoo.hpl.hp.com>.  Discussions of the working
        group are archived at
        <URL:http://www.ics.uci.edu/pub/ietf/http/>.  General
        discussions about HTTP and the applications which use HTTP
        should take place on the <www-talk@w3.org> mailing list.

ABSTRACT

   This document proposes a HTTP response header field called Safe,
   which can be used to indicate that repeating the corresponding POST
   request is safe.  Such an indication will allow user agents to
   present services which use safe POSTs in a more user-friendly way.
   Improving the user-friendliness of safe POSTs is considered
   important, because web internationalization will depend for a large
   part on the use of safe POSTs.
                                   

1  Introduction

 This document proposes a HTTP response header field called Safe,
 which can be used to indicate that repeating the corresponding POST
 request is safe.  Such an indication will allow user agents to
 present services which use safe POSTs in a more user-friendly way.
 Improving the user-friendliness of safe POSTs is considered
 important, because web internationalization will depend for a large
 part on the use of safe POSTs.

2 Background

 According to Section 9.1.1 (Safe Methods) of the HTTP/1.1 draft
 specification [1], POST requests are assumed to be `unsafe' by
 default.  `Unsafe' means `causes side effects for which the user will
 be held accountable'.

 If the POST request is unsafe, explicit user confirmation is
 necessary before the request is repeated.  User agents will repeat
 POST requests when the user presses the RELOAD button while a POST
 result is displayed, or when the history function is used to
 redisplay a POST result which is no longer in the history buffer.

 The necessary confirmation dialog often takes the form of a `repost
 form data?'  dialog box.  The dialog is confusing to many users, and
 slows down navigation in any case.

 In theory, if the repeated POST request is safe, the user-unfriendly
 confirmation dialog can be omitted.  However, up till now, HTTP has
 no mechanism by which agents can tell if POST requests are safe.
 This proposal adds such a mechanism.

 Many content authors have managed to avoid the confirmation dialog
 problem by using GETs for form submission instead of safe POSTs.
 However, this escape is not possible for forms

    a) which are (sometimes) used to submit large amounts of data
    b) which are (sometimes) used to submit data in a charset other
       than ISO-8859-1.

 Case b) will be the increasingly common; web internationalization [2]
 makes it necessary to use the POST method for form submission.

   Note: Actually, according to the authors of [2], web
   internationalization makes it necessary to use requests which
   request bodies.  This rules out the use of the only methods which
   are safe under HTTP/1.1: GET and HEAD.  A new GET-WITH-BODY method
   could be defined, but it would be unsafe by default under HTTP/1.1,
   so GET-WITH-HEAD would also need something like the Safe header.

 It is therefore considered important to eliminate the unnecessary
 confirmation dialogs for safe POSTs as soon as possible.  They are a
 counter-incentive to the upgrading of GET based forms services (like
 search engines) to internationalized POST based forms services.

3 The Safe response header

 This header is proposed as an addition to the HTTP/1.x suite.

 The Safe response header field indicates whether repeating the
 request in the corresponding request message is safe in the sense of
 Section 9.1.1 (Safe Methods) of the HTTP/1.1 specification [1].

   Safe        = "Safe" ":" safe-nature
   safe-nature = "yes" | "no"

 An example of the field is:

       Safe: yes

 If the Safe header field is absent in the response, the corresponding
 request must be considered unsafe, unless it is a GET or HEAD
 request.  GET and HEAD requests are safe by definition, user agents
 must ignore a `Safe: no' header field in GET and HEAD responses.

    Note: User agents can use the received information about safety
    when repeating an earlier request.  If the repeating the request
    is known to be safe, the request can be repeated automatically
    without asking for user confirmation.


4 Smooth upgrade path

 That the Safe header provides a smooth upgrade path; if a service
 switches from GETs to safe POSTs, existing browsers will still be
 able to access the service.  Its use requires little re-coding effort
 for service authors and user agent authors, and is optional in any
 case.


5 About syntax

 This document mainly intends to recommend a _mechanism_; the syntax
 of the corresponding header is considered less important.  One
 alternative to the addition of a Safe header would be the addition of
 a `safe' response directive to the Cache-Control header.


6 Alternatives to the Safe header

 A number of alternative ways to solve the confirmation dialog problem
 have been proposed.  These alternative solutions would make the
 introduction of the Safe header unnecessary.

6.1 GET-WITH-BODY

 If a new HTTP/1.x GET-WITH-BODY is defined, one would not need the
 Safe header anymore, one could simply define GET-WITH-BODY as always
 safe.  However, it has been shown that some ugly extensions to the
 HTML form syntax would be needed to provide the same level of
 downwards compatibility with existing browsers that Safe can provide,
 for example

  <form action="..." method=post preferred_method=get-with-body>
   ....
  </form>.

 One could say that a GET-WITH-BODY manages to keep HTTP clean at the
 cost of adding extensions to HTML.  The author of this draft prefers
 to keep HTML clean by adding the Safe extension to HTTP.

 Note that the Safe header does not block the introduction of a
 GET-WITH-BODY in the long run.

6.2 Link

 The need for a confirmation dialog can also be eliminated by offering
 the user agent an alternative to resubmitting the POST request
 altogether.  A POST result could for example have a Link header which
 would contain an URL from which the result can be retrieved again
 with a GET request.  However, this Link URL cannot be very long: it
 it were too long, request would fail due to user agent, proxy, or
 origin server limitations.  This length restriction would make the
 Link solution hard to use in the general case.

6.3 Conclusion

 The Safe header seems to be the best solution in the current
 framework.  Though the existence of alternative solutions like the
 ones above has been asserted, the author of this draft has not seen
 any work on getting alternative solutions standardized.

 The Safe header would eliminate a counter-incentive to web
 internationalization, and the author feels that these
 counter-incentives need to be eliminated as soon as possible.  It is
 therefore proposed to introduce the Safe header into HTTP/1.x without
 undue delay.

 The counter-incentive can be thought of as an interoperability
 problem between HTTP/1.1 [1] and [2].  These documents currently both
 have the Proposed Standard status.  It may be possible to add the
 Safe header to [1] before it goes to Draft Standard.


7 Security considerations

 This proposal adds no new HTTP security considerations.


8 References

   [1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and
       T. Berners-Lee.  Hypertext Transfer Protocol -- HTTP/1.1.  RFC
       2068, HTTP Working Group, January, 1997.

   [2] Yergeau et al, Internationalization of the Hypertext Markup
       Language, Internet-Draft draft-ietf-html-i18n-05.txt, Network
       Working Group, August 7, 1996


9 Author's address

   Koen Holtman
   Technische Universiteit Eindhoven
   Postbus 513
   Kamer HG 6.57
   5600 MB Eindhoven (The Netherlands)
   Email: koen@win.tue.nl


Expires: January 29, 1998

1	wakaba	1.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