< draft-holtman-http-safe-01.txt		draft-holtman-http-safe-02.txt >
	HTTP Working Group Koen Holtman, TUE		HTTP Working Group Koen Holtman, TUE
	Internet-Draft		Internet-Draft
	Expires: May 24, 1997 November 24, 1996		Expires: January 29, 1998 July 29, 1997
	The Safe Response Header		The Safe Response Header Field
	draft-holtman-http-safe-01.txt		draft-holtman-http-safe-02.txt
	STATUS OF THIS MEMO		STATUS OF THIS MEMO
	This document is an Internet-Draft. Internet-Drafts are		This document is an Internet-Draft. Internet-Drafts are
	working documents of the Internet Engineering Task Force		working documents of the Internet Engineering Task Force
	(IETF), its areas, and its working groups. Note that other		(IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as		groups may also distribute working documents as
	Internet-Drafts.		Internet-Drafts.
	Internet-Drafts are draft documents valid for a maximum of		Internet-Drafts are draft documents valid for a maximum of
	skipping to change at line 41 ¶		skipping to change at line 41 ¶
	Distribution of this document is unlimited. Please send		Distribution of this document is unlimited. Please send
	comments to the HTTP working group at		comments to the HTTP working group at
	<http-wg@cuckoo.hpl.hp.com>. Discussions of the working		<http-wg@cuckoo.hpl.hp.com>. Discussions of the working
	group are archived at		group are archived at
	<URL:http://www.ics.uci.edu/pub/ietf/http/>. General		<URL:http://www.ics.uci.edu/pub/ietf/http/>. General
	discussions about HTTP and the applications which use HTTP		discussions about HTTP and the applications which use HTTP
	should take place on the <www-talk@w3.org> mailing list.		should take place on the <www-talk@w3.org> mailing list.
	ABSTRACT		ABSTRACT
	This document proposes a HTTP response header called Safe, which		This document proposes a HTTP response header field called Safe,
	can be used to label the corresponding POST request as being safe.		which can be used to indicate that repeating the corresponding POST
	This labeling will allow user agents to present services which use		request is safe. Such an indication will allow user agents to
	safe POSTs in a more user-friendly way. Improving the		present services which use safe POSTs in a more user-friendly way.
	user-friendliness of safe POSTs is considered important, because		Improving the user-friendliness of safe POSTs is considered
	web internationalization will depend for a large part on the use of		important, because web internationalization will depend for a large
	safe POSTs.		part on the use of safe POSTs.
	1 Introduction		1 Introduction
	This document proposes a HTTP response header called Safe, which can		This document proposes a HTTP response header field called Safe,
	be used to label the corresponding POST request as being safe. This		which can be used to indicate that repeating the corresponding POST
	labeling will allow user agents to present services which use safe		request is safe. Such an indication will allow user agents to
	POSTs in a more user-friendly way. Improving the user-friendliness		present services which use safe POSTs in a more user-friendly way.
	of safe POSTs is considered important, because web		Improving the user-friendliness of safe POSTs is considered
	internationalization will depend for a large part on the use of safe		important, because web internationalization will depend for a large
	POSTs.		part on the use of safe POSTs.
	1.1 Revision history
	Changes with respect to the 00 version of this document:
	- a note was added to Section 2
	- Section 6 was added.
	2 Background		2 Background
	According to Section 9.1.1 (Safe Methods) of the HTTP/1.1 draft		According to Section 9.1.1 (Safe Methods) of the HTTP/1.1 draft
	specification [1], POST requests are assumed to be `unsafe' by		specification [1], POST requests are assumed to be `unsafe' by
	default. `Unsafe' means `causes side effects for which the user will		default. `Unsafe' means `causes side effects for which the user will
	be held accountable'.		be held accountable'.
	If the POST request is unsafe, explicit user confirmation is		If the POST request is unsafe, explicit user confirmation is
	necessary before the request is repeated. User agents will repeat		necessary before the request is repeated. User agents will repeat
	skipping to change at line 116 ¶		skipping to change at line 108 ¶
	It is therefore considered important to eliminate the unnecessary		It is therefore considered important to eliminate the unnecessary
	confirmation dialogs for safe POSTs as soon as possible. They are a		confirmation dialogs for safe POSTs as soon as possible. They are a
	counter-incentive to the upgrading of GET based forms services (like		counter-incentive to the upgrading of GET based forms services (like
	search engines) to internationalized POST based forms services.		search engines) to internationalized POST based forms services.
	3 The Safe response header		3 The Safe response header
	This header is proposed as an addition to the HTTP/1.x suite.		This header is proposed as an addition to the HTTP/1.x suite.
	The Safe response header field indicates whether the corresponding		The Safe response header field indicates whether repeating the
	request is safe in the sense of Section 9.1.1 (Safe Methods) of the		request in the corresponding request message is safe in the sense of
	HTTP/1.1 draft specification [1].		Section 9.1.1 (Safe Methods) of the HTTP/1.1 specification [1].
	Safe = "Safe" ":" safe-nature		Safe = "Safe" ":" safe-nature
	safe-nature = "yes" | "no"		safe-nature = "yes" | "no"
	An example of the field is:		An example of the field is:
	Safe: yes		Safe: yes
	If the Safe header is absent, the corresponding request must be		If the Safe header field is absent in the response, the corresponding
	considered unsafe, unless it is a GET or HEAD request. GET and HEAD		request must be considered unsafe, unless it is a GET or HEAD
	requests are safe by definition, user agents must ignore a `Safe: no'		request. GET and HEAD requests are safe by definition, user agents
	header field in GET and HEAD responses.		must ignore a `Safe: no' header field in GET and HEAD responses.
	Note: User agents can use the received information about safety		Note: User agents can use the received information about safety
	when repeating an earlier request. If the request is known to be		when repeating an earlier request. If the repeating the request
	safe, it can be silently repeated without asking for user		is known to be safe, the request can be repeated automatically
	confirmation.		without asking for user confirmation.
	4 Smooth upgrade path		4 Smooth upgrade path
	That the Safe header provides a smooth upgrade path; if a service		That the Safe header provides a smooth upgrade path; if a service
	switches from GETs to safe POSTs, existing browsers will still be		switches from GETs to safe POSTs, existing browsers will still be
	able to access the service. Its use requires little re-coding effort		able to access the service. Its use requires little re-coding effort
	for service authors and user agent authors, and is optional in any		for service authors and user agent authors, and is optional in any
	case.		case.
	5 About syntax		5 About syntax
	skipping to change at line 213 ¶		skipping to change at line 205 ¶
	problem between HTTP/1.1 [1] and [2]. These documents currently both		problem between HTTP/1.1 [1] and [2]. These documents currently both
	have the Proposed Standard status. It may be possible to add the		have the Proposed Standard status. It may be possible to add the
	Safe header to [1] before it goes to Draft Standard.		Safe header to [1] before it goes to Draft Standard.
	7 Security considerations		7 Security considerations
	This proposal adds no new HTTP security considerations.		This proposal adds no new HTTP security considerations.
	8 References		8 References
	[1] Fielding et al, Hypertext Transfer Protocol -- HTTP/1.1.		[1] R. Fielding, J. Gettys, J. C. Mogul, H. Frystyk, and
	Internet-Draft draft-ietf-http-v11-spec-07.txt, HTTP Working		T. Berners-Lee. Hypertext Transfer Protocol -- HTTP/1.1. RFC
	Group, August 12, 1996		2068, HTTP Working Group, January, 1997.
	[2] Yergeau et al, Internationalization of the Hypertext Markup		[2] Yergeau et al, Internationalization of the Hypertext Markup
	Language, Internet-Draft draft-ietf-html-i18n-05.txt, Network		Language, Internet-Draft draft-ietf-html-i18n-05.txt, Network
	Working Group, August 7, 1996		Working Group, August 7, 1996
	9 Author's address		9 Author's address
	Koen Holtman		Koen Holtman
	Technische Universiteit Eindhoven		Technische Universiteit Eindhoven
	Postbus 513		Postbus 513
	Kamer HG 6.57		Kamer HG 6.57
	5600 MB Eindhoven (The Netherlands)		5600 MB Eindhoven (The Netherlands)
	Email: koen@win.tue.nl		Email: koen@win.tue.nl
	Expires: May 24, 1997		Expires: January 29, 1998
End of changes. 10 change blocks.
	38 lines changed or deleted		30 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/