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

HTTP Working Group                                     Koen Holtman, TUE
Internet-Draft
Expires: April 10, 1997                                 October 10, 1996


                       The Safe Response Header

                     draft-holtman-http-safe-00.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 called Safe, which
   can be used to label the corresponding POST request as being safe.
   This labeling 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 called Safe, which can
 be used to label the corresponding POST request as being safe.  This
 labeling 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.

 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 the corresponding
 request is safe in the sense of Section 9.1.1 (Safe Methods) of the
 HTTP/1.1 draft specification [1].

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

 An example of the field is:

       Safe: yes

 If the Safe header is absent, 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 request is known to be
    safe, it can be silently repeated 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 Security considerations

 This proposal adds no new HTTP security considerations.


7 References

   [1] Fielding et al, Hypertext Transfer Protocol -- HTTP/1.1.
       Internet-Draft draft-ietf-http-v11-spec-07.txt, HTTP Working
       Group, August 12, 1996

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


8 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: April 10, 1997


1	HTTP Working Group Koen Holtman, TUE
2	Internet-Draft
3	Expires: April 10, 1997 October 10, 1996
4
5
6	The Safe Response Header
7
8	draft-holtman-http-safe-00.txt
9
10
11	STATUS OF THIS MEMO
12
13	This document is an Internet-Draft. Internet-Drafts are
14	working documents of the Internet Engineering Task Force
15	(IETF), its areas, and its working groups. Note that other
16	groups may also distribute working documents as
17	Internet-Drafts.
18
19	Internet-Drafts are draft documents valid for a maximum of
20	six months and may be updated, replaced, or obsoleted by
21	other documents at any time. It is inappropriate to use
22	Internet-Drafts as reference material or to cite them other
23	than as "work in progress".
24
25	To learn the current status of any Internet-Draft, please
26	check the "1id-abstracts.txt" listing contained in the
27	Internet-Drafts Shadow Directories on ftp.is.co.za
28	(Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific
29	Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US
30	West Coast).
31
32	Distribution of this document is unlimited. Please send
33	comments to the HTTP working group at
34	<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
35	group are archived at
36	<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
37	discussions about HTTP and the applications which use HTTP
38	should take place on the <www-talk@w3.org> mailing list.
39
40	ABSTRACT
41
42	This document proposes a HTTP response header called Safe, which
43	can be used to label the corresponding POST request as being safe.
44	This labeling will allow user agents to present services which use
45	safe POSTs in a more user-friendly way. Improving the
46	user-friendliness of safe POSTs is considered important, because
47	web internationalization will depend for a large part on the use of
48	safe POSTs.
49
50
51	1 Introduction
52
53	This document proposes a HTTP response header called Safe, which can
54	be used to label the corresponding POST request as being safe. This
55	labeling will allow user agents to present services which use safe
56	POSTs in a more user-friendly way. Improving the user-friendliness
57	of safe POSTs is considered important, because web
58	internationalization will depend for a large part on the use of safe
59	POSTs.
60
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	It is therefore considered important to eliminate the unnecessary
96	confirmation dialogs for safe POSTs as soon as possible. They are a
97	counter-incentive to the upgrading of GET based forms services (like
98	search engines) to internationalized POST based forms services.
99
100
101	3 The Safe response header
102
103	This header is proposed as an addition to the HTTP/1.x suite.
104
105	The Safe response header field indicates whether the corresponding
106	request is safe in the sense of Section 9.1.1 (Safe Methods) of the
107	HTTP/1.1 draft specification [1].
108
109	Safe = "Safe" ":" safe-nature
110	safe-nature = "yes" \| "no"
111
112	An example of the field is:
113
114	Safe: yes
115
116	If the Safe header is absent, the corresponding request must be
117	considered unsafe, unless it is a GET or HEAD request. GET and HEAD
118	requests are safe by definition, user agents must ignore a `Safe: no'
119	header field in GET and HEAD responses.
120
121	Note: User agents can use the received information about safety
122	when repeating an earlier request. If the request is known to be
123	safe, it can be silently repeated without asking for user
124	confirmation.
125
126
127	4 Smooth upgrade path
128
129	That the Safe header provides a smooth upgrade path; if a service
130	switches from GETs to safe POSTs, existing browsers will still be
131	able to access the service. Its use requires little re-coding effort
132	for service authors and user agent authors, and is optional in any
133	case.
134
135
136	5 About syntax
137
138	This document mainly intends to recommend a _mechanism_; the syntax
139	of the corresponding header is considered less important. One
140	alternative to the addition of a Safe header would be the addition of
141	a `safe' response directive to the Cache-Control header.
142
143
144	6 Security considerations
145
146	This proposal adds no new HTTP security considerations.
147
148
149	7 References
150
151	[1] Fielding et al, Hypertext Transfer Protocol -- HTTP/1.1.
152	Internet-Draft draft-ietf-http-v11-spec-07.txt, HTTP Working
153	Group, August 12, 1996
154
155	[2] Yergeau et al, Internationalization of the Hypertext Markup
156	Language, Internet-Draft draft-ietf-html-i18n-05.txt, Network
157	Working Group, August 7, 1996
158
159
160	8 Author's address
161
162	Koen Holtman
163	Technische Universiteit Eindhoven
164	Postbus 513
165	Kamer HG 6.57
166	5600 MB Eindhoven (The Netherlands)
167	Email: koen@win.tue.nl
168
169
170	Expires: April 10, 1997
171
172