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: 2019-Feb-15
Document File: 5 page(s) / 6K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

K. Holtman: AUTHOR

Related Documents

10.17487/RFC2310: DOI

Abstract

This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. 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.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 43% 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’.

Holtman Experimental [Page 1]

RFC 2310 The Safe Response Header Field April 1998

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 large - the form is used to upload a file (see [2]) - the application needs some internationalization features (see [3]) which are only available if the form contents are tran...

Processing...
Loading...