Prefer Header for HTTP
draft-snell-http-prefer-14
The information below is for an old version of the document |
Document |
Type |
|
Active Internet-Draft (individual in app area)
|
|
Author |
|
James Snell
|
|
Last updated |
|
2012-10-12
(latest revision 2012-08-23)
|
|
Stream |
|
IETF
|
|
Intended RFC status |
|
Proposed Standard
|
|
Formats |
|
pdf
htmlized (tools)
htmlized
bibtex
|
|
Reviews |
|
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
None
|
IESG |
IESG state |
|
Waiting for AD Go-Ahead
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
Barry Leiba
|
|
IESG note |
|
Mark Nottingham is the document shepherd.
|
|
Send notices to |
|
jasnell@gmail.com, mnot@mnot.net, draft-snell-http-prefer@tools.ietf.org
|
Network Working Group J. Snell
Internet-Draft August 23, 2012
Intended status: Standards Track
Expires: February 24, 2013
Prefer Header for HTTP
draft-snell-http-prefer-14
Abstract
This specification defines an HTTP header field that can be used by a
client to request that certain behaviors be implemented by a server
while processing a request.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on February 24, 2013.
Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Snell Expires February 24, 2013 [Page 1]
Internet-Draft HTTP Prefer August 2012
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
2. The Prefer Request Header Field . . . . . . . . . . . . . . . 4
2.1. Content Negotiation and Cache Considerations . . . . . . . 6
2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Preference Definitions . . . . . . . . . . . . . . . . . . . . 7
3.1. The "return-asynch" Preference . . . . . . . . . . . . . . 7
3.2. The "return-representation" Preference . . . . . . . . . . 8
3.3. The "return-minimal" Preference . . . . . . . . . . . . . 9
3.4. The "wait" Preference . . . . . . . . . . . . . . . . . . 10
3.5. The "strict" and "lenient" Processing Preferences . . . . 11
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
4.1. The Registry of Preferences . . . . . . . . . . . . . . . 12
4.2. Initial Registry Contents . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14
6. Normative References . . . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16
Snell Expires February 24, 2013 [Page 2]
Internet-Draft HTTP Prefer August 2012
1. Introduction
Within the course of processing an HTTP request there are typically a
range of required and optional behaviors that a server or
intermediary can employ. These often manifest is a variety of subtle
and not-so-subtle ways within the response.
For example, when using the HTTP PUT method to modify a resource --
similar to that defined for the Atom Publishing Protocol [RFC 5023]
-- the server is given the option of returning either a complete
representation of a modified resource or a minimal response that
indicates only the successful completion of the operation. The
selection of which type of response to return to the client generally
has no bearing on the successful processing of the request but could,
for instance, have an impact on what actions the client must take
after receiving the response. That is, returning a representation of
the modified resource within the response can allow the client to
avoid sending an additional subsequent GET request.
Similarly, servers that process requests are often faced with
decisions about how to process requests that may be technically
invalid or incorrect but are still understandable. It might be the
case that the server is able to overlook the technical errors in the
request but still successfully process the request. Depending on the
specific requirements of the application and the nature of the
request being made, the client might or might not consider such
Show full document text