draft-ietf-httpbis-p2-semantics-00.txt   draft-ietf-httpbis-p2-semantics-01.txt 
Network Working Group R. Fielding, Ed. Network Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2068, 2616 J. Gettys Obsoletes: 2616 (if approved) J. Gettys
(if approved) One Laptop per Child Intended status: Standards Track One Laptop per Child
Intended status: Standards Track J. Mogul Expires: July 15, 2008 J. Mogul
Expires: June 22, 2008 HP HP
H. Frystyk H. Frystyk
Microsoft Microsoft
L. Masinter L. Masinter
Adobe Systems Adobe Systems
P. Leach P. Leach
Microsoft Microsoft
T. Berners-Lee T. Berners-Lee
W3C/MIT W3C/MIT
December 20, 2007 Y. Lafon, Ed.
W3C
J. Reschke, Ed.
greenbytes
January 12, 2008
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-00 draft-ietf-httpbis-p2-semantics-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 45 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on June 22, 2008. This Internet-Draft will expire on July 15, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information protocol for distributed, collaborative, hypermedia information
systems. HTTP has been in use by the World Wide Web global systems. HTTP has been in use by the World Wide Web global
information initiative since 1990. This document is Part 2 of the information initiative since 1990. This document is Part 2 of the
seven-part specification that defines the protocol referred to as seven-part specification that defines the protocol referred to as
"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines
the semantics of HTTP messages as expressed by request methods, the semantics of HTTP messages as expressed by request methods,
request-header fields, response status codes, and response-header request-header fields, response status codes, and response-header
fields. fields.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
This version of the HTTP specification contains only minimal
editorial changes from [RFC2616] (abstract, introductory paragraph,
and authors' addresses). All other changes are due to partitioning
the original into seven mostly independent parts. The intent is for
readers of future drafts to able to use draft 00 as the basis for
comparison when the WG makes later changes to the specification text.
This draft will shortly be followed by draft 01 (containing the first
round of changes that have already been agreed to on the mailing
list). There is no point in reviewing this draft other than to
verify that the partitioning has been done correctly. Roy T.
Fielding, Yves Lafon, and Julian Reschke will be the editors after
draft 00 is submitted.
Discussion of this draft should take place on the HTTPBIS working Discussion of this draft should take place on the HTTPBIS working
group mailing list (ietf-http-wg@w3.org). The current issues list is group mailing list (ietf-http-wg@w3.org). The current issues list is
at <http://www3.tools.ietf.org/wg/httpbis/trac/report/11> and related at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://www3.tools.ietf.org/wg/httpbis/>. <http://www.tools.ietf.org/wg/httpbis/>.
This draft incorporates those issue resolutions that were either
collected in the original RFC2616 errata list
(<http://purl.org/NET/http-errata>), or which were agreed upon on the
mailing list between October 2006 and November 2007 (as published in
"draft-lafon-rfc2616bis-03").
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 6 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 7 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 7
6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 9 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 8
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 10
8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 10 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 10 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 11
8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 10 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 11
8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 10 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 11
8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 11
8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 16 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 16 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17
9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 16 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 17
9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 17 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 17
9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 17 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 18
9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 18
9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 17 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 18 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 18
9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 18 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 19
9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 18 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 19
9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 19 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 19
9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 19 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 20
9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 19 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 20
9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 19 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 20
9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 20 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 20
9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 20 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 21
9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 21 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 21
9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 21 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 22
9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 21 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 22
9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 22 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 22
9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 22 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 23
9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 22 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 23
9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 23 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 23
9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 23 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 24
9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 23 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 24
9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 23 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 24
9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 23 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 24
9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 23 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 24
9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 23 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 24
9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 24 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 24
9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 24 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 25
9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 24 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 25
9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 25 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 25
9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 25 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 26
9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 25 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 26
9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 25 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 26
9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 26 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 26
9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 26 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 27
9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 26 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 27
9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 26 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 27
9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 26 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 27
9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 26 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 27
9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 27 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 27
9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 27 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 28
9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 27 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 28
9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 27 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 28
9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 27 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 28
10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 28 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 28
10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 29
10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 28 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 29
10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 30 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 32
10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 31 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 33
10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 32 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 33
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 34
12. Security Considerations . . . . . . . . . . . . . . . . . . . 33 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
12.1. Transfer of Sensitive Information . . . . . . . . . . . . 33 12. Security Considerations . . . . . . . . . . . . . . . . . . . 34
12.2. Encoding Sensitive Information in URI's . . . . . . . . . 34 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 34
12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 34 12.2. Encoding Sensitive Information in URI's . . . . . . . . . 35
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 34 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 36
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Changes from RFC 2068 . . . . . . . . . . . . . . . . 36 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 40 14.2. Informative References . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 43 Appendix A. Compatibility with Previous Versions . . . . . . . . 37
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 37
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 38
Appendix B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 39
B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 39
B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 39
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . . . . 47
1. Introduction 1. Introduction
This document will define aspects of HTTP related to request and This document defines HTTP/1.1 request and response semantics. Each
response semantics. Right now it only includes the extracted HTTP message, as defined in [Part1], is in the form of either a
relevant sections of RFC 2616 with only minor edits. request or a response. An HTTP server listens on a connection for
HTTP requests and responds to each request, in the order received on
that connection, with one or more HTTP response messages. This
document defines the commonly agreed upon semantics of the HTTP
uniform interface, the intentions defined by each request method, and
the various response messages that might be expected as a result of
applying that method for the requested resource.
The HTTP protocol is a request/response protocol. A client sends a This document is currently disorganized in order to minimize the
request to the server in the form of a request method, URI, and changes between drafts and enable reviewers to see the smaller errata
protocol version, followed by a MIME-like message containing request changes. The next draft will reorganize the sections to better
modifiers, client information, and possible body content over a reflect the content. In particular, the sections will be ordered
connection with a server. The server responds with a status line, according to the typical processing of an HTTP request message (after
including the message's protocol version and a success or error code, message parsing): resource mapping, general header fields, methods,
followed by a MIME-like message containing server information, entity request modifiers, response status, and resource metadata. The
metainformation, and possible entity-body content. The relationship current mess reflects how widely dispersed these topics and
between HTTP and MIME is described in Appendix A of [Part3]. associated requirements had become in [RFC2616].
1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it
implements. An implementation that satisfies all the MUST or
REQUIRED level and all the SHOULD level requirements for its
protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD
level requirements for its protocols is said to be "conditionally
compliant."
2. Product Tokens 2. Product Tokens
Product tokens are used to allow communicating applications to Product tokens are used to allow communicating applications to
identify themselves by software name and version. Most fields using identify themselves by software name and version. Most fields using
product tokens also allow sub-products which form a significant part product tokens also allow sub-products which form a significant part
of the application to be listed, separated by white space. By of the application to be listed, separated by white space. By
convention, the products are listed in order of their significance convention, the products are listed in order of their significance
for identifying the application. for identifying the application.
skipping to change at page 7, line 35 skipping to change at page 8, line 39
Request-header field names can be extended reliably only in Request-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of request- experimental header fields MAY be given the semantics of request-
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be request-header fields. Unrecognized header fields are treated as be request-header fields. Unrecognized header fields are treated as
entity-header fields. entity-header fields.
5. Status Code and Reason Phrase 5. Status Code and Reason Phrase
The Status-Code element is a 3-digit integer result code of the The Status-Code element is a 3-digit integer result code of the
attempt to understand and satisfy the request. These codes are fully attempt to understand and satisfy the request. The status codes
defined in Section 9. The Reason-Phrase is intended to give a short listed below are defined in Section 9. The Reason-Phrase is intended
textual description of the Status-Code. The Status-Code is intended to give a short textual description of the Status-Code. The Status-
for use by automata and the Reason-Phrase is intended for the human Code is intended for use by automata and the Reason-Phrase is
user. The client is not required to examine or display the Reason- intended for the human user. The client is not required to examine
Phrase. or display the Reason-Phrase.
The individual values of the numeric status codes defined for The individual values of the numeric status codes defined for
HTTP/1.1, and an example set of corresponding Reason-Phrase's, are HTTP/1.1, and an example set of corresponding Reason-Phrase's, are
presented below. The reason phrases listed here are only presented below. The reason phrases listed here are only
recommendations -- they MAY be replaced by local equivalents without recommendations -- they MAY be replaced by local equivalents without
affecting the protocol. affecting the protocol.
Status-Code = Status-Code =
"100" ; Section 9.1.1: Continue "100" ; Section 9.1.1: Continue
| "101" ; Section 9.1.2: Switching Protocols | "101" ; Section 9.1.2: Switching Protocols
skipping to change at page 9, line 24 skipping to change at page 10, line 24
readable information which will explain the unusual status. readable information which will explain the unusual status.
6. Response Header Fields 6. Response Header Fields
The response-header fields allow the server to pass additional The response-header fields allow the server to pass additional
information about the response which cannot be placed in the Status- information about the response which cannot be placed in the Status-
Line. These header fields give information about the server and Line. These header fields give information about the server and
about further access to the resource identified by the Request-URI. about further access to the resource identified by the Request-URI.
response-header = Accept-Ranges ; [Part5], Section 5.1 response-header = Accept-Ranges ; [Part5], Section 5.1
| Age ; [Part6], Section 3.1 | Age ; [Part6], Section 15.1
| ETag ; [Part4], Section 6.1 | ETag ; [Part4], Section 6.1
| Location ; Section 10.4 | Location ; Section 10.4
| Proxy-Authenticate ; [Part7], Section 3.2 | Proxy-Authenticate ; [Part7], Section 3.2
| Retry-After ; Section 10.7 | Retry-After ; Section 10.7
| Server ; Section 10.8 | Server ; Section 10.8
| Vary ; [Part6], Section 3.5 | Vary ; [Part6], Section 15.5
| WWW-Authenticate ; [Part7], Section 3.4 | WWW-Authenticate ; [Part7], Section 3.4
Response-header field names can be extended reliably only in Response-header field names can be extended reliably only in
combination with a change in the protocol version. However, new or combination with a change in the protocol version. However, new or
experimental header fields MAY be given the semantics of response- experimental header fields MAY be given the semantics of response-
header fields if all parties in the communication recognize them to header fields if all parties in the communication recognize them to
be response-header fields. Unrecognized header fields are treated as be response-header fields. Unrecognized header fields are treated as
entity-header fields. entity-header fields.
7. Entity 7. Entity
skipping to change at page 13, line 19 skipping to change at page 14, line 19
information contained in the response MAY be used to update a information contained in the response MAY be used to update a
previously cached entity from that resource. If the new field values previously cached entity from that resource. If the new field values
indicate that the cached entity differs from the current entity (as indicate that the cached entity differs from the current entity (as
would be indicated by a change in Content-Length, Content-MD5, ETag would be indicated by a change in Content-Length, Content-MD5, ETag
or Last-Modified), then the cache MUST treat the cache entry as or Last-Modified), then the cache MUST treat the cache entry as
stale. stale.
8.5. POST 8.5. POST
The POST method is used to request that the origin server accept the The POST method is used to request that the origin server accept the
entity enclosed in the request as a new subordinate of the resource entity enclosed in the request as data to be processed by the
identified by the Request-URI in the Request-Line. POST is designed resource identified by the Request-URI in the Request-Line. POST is
to allow a uniform method to cover the following functions: designed to allow a uniform method to cover the following functions:
o Annotation of existing resources; o Annotation of existing resources;
o Posting a message to a bulletin board, newsgroup, mailing list, or o Posting a message to a bulletin board, newsgroup, mailing list, or
similar group of articles; similar group of articles;
o Providing a block of data, such as the result of submitting a o Providing a block of data, such as the result of submitting a
form, to a data-handling process; form, to a data-handling process;
o Extending a database through an append operation. o Extending a database through an append operation.
The actual function performed by the POST method is determined by the The actual function performed by the POST method is determined by the
server and is usually dependent on the Request-URI. The posted server and is usually dependent on the Request-URI.
entity is subordinate to that URI in the same way that a file is
subordinate to a directory containing it, a news article is
subordinate to a newsgroup to which it is posted, or a record is
subordinate to a database.
The action performed by the POST method might not result in a The action performed by the POST method might not result in a
resource that can be identified by a URI. In this case, either 200 resource that can be identified by a URI. In this case, either 200
(OK) or 204 (No Content) is the appropriate response status, (OK) or 204 (No Content) is the appropriate response status,
depending on whether or not the response includes an entity that depending on whether or not the response includes an entity that
describes the result. describes the result.
If a resource has been created on the origin server, the response If a resource has been created on the origin server, the response
SHOULD be 201 (Created) and contain an entity which describes the SHOULD be 201 (Created) and contain an entity which describes the
status of the request and refers to the new resource, and a Location status of the request and refers to the new resource, and a Location
header (see Section 10.4). header (see Section 10.4).
Responses to this method are not cacheable, unless the response Responses to this method are not cacheable, unless the response
includes appropriate Cache-Control or Expires header fields. includes appropriate Cache-Control or Expires header fields.
However, the 303 (See Other) response can be used to direct the user However, the 303 (See Other) response can be used to direct the user
agent to retrieve a cacheable resource. agent to retrieve a cacheable resource.
POST requests MUST obey the message transmission requirements set out
in Section 7.2 of [Part1].
See Section 12.2 for security considerations.
8.6. PUT 8.6. PUT
The PUT method requests that the enclosed entity be stored under the The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already supplied Request-URI. If the Request-URI refers to an already
existing resource, the enclosed entity SHOULD be considered as a existing resource, the enclosed entity SHOULD be considered as a
modified version of the one residing on the origin server. If the modified version of the one residing on the origin server. If the
Request-URI does not point to an existing resource, and that URI is Request-URI does not point to an existing resource, and that URI is
capable of being defined as a new resource by the requesting user capable of being defined as a new resource by the requesting user
agent, the origin server can create the resource with that URI. If a agent, the origin server can create the resource with that URI. If a
new resource is created, the origin server MUST inform the user agent new resource is created, the origin server MUST inform the user agent
skipping to change at page 15, line 11 skipping to change at page 15, line 51
A single resource MAY be identified by many different URIs. For A single resource MAY be identified by many different URIs. For
example, an article might have a URI for identifying "the current example, an article might have a URI for identifying "the current
version" which is separate from the URI identifying each particular version" which is separate from the URI identifying each particular
version. In this case, a PUT request on a general URI might result version. In this case, a PUT request on a general URI might result
in several other URIs being defined by the origin server. in several other URIs being defined by the origin server.
HTTP/1.1 does not define how a PUT method affects the state of an HTTP/1.1 does not define how a PUT method affects the state of an
origin server. origin server.
PUT requests MUST obey the message transmission requirements set out
in Section 7.2 of [Part1].
Unless otherwise specified for a particular entity-header, the Unless otherwise specified for a particular entity-header, the
entity-headers in the PUT request SHOULD be applied to the resource entity-headers in the PUT request SHOULD be applied to the resource
created or modified by the PUT. created or modified by the PUT.
8.7. DELETE 8.7. DELETE
The DELETE method requests that the origin server delete the resource The DELETE method requests that the origin server delete the resource
identified by the Request-URI. This method MAY be overridden by identified by the Request-URI. This method MAY be overridden by
human intervention (or other means) on the origin server. The client human intervention (or other means) on the origin server. The client
cannot be guaranteed that the operation has been carried out, even if cannot be guaranteed that the operation has been carried out, even if
skipping to change at page 20, line 31 skipping to change at page 21, line 24
URIs. Clients with link editing capabilities ought to automatically URIs. Clients with link editing capabilities ought to automatically
re-link references to the Request-URI to one or more of the new re-link references to the Request-URI to one or more of the new
references returned by the server, where possible. This response is references returned by the server, where possible. This response is
cacheable unless indicated otherwise. cacheable unless indicated otherwise.
The new permanent URI SHOULD be given by the Location field in the The new permanent URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s). the new URI(s).
If the 301 status code is received in response to a request other If the 301 status code is received in response to a request method
than GET or HEAD, the user agent MUST NOT automatically redirect the that is known to be "safe", as defined in Section 8.1.1, then the
request unless it can be confirmed by the user, since this might request MAY be automatically redirected by the user agent without
change the conditions under which the request was issued. confirmation. Otherwise, the user agent MUST NOT automatically
redirect the request unless it can be confirmed by the user, since
this might change the conditions under which the request was issued.
Note: When automatically redirecting a POST request after Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing HTTP/1.0 user agents receiving a 301 status code, some existing HTTP/1.0 user agents
will erroneously change it into a GET request. will erroneously change it into a GET request.
9.3.3. 302 Found 9.3.3. 302 Found
The requested resource resides temporarily under a different URI. The requested resource resides temporarily under a different URI.
Since the redirection might be altered on occasion, the client SHOULD Since the redirection might be altered on occasion, the client SHOULD
continue to use the Request-URI for future requests. This response continue to use the Request-URI for future requests. This response
is only cacheable if indicated by a Cache-Control or Expires header is only cacheable if indicated by a Cache-Control or Expires header
field. field.
The temporary URI SHOULD be given by the Location field in the The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s). the new URI(s).
If the 302 status code is received in response to a request other If the 302 status code is received in response to a request method
than GET or HEAD, the user agent MUST NOT automatically redirect the that is known to be "safe", as defined in Section 8.1.1, then the
request unless it can be confirmed by the user, since this might request MAY be automatically redirected by the user agent without
change the conditions under which the request was issued. confirmation. Otherwise, the user agent MUST NOT automatically
redirect the request unless it can be confirmed by the user, since
this might change the conditions under which the request was issued.
Note: RFC 1945 and RFC 2068 specify that the client is not allowed Note: [RFC1945] and [RFC2068] specify that the client is not
to change the method on the redirected request. However, most allowed to change the method on the redirected request. However,
existing user agent implementations treat 302 as if it were a 303 most existing user agent implementations treat 302 as if it were a
response, performing a GET on the Location field-value regardless 303 response, performing a GET on the Location field-value
of the original request method. The status codes 303 and 307 have regardless of the original request method. The status codes 303
been added for servers that wish to make unambiguously clear which and 307 have been added for servers that wish to make
kind of reaction is expected of the client. unambiguously clear which kind of reaction is expected of the
client.
9.3.4. 303 See Other 9.3.4. 303 See Other
The response to the request can be found under a different URI and The response to the request can be found under a different URI and
SHOULD be retrieved using a GET method on that resource. This method SHOULD be retrieved using a GET method on that resource. This method
exists primarily to allow the output of a POST-activated script to exists primarily to allow the output of a POST-activated script to
redirect the user agent to a selected resource. The new URI is not a redirect the user agent to a selected resource. The new URI is not a
substitute reference for the originally requested resource. The 303 substitute reference for the originally requested resource. The 303
response MUST NOT be cached, but the response to the second response MUST NOT be cached, but the response to the second
(redirected) request might be cacheable. (redirected) request might be cacheable.
skipping to change at page 21, line 51 skipping to change at page 22, line 48
conditions indicated by the client's conditional GET request, as conditions indicated by the client's conditional GET request, as
defined in [Part4]. defined in [Part4].
9.3.6. 305 Use Proxy 9.3.6. 305 Use Proxy
The requested resource MUST be accessed through the proxy given by The requested resource MUST be accessed through the proxy given by
the Location field. The Location field gives the URI of the proxy. the Location field. The Location field gives the URI of the proxy.
The recipient is expected to repeat this single request via the The recipient is expected to repeat this single request via the
proxy. 305 responses MUST only be generated by origin servers. proxy. 305 responses MUST only be generated by origin servers.
Note: RFC 2068 was not clear that 305 was intended to redirect a Note: [RFC2068] was not clear that 305 was intended to redirect a
single request, and to be generated by origin servers only. Not single request, and to be generated by origin servers only. Not
observing these limitations has significant security consequences. observing these limitations has significant security consequences.
9.3.7. 306 (Unused) 9.3.7. 306 (Unused)
The 306 status code was used in a previous version of the The 306 status code was used in a previous version of the
specification, is no longer used, and the code is reserved. specification, is no longer used, and the code is reserved.
9.3.8. 307 Temporary Redirect 9.3.8. 307 Temporary Redirect
skipping to change at page 22, line 27 skipping to change at page 23, line 26
field. field.
The temporary URI SHOULD be given by the Location field in the The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD, the entity of the response. Unless the request method was HEAD, the entity of the
response SHOULD contain a short hypertext note with a hyperlink to response SHOULD contain a short hypertext note with a hyperlink to
the new URI(s) , since many pre-HTTP/1.1 user agents do not the new URI(s) , since many pre-HTTP/1.1 user agents do not
understand the 307 status. Therefore, the note SHOULD contain the understand the 307 status. Therefore, the note SHOULD contain the
information necessary for a user to repeat the original request on information necessary for a user to repeat the original request on
the new URI. the new URI.
If the 307 status code is received in response to a request other If the 307 status code is received in response to a request method
than GET or HEAD, the user agent MUST NOT automatically redirect the that is known to be "safe", as defined in Section 8.1.1, then the
request unless it can be confirmed by the user, since this might request MAY be automatically redirected by the user agent without
change the conditions under which the request was issued. confirmation. Otherwise, the user agent MUST NOT automatically
redirect the request unless it can be confirmed by the user, since
this might change the conditions under which the request was issued.
9.4. Client Error 4xx 9.4. Client Error 4xx
The 4xx class of status code is intended for cases in which the The 4xx class of status code is intended for cases in which the
client seems to have erred. Except when responding to a HEAD client seems to have erred. Except when responding to a HEAD
request, the server SHOULD include an entity containing an request, the server SHOULD include an entity containing an
explanation of the error situation, and whether it is a temporary or explanation of the error situation, and whether it is a temporary or
permanent condition. These status codes are applicable to any permanent condition. These status codes are applicable to any
request method. User agents SHOULD display any included entity to request method. User agents SHOULD display any included entity to
the user. the user.
skipping to change at page 28, line 7 skipping to change at page 29, line 7
The server does not support, or refuses to support, the HTTP protocol The server does not support, or refuses to support, the HTTP protocol
version that was used in the request message. The server is version that was used in the request message. The server is
indicating that it is unable or unwilling to complete the request indicating that it is unable or unwilling to complete the request
using the same major version as the client, as described in Section using the same major version as the client, as described in Section
3.1 of [Part1], other than with this error message. The response 3.1 of [Part1], other than with this error message. The response
SHOULD contain an entity describing why that version is not supported SHOULD contain an entity describing why that version is not supported
and what other protocols are supported by that server. and what other protocols are supported by that server.
10. Header Field Definitions 10. Header Field Definitions
This section defines the syntax and semantics of all standard This section defines the syntax and semantics of HTTP/1.1 header
HTTP/1.1 header fields. For entity-header fields, both sender and fields related to request and response semantics.
recipient refer to either the client or the server, depending on who
sends and who receives the entity. For entity-header fields, both sender and recipient refer to either
the client or the server, depending on who sends and who receives the
entity.
10.1. Allow 10.1. Allow
The Allow entity-header field lists the set of methods supported by The Allow entity-header field lists the set of methods supported by
the resource identified by the Request-URI. The purpose of this the resource identified by the Request-URI. The purpose of this
field is strictly to inform the recipient of valid methods associated field is strictly to inform the recipient of valid methods associated
with the resource. An Allow header field MUST be present in a 405 with the resource. An Allow header field MUST be present in a 405
(Method Not Allowed) response. (Method Not Allowed) response.
Allow = "Allow" ":" #Method Allow = "Allow" ":" #Method
skipping to change at page 29, line 29 skipping to change at page 30, line 31
The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST The Expect mechanism is hop-by-hop: that is, an HTTP/1.1 proxy MUST
return a 417 (Expectation Failed) status if it receives a request return a 417 (Expectation Failed) status if it receives a request
with an expectation that it cannot meet. However, the Expect with an expectation that it cannot meet. However, the Expect
request-header itself is end-to-end; it MUST be forwarded if the request-header itself is end-to-end; it MUST be forwarded if the
request is forwarded. request is forwarded.
Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Many older HTTP/1.0 and HTTP/1.1 applications do not understand the
Expect header. Expect header.
See Section 7.2.3 of [Part1] for the use of the 100 (continue) See Section 7.2.3 of [Part1] for the use of the 100 (Continue)
status. status.
10.3. From 10.3. From
The From request-header field, if given, SHOULD contain an Internet The From request-header field, if given, SHOULD contain an Internet
e-mail address for the human user who controls the requesting user e-mail address for the human user who controls the requesting user
agent. The address SHOULD be machine-usable, as defined by "mailbox" agent. The address SHOULD be machine-usable, as defined by "mailbox"
in RFC 822 [RFC822] as updated by RFC 1123 [RFC1123]: in Section 3.4 of [RFC2822]:
From = "From" ":" mailbox From = "From" ":" mailbox
An example is: An example is:
From: webmaster@w3.org From: webmaster@example.org
This header field MAY be used for logging purposes and as a means for This header field MAY be used for logging purposes and as a means for
identifying the source of invalid or unwanted requests. It SHOULD identifying the source of invalid or unwanted requests. It SHOULD
NOT be used as an insecure form of access protection. The NOT be used as an insecure form of access protection. The
interpretation of this field is that the request is being performed interpretation of this field is that the request is being performed
on behalf of the person given, who accepts responsibility for the on behalf of the person given, who accepts responsibility for the
method performed. In particular, robot agents SHOULD include this method performed. In particular, robot agents SHOULD include this
header so that the person responsible for running the robot can be header so that the person responsible for running the robot can be
contacted if problems occur on the receiving end. contacted if problems occur on the receiving end.
skipping to change at page 30, line 27 skipping to change at page 31, line 29
10.4. Location 10.4. Location
The Location response-header field is used to redirect the recipient The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the to a location other than the Request-URI for completion of the
request or identification of a new resource. For 201 (Created) request or identification of a new resource. For 201 (Created)
responses, the Location is that of the new resource which was created responses, the Location is that of the new resource which was created
by the request. For 3xx responses, the location SHOULD indicate the by the request. For 3xx responses, the location SHOULD indicate the
server's preferred URI for automatic redirection to the resource. server's preferred URI for automatic redirection to the resource.
The field value consists of a single absolute URI. The field value consists of a single absolute URI.
Location = "Location" ":" absoluteURI Location = "Location" ":" absoluteURI [ "#" fragment ]
An example is: An example is:
Location: http://www.w3.org/pub/WWW/People.html Location: http://www.example.org/pub/WWW/People.html
Note: The Content-Location header field (Section 5.7 of [Part3]) Note: The Content-Location header field (Section 5.7 of [Part3])
differs from Location in that the Content-Location identifies the differs from Location in that the Content-Location identifies the
original location of the entity enclosed in the request. It is original location of the entity enclosed in the request. It is
therefore possible for a response to contain header fields for therefore possible for a response to contain header fields for
both Location and Content-Location. both Location and Content-Location.
There are circumstances in which a fragment identifier in a Location
URL would not be appropriate:
o With a 201 Created response, because in this usage the Location
header specifies the URL for the entire created resource.
o With a 300 Multiple Choices, since the choice decision is intended
to be made on resource characteristics and not fragment
characteristics.
o With 305 Use Proxy.
10.5. Max-Forwards 10.5. Max-Forwards
The Max-Forwards request-header field provides a mechanism with the The Max-Forwards request-header field provides a mechanism with the
TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the TRACE (Section 8.8) and OPTIONS (Section 8.2) methods to limit the
number of proxies or gateways that can forward the request to the number of proxies or gateways that can forward the request to the
next inbound server. This can be useful when the client is next inbound server. This can be useful when the client is
attempting to trace a request chain which appears to be failing or attempting to trace a request chain which appears to be failing or
looping in mid-chain. looping in mid-chain.
Max-Forwards = "Max-Forwards" ":" 1*DIGIT Max-Forwards = "Max-Forwards" ":" 1*DIGIT
skipping to change at page 31, line 33 skipping to change at page 32, line 49
server to generate lists of back-links to resources for interest, server to generate lists of back-links to resources for interest,
logging, optimized caching, etc. It also allows obsolete or mistyped logging, optimized caching, etc. It also allows obsolete or mistyped
links to be traced for maintenance. The Referer field MUST NOT be links to be traced for maintenance. The Referer field MUST NOT be
sent if the Request-URI was obtained from a source that does not have sent if the Request-URI was obtained from a source that does not have
its own URI, such as input from the user keyboard. its own URI, such as input from the user keyboard.
Referer = "Referer" ":" ( absoluteURI | relativeURI ) Referer = "Referer" ":" ( absoluteURI | relativeURI )
Example: Example:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html Referer: http://www.example.org/hypertext/Overview.html
If the field value is a relative URI, it SHOULD be interpreted If the field value is a relative URI, it SHOULD be interpreted
relative to the Request-URI. The URI MUST NOT include a fragment. relative to the Request-URI. The URI MUST NOT include a fragment.
See Section 12.2 for security considerations. See Section 12.2 for security considerations.
10.7. Retry-After 10.7. Retry-After
The Retry-After response-header field can be used with a 503 (Service The Retry-After response-header field can be used with a 503 (Service
Unavailable) response to indicate how long the service is expected to Unavailable) response to indicate how long the service is expected to
be unavailable to the requesting client. This field MAY also be used be unavailable to the requesting client. This field MAY also be used
with any 3xx (Redirection) response to indicate the minimum time the with any 3xx (Redirection) response to indicate the minimum time the
user-agent is asked wait before issuing the redirected request. The user-agent is asked wait before issuing the redirected request. The
value of this field can be either an HTTP-date or an integer number value of this field can be either an HTTP-date or an integer number
skipping to change at page 32, line 26 skipping to change at page 33, line 43
application. application.
Server = "Server" ":" 1*( product | comment ) Server = "Server" ":" 1*( product | comment )
Example: Example:
Server: CERN/3.0 libwww/2.17 Server: CERN/3.0 libwww/2.17
If the response is being forwarded through a proxy, the proxy If the response is being forwarded through a proxy, the proxy
application MUST NOT modify the Server response-header. Instead, it application MUST NOT modify the Server response-header. Instead, it
SHOULD include a Via field (as described in Section 8.9 of [Part1]). MUST include a Via field (as described in Section 8.9 of [Part1]).
Note: Revealing the specific software version of the server might Note: Revealing the specific software version of the server might
allow the server machine to become more vulnerable to attacks allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server against software that is known to contain security holes. Server
implementors are encouraged to make this field a configurable implementors are encouraged to make this field a configurable
option. option.
10.9. User-Agent 10.9. User-Agent
The User-Agent request-header field contains information about the The User-Agent request-header field contains information about the
skipping to change at page 34, line 46 skipping to change at page 36, line 17
12.3. Location Headers and Spoofing 12.3. Location Headers and Spoofing
If a single server supports multiple organizations that do not trust If a single server supports multiple organizations that do not trust
one another, then it MUST check the values of Location and Content- one another, then it MUST check the values of Location and Content-
Location headers in responses that are generated under control of Location headers in responses that are generated under control of
said organizations to make sure that they do not attempt to said organizations to make sure that they do not attempt to
invalidate resources over which they have no authority. invalidate resources over which they have no authority.
13. Acknowledgments 13. Acknowledgments
Based on an XML translation of RFC 2616 by Julian Reschke.
14. References 14. References
[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web 14.1. Normative References
proxy servers", Work in Progress.
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 1: URIs, Connections, and Message Parsing", and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
draft-ietf-httpbis-p1-messaging-00 (work in progress), and Message Parsing", draft-ietf-httpbis-p1-messaging-01
December 2007. (work in progress), January 2008.
[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 3: Message Payload and Content Negotiation", and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
draft-ietf-httpbis-p3-payload-00 (work in progress), and Content Negotiation", draft-ietf-httpbis-p3-payload-01
December 2007. (work in progress), January 2008.
[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 4: Conditional Requests", and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
draft-ietf-httpbis-p4-conditional-00 (work in progress), Requests", draft-ietf-httpbis-p4-conditional-01 (work in
December 2007. progress), January 2008.
[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 5: Range Requests and Partial Responses", and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
draft-ietf-httpbis-p5-range-00 (work in progress), Partial Responses", draft-ietf-httpbis-p5-range-01 (work
December 2007. in progress), January 2008.
[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 6: Caching", draft-ietf-httpbis-p6-cache-00 (work in and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
progress), December 2007. draft-ietf-httpbis-p6-cache-01 (work in progress),
January 2008.
[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "HTTP/1.1, Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
part 7: Authentication", draft-ietf-httpbis-p7-auth-00 and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
(work in progress), December 2007. draft-ietf-httpbis-p7-auth-01 (work in progress),
January 2008.
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
and Support", STD 3, RFC 1123, October 1989. Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References
[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web
proxy servers", draft-luotonen-web-proxy-tunneling-01
(work in progress), August 1998.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC822] Crocker, D., "Standard for the format of ARPA Internet [RFC2822] Resnick, P., "Internet Message Format", RFC 2822,
text messages", STD 11, RFC 822, August 1982. April 2001.
Appendix A. Changes from RFC 2068 Appendix A. Compatibility with Previous Versions
A.1. Changes from RFC 2068
Clarified which error code should be used for inbound server failures Clarified which error code should be used for inbound server failures
(e.g. DNS failures). (Section 9.5.5). (e.g. DNS failures). (Section 9.5.5).
CREATE had a race that required an Etag be sent when a resource is 201 (Created) had a race that required an Etag be sent when a
first created. (Section 9.2.2). resource is first created. (Section 9.2.2).
Rewrite of message transmission requirements to make it much harder Rewrite of message transmission requirements to make it much harder
for implementors to get it wrong, as the consequences of errors here for implementors to get it wrong, as the consequences of errors here
can have significant impact on the Internet, and to deal with the can have significant impact on the Internet, and to deal with the
following problems: following problems:
1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where 1. Changing "HTTP/1.1 or later" to "HTTP/1.1", in contexts where
this was incorrectly placing a requirement on the behavior of an this was incorrectly placing a requirement on the behavior of an
implementation of a future version of HTTP/1.x implementation of a future version of HTTP/1.x
2. Made it clear that user-agents should retry requests, not 2. Made it clear that user-agents should retry requests, not
"clients" in general. "clients" in general.
3. Converted requirements for clients to ignore unexpected 100 3. Converted requirements for clients to ignore unexpected 100
(Continue) responses, and for proxies to forward 100 responses, (Continue) responses, and for proxies to forward 100 responses,
into a general requirement for 1xx responses. into a general requirement for 1xx responses.
4. Modified some TCP-specific language, to make it clearer that non- 4. Modified some TCP-specific language, to make it clearer that non-
TCP transports are possible for HTTP. TCP transports are possible for HTTP.
skipping to change at page 36, line 48 skipping to change at page 38, line 29
7. Allow servers to defend against denial-of-service attacks and 7. Allow servers to defend against denial-of-service attacks and
broken clients. broken clients.
This change adds the Expect header and 417 status code. This change adds the Expect header and 417 status code.
Clean up confusion between 403 and 404 responses. (Section 9.4.4, Clean up confusion between 403 and 404 responses. (Section 9.4.4,
9.4.5, and 9.4.11) 9.4.5, and 9.4.11)
The PATCH, LINK, UNLINK methods were defined but not commonly The PATCH, LINK, UNLINK methods were defined but not commonly
implemented in previous versions of this specification. See RFC 2068 implemented in previous versions of this specification. See
[RFC2068]. [RFC2068].
A.2. Changes from RFC 2616
Clarify definition of POST. (Section 8.5)
Failed to consider that there are many other request methods that are
safe to automatically redirect, and further that the user agent is
able to make that determination based on the request method
semantics. (Sections 9.3.2, 9.3.3 and 9.3.8 )
Correct syntax of Location header to allow fragment, as referred
symbol wasn't what was expected, and add some clarifications as to
when it would not be appropriate. (Section 10.4)
In the description of the Server header, the Via field was described
as a SHOULD. The requirement was and is stated correctly in the
description of the Via header in Section 8.9 of [Part1].
(Section 10.8)
Appendix B. Change Log (to be removed by RFC Editor before publication)
B.1. Since RFC2616
Extracted relevant partitions from [RFC2616].
B.2. Since draft-ietf-httpbis-p2-semantics-00
Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/5>: "Via is a
MUST" (<http://purl.org/NET/http-errata#via-must>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/6>: "Fragments
allowed in Location"
(<http://purl.org/NET/http-errata#location-fragments>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/10>: "Safe
Methods vs Redirection"
(<http://purl.org/NET/http-errata#saferedirect>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/17>: "Revise
description of the POST method"
(<http://purl.org/NET/http-errata#post>)
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative
and Informative references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/42>: "RFC2606
Compliance"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:
"Informative references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
cross-references"
Other changes:
o Move definitions of 304 and 412 condition codes to [Part4]
Index Index
1 1
100 Continue (status code) 16 100 Continue (status code) 17
101 Switching Protocols (status code) 17 101 Switching Protocols (status code) 18
2 2
200 OK (status code) 17 200 OK (status code) 18
201 Created (status code) 17 201 Created (status code) 18
202 Accepted (status code) 18 202 Accepted (status code) 19
203 Non-Authoritative Information (status code) 18 203 Non-Authoritative Information (status code) 19
204 No Content (status code) 18 204 No Content (status code) 19
205 Reset Content (status code) 19 205 Reset Content (status code) 20
206 Partial Content (status code) 19 206 Partial Content (status code) 20
3 3
300 Multiple Choices (status code) 19 300 Multiple Choices (status code) 20
301 Moved Permanently (status code) 20 301 Moved Permanently (status code) 21
302 Found (status code) 20 302 Found (status code) 21
303 See Other (status code) 21 303 See Other (status code) 22
304 Not Modified (status code) 21 304 Not Modified (status code) 22
305 Use Proxy (status code) 21 305 Use Proxy (status code) 22
306 (Unused) (status code) 22 306 (Unused) (status code) 23
307 Temporary Redirect (status code) 22 307 Temporary Redirect (status code) 23
4 4
400 Bad Request (status code) 23 400 Bad Request (status code) 24
401 Unauthorized (status code) 23 401 Unauthorized (status code) 24
402 Payment Required (status code) 23 402 Payment Required (status code) 24
403 Forbidden (status code) 23 403 Forbidden (status code) 24
404 Not Found (status code) 23 404 Not Found (status code) 24
405 Method Not Allowed (status code) 23 405 Method Not Allowed (status code) 24
406 Not Acceptable (status code) 23 406 Not Acceptable (status code) 24
407 Proxy Authentication Required (status code) 24 407 Proxy Authentication Required (status code) 25
408 Request Timeout (status code) 24 408 Request Timeout (status code) 25
409 Conflict (status code) 24 409 Conflict (status code) 25
410 Gone (status code) 25 410 Gone (status code) 26
411 Length Required (status code) 25 411 Length Required (status code) 26
412 Precondition Failed (status code) 25 412 Precondition Failed (status code) 26
413 Request Entity Too Large (status code) 25 413 Request Entity Too Large (status code) 26
414 Request-URI Too Long (status code) 26 414 Request-URI Too Long (status code) 27
415 Unsupported Media Type (status code) 26 415 Unsupported Media Type (status code) 27
416 Requested Range Not Satisfiable (status code) 26 416 Requested Range Not Satisfiable (status code) 27
417 Expectation Failed (status code) 26 417 Expectation Failed (status code) 27
5 5
500 Internal Server Error (status code) 26 500 Internal Server Error (status code) 27
501 Not Implemented (status code) 27 501 Not Implemented (status code) 28
502 Bad Gateway (status code) 27 502 Bad Gateway (status code) 28
503 Service Unavailable (status code) 27 503 Service Unavailable (status code) 28
504 Gateway Timeout (status code) 27 504 Gateway Timeout (status code) 28
505 HTTP Version Not Supported (status code) 27 505 HTTP Version Not Supported (status code) 28
A A
Allow header 28 Allow header 29
C C
CONNECT method 16 CONNECT method 17
D D
DELETE method 15 DELETE method 16
E E
Expect header 28 Expect header 29
F F
From header 29 From header 30
G G
GET method 12 GET method 13
Grammar Grammar
Allow 28 Allow 29
Expect 28 Expect 29
expect-params 28 expect-params 29
expectation 28 expectation 29
expectation-extension 28 expectation-extension 29
extension-code 8 extension-code 9
extension-method 6 extension-method 7
From 29 From 30
Location 30 Location 31
Max-Forwards 30 Max-Forwards 32
Method 6 Method 7
product 5 product 6
product-version 5 product-version 6
Reason-Phrase 8 Reason-Phrase 9
Referer 31 Referer 32
request-header 7 request-header 8
response-header 9 response-header 10
Retry-After 31 Retry-After 33
Server 32 Server 33
Status-Code 8 Status-Code 9
User-Agent 32 User-Agent 34
H H
HEAD method 12 HEAD method 13
Headers Headers
Allow 28 Allow 29
Expect 28 Expect 29
From 29 From 30
Location 30 Location 31
Max-Forwards 30 Max-Forwards 32
Referer 31 Referer 32
Retry-After 31 Retry-After 33
Server 32 Server 33
User-Agent 32 User-Agent 34
L L
LINK method 36 LINK method 38
Location header 30 Location header 31
M M
Max-Forwards header 30 Max-Forwards header 32
Methods Methods
CONNECT 16 CONNECT 17
DELETE 15 DELETE 16
GET 12 GET 13
HEAD 12 HEAD 13
LINK 36 LINK 38
OPTIONS 11 OPTIONS 12
PATCH 36 PATCH 38
POST 13 POST 14
PUT 14 PUT 15
TRACE 15 TRACE 16
UNLINK 36 UNLINK 38
O O
OPTIONS method 11 OPTIONS method 12
P P
PATCH method 36 PATCH method 38
POST method 13 POST method 14
PUT method 14 PUT method 15
R R
Referer header 31 Referer header 32
Retry-After header 31 Retry-After header 33
S S
Server header 32 Server header 33
Status Codes Status Codes
100 Continue 16 100 Continue 17
101 Switching Protocols 17 101 Switching Protocols 18
200 OK 17 200 OK 18
201 Created 17 201 Created 18
202 Accepted 18 202 Accepted 19
203 Non-Authoritative Information 18 203 Non-Authoritative Information 19
204 No Content 18 204 No Content 19
205 Reset Content 19 205 Reset Content 20
206 Partial Content 19 206 Partial Content 20
300 Multiple Choices 19 300 Multiple Choices 20
301 Moved Permanently 20 301 Moved Permanently 21
302 Found 20 302 Found 21
303 See Other 21 303 See Other 22
304 Not Modified 21 304 Not Modified 22
305 Use Proxy 21 305 Use Proxy 22
306 (Unused) 22 306 (Unused) 23
307 Temporary Redirect 22 307 Temporary Redirect 23
400 Bad Request 23 400 Bad Request 24
401 Unauthorized 23 401 Unauthorized 24
402 Payment Required 23 402 Payment Required 24
403 Forbidden 23 403 Forbidden 24
404 Not Found 23 404 Not Found 24
405 Method Not Allowed 23 405 Method Not Allowed 24
406 Not Acceptable 23 406 Not Acceptable 24
407 Proxy Authentication Required 24 407 Proxy Authentication Required 25
408 Request Timeout 24 408 Request Timeout 25
409 Conflict 24 409 Conflict 25
410 Gone 25 410 Gone 26
411 Length Required 25 411 Length Required 26
412 Precondition Failed 25 412 Precondition Failed 26
413 Request Entity Too Large 25 413 Request Entity Too Large 26
414 Request-URI Too Long 26 414 Request-URI Too Long 27
415 Unsupported Media Type 26 415 Unsupported Media Type 27
416 Requested Range Not Satisfiable 26 416 Requested Range Not Satisfiable 27
417 Expectation Failed 26 417 Expectation Failed 27
500 Internal Server Error 26 500 Internal Server Error 27
501 Not Implemented 27 501 Not Implemented 28
502 Bad Gateway 27 502 Bad Gateway 28
503 Service Unavailable 27 503 Service Unavailable 28
504 Gateway Timeout 27 504 Gateway Timeout 28
505 HTTP Version Not Supported 27 505 HTTP Version Not Supported 28
T T
TRACE method 15 TRACE method 16
U U
UNLINK method 36 UNLINK method 38
User-Agent header 32 User-Agent header 34
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Day Software Day Software
23 Corporate Plaza DR, Suite 280 23 Corporate Plaza DR, Suite 280
Newport Beach, CA 92660 Newport Beach, CA 92660
USA USA
Phone: +1-949-706-5300 Phone: +1-949-706-5300
skipping to change at page 43, line 5 skipping to change at page 45, line 31
World Wide Web Consortium World Wide Web Consortium
MIT Computer Science and Artificial Intelligence Laboratory MIT Computer Science and Artificial Intelligence Laboratory
The Stata Center, Building 32 The Stata Center, Building 32
32 Vassar Street 32 Vassar Street
Cambridge, MA 02139 Cambridge, MA 02139
USA USA
Email: timbl@w3.org Email: timbl@w3.org
URI: http://www.w3.org/People/Berners-Lee/ URI: http://www.w3.org/People/Berners-Lee/
Yves Lafon (editor)
World Wide Web Consortium
W3C / ERCIM
2004, rte des Lucioles
Sophia-Antipolis, AM 06902
France
Email: ylafon@w3.org
URI: http://www.raubacapeu.net/people/yves/
Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
Phone: +49 251 2807760
Fax: +49 251 2807761
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 74 change blocks. 
357 lines changed or deleted 481 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/