Browse Prior Art Database

The Safe Response Header Field (RFC2310)

IP.com Disclosure Number: IPCOM000002876D
Original Publication Date: 1998-Apr-01
Included in the Prior Art Database: 2000-Sep-13
Document File: 4 page(s) / 7K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K. Holtman: AUTHOR

Abstract

This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way.

This text was extracted from a ASCII Text document.
This is the abbreviated version, containing approximately 40% of the total text.

Network Working Group K. Holtman

Request for Comments: 2310 TUE

Category: Experimental April 1998

The Safe Response Header Field

Status of this Memo

This memo defines an Experimental Protocol for the Internet

community. It does not specify an Internet standard of any kind.

Discussion and suggestions for improvement are requested.

Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (1998). All Rights Reserved.

Abstract

This document defines a HTTP response header field called Safe, which

can be used to indicate that repeating a HTTP request is safe. Such

an indication will allow user agents to handle retries of some safe

requests, in particular safe POST requests, in a more user-friendly

way.

1 Introduction

This document defines a HTTP response header field called Safe, which

can be used to indicate that repeating a HTTP request is safe. Such

an indication will allow user agents to handle retries of some safe

requests, in particular safe POST requests, in a more user-friendly

way.

2 Terminology and Notation

This document uses the HTTP terminology and BNF notation defined in

[1]. It uses the key words in RFC 2119 for defining the significance

of each particular requirement.

3 Rationale

According to Section 9.1.1 (Safe Methods) of the HTTP/1.1

specification [1], POST requests are assumed to be `unsafe' by

default. `Unsafe' means `causes side effects for which the user will

be held accountable'.

It is sometimes necessary for a user agent to repeat a POST request.

Examples of such cases are

- when retrying a POST request which gave an indeterminate error

result in the previous attempt

- when the user presses the RELOAD button while a POST result is

displayed

- when the history function is used to redisplay a POST result

which is no longer in the history buffer.

If the POST request is unsafe, HTTP requires explicit user

confirmation is before the request is repeated. The confirmation

dialog often takes the form of a `repost form data?' dialog box.

This dialog is confusing to many users, and slows down navigation in

any case.

If the repeated POST request is safe, the user-unfriendly

confirmation dialog can be omitted. However plain HTTP/1.1 [1] has

no mechanism by which agents can tell if POST requests are safe, and

they must be assumed unsafe by default. This document adds a

mechanism to HTTP, the Safe header field, for telling if a POST

request is safe.

Using the Safe header field, web applications which require the use

of a safe POST request, rather than a GET request, for the submission

of web forms, can be made more user-friendly. The use of a POST

request may be required for a number of reasons, including

- the contents of the form are potentially very l...