draft-ietf-httpbis-p2-semantics-01.txt   draft-ietf-httpbis-p2-semantics-02.txt 
Network Working Group R. Fielding, Ed. Network Working Group R. Fielding, Ed.
Internet-Draft Day Software Internet-Draft Day Software
Obsoletes: 2616 (if approved) J. Gettys Obsoletes: 2616 (if approved) J. Gettys
Intended status: Standards Track One Laptop per Child Intended status: Standards Track One Laptop per Child
Expires: July 15, 2008 J. Mogul Expires: August 27, 2008 J. Mogul
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
Y. Lafon, Ed. Y. Lafon, Ed.
W3C W3C
J. Reschke, Ed. J. Reschke, Ed.
greenbytes greenbytes
January 12, 2008 February 24, 2008
HTTP/1.1, part 2: Message Semantics HTTP/1.1, part 2: Message Semantics
draft-ietf-httpbis-p2-semantics-01 draft-ietf-httpbis-p2-semantics-02
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 49 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 July 15, 2008. This Internet-Draft will expire on August 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). 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
skipping to change at page 3, line 9 skipping to change at page 3, line 9
This draft incorporates those issue resolutions that were either This draft incorporates those issue resolutions that were either
collected in the original RFC2616 errata list collected in the original RFC2616 errata list
(<http://purl.org/NET/http-errata>), or which were agreed upon on the (<http://purl.org/NET/http-errata>), or which were agreed upon on the
mailing list between October 2006 and November 2007 (as published in mailing list between October 2006 and November 2007 (as published in
"draft-lafon-rfc2616bis-03"). "draft-lafon-rfc2616bis-03").
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
2. Product Tokens . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Notational Conventions and Generic Grammar . . . . . . . . . . 6
3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 7 4. Request Header Fields . . . . . . . . . . . . . . . . . . . . 8
5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 8 5. Status Code and Reason Phrase . . . . . . . . . . . . . . . . 9
6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 10 6. Response Header Fields . . . . . . . . . . . . . . . . . . . . 11
7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Entity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 11 8. Method Definitions . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 11 8.1. Safe and Idempotent Methods . . . . . . . . . . . . . . . 12
8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 11 8.1.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 12
8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 11 8.1.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 12
8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3. GET . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.4. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.5. POST . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.6. PUT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.7. DELETE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.9. CONNECT . . . . . . . . . . . . . . . . . . . . . . . . . 18
9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 17 9. Status Code Definitions . . . . . . . . . . . . . . . . . . . 18
9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 17 9.1. Informational 1xx . . . . . . . . . . . . . . . . . . . . 18
9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 17 9.1.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 18
9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 18 9.1.2. 101 Switching Protocols . . . . . . . . . . . . . . . 19
9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 19
9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 19
9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 18 9.2.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 19
9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 19 9.2.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 20
9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 19 9.2.4. 203 Non-Authoritative Information . . . . . . . . . . 20
9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 19 9.2.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 20
9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 20 9.2.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 21
9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 20 9.2.7. 206 Partial Content . . . . . . . . . . . . . . . . . 21
9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 20 9.3. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 21
9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 20 9.3.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 21
9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 21 9.3.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 22
9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 21 9.3.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 22
9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 22 9.3.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 23
9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 22 9.3.5. 304 Not Modified . . . . . . . . . . . . . . . . . . . 23
9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 22 9.3.6. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 23
9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 23 9.3.7. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 24
9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 23 9.3.8. 307 Temporary Redirect . . . . . . . . . . . . . . . . 24
9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 23 9.4. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 24
9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 24 9.4.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 25
9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 24 9.4.2. 401 Unauthorized . . . . . . . . . . . . . . . . . . . 25
9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 24 9.4.3. 402 Payment Required . . . . . . . . . . . . . . . . . 25
9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 24 9.4.4. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 25
9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 24 9.4.5. 404 Not Found . . . . . . . . . . . . . . . . . . . . 25
9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 24 9.4.6. 405 Method Not Allowed . . . . . . . . . . . . . . . . 25
9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 24 9.4.7. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 25
9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 25 9.4.8. 407 Proxy Authentication Required . . . . . . . . . . 26
9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 25 9.4.9. 408 Request Timeout . . . . . . . . . . . . . . . . . 26
9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 25 9.4.10. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 26
9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 26 9.4.11. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 27
9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 26 9.4.12. 411 Length Required . . . . . . . . . . . . . . . . . 27
9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 26 9.4.13. 412 Precondition Failed . . . . . . . . . . . . . . . 27
9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 26 9.4.14. 413 Request Entity Too Large . . . . . . . . . . . . . 27
9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 27 9.4.15. 414 Request-URI Too Long . . . . . . . . . . . . . . . 28
9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 27 9.4.16. 415 Unsupported Media Type . . . . . . . . . . . . . . 28
9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 27 9.4.17. 416 Requested Range Not Satisfiable . . . . . . . . . 28
9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 27 9.4.18. 417 Expectation Failed . . . . . . . . . . . . . . . . 28
9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 27 9.5. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 28
9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 27 9.5.1. 500 Internal Server Error . . . . . . . . . . . . . . 28
9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 28 9.5.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 29
9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 28 9.5.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 29
9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 28 9.5.4. 503 Service Unavailable . . . . . . . . . . . . . . . 29
9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 28 9.5.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 29
9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 28 9.5.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 29
10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 29 10. Header Field Definitions . . . . . . . . . . . . . . . . . . . 30
10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.2. Expect . . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.3. From . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.4. Location . . . . . . . . . . . . . . . . . . . . . . . . . 32
10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 32 10.5. Max-Forwards . . . . . . . . . . . . . . . . . . . . . . . 33
10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 32 10.6. Referer . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 33 10.7. Retry-After . . . . . . . . . . . . . . . . . . . . . . . 34
10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.8. Server . . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 34 10.9. User-Agent . . . . . . . . . . . . . . . . . . . . . . . . 35
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
12. Security Considerations . . . . . . . . . . . . . . . . . . . 34 12. Security Considerations . . . . . . . . . . . . . . . . . . . 35
12.1. Transfer of Sensitive Information . . . . . . . . . . . . 34 12.1. Transfer of Sensitive Information . . . . . . . . . . . . 35
12.2. Encoding Sensitive Information in URI's . . . . . . . . . 35 12.2. Encoding Sensitive Information in URIs . . . . . . . . . . 36
12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 36 12.3. Location Headers and Spoofing . . . . . . . . . . . . . . 37
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
14.1. Normative References . . . . . . . . . . . . . . . . . . . 36 14.1. Normative References . . . . . . . . . . . . . . . . . . . 37
14.2. Informative References . . . . . . . . . . . . . . . . . . 37 14.2. Informative References . . . . . . . . . . . . . . . . . . 38
Appendix A. Compatibility with Previous Versions . . . . . . . . 37 Appendix A. Compatibility with Previous Versions . . . . . . . . 38
A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 37 A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 38
A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 38 A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 39
Appendix B. Change Log (to be removed by RFC Editor before Appendix B. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 39 publication) . . . . . . . . . . . . . . . . . . . . 40
B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 39 B.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 40
B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 39 B.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 40
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 B.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 43 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Intellectual Property and Copyright Statements . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 48
1. Introduction 1. Introduction
This document defines HTTP/1.1 request and response semantics. Each This document defines HTTP/1.1 request and response semantics. Each
HTTP message, as defined in [Part1], is in the form of either a HTTP message, as defined in [Part1], is in the form of either a
request or a response. An HTTP server listens on a connection for request or a response. An HTTP server listens on a connection for
HTTP requests and responds to each request, in the order received on HTTP requests and responds to each request, in the order received on
that connection, with one or more HTTP response messages. This that connection, with one or more HTTP response messages. This
document defines the commonly agreed upon semantics of the HTTP document defines the commonly agreed upon semantics of the HTTP
uniform interface, the intentions defined by each request method, and uniform interface, the intentions defined by each request method, and
skipping to change at page 6, line 42 skipping to change at page 6, line 42
An implementation is not compliant if it fails to satisfy one or more An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocols it of the MUST or REQUIRED level requirements for the protocols it
implements. An implementation that satisfies all the MUST or implements. An implementation that satisfies all the MUST or
REQUIRED level and all the SHOULD level requirements for its REQUIRED level and all the SHOULD level requirements for its
protocols is said to be "unconditionally compliant"; one that protocols is said to be "unconditionally compliant"; one that
satisfies all the MUST level requirements but not all the SHOULD satisfies all the MUST level requirements but not all the SHOULD
level requirements for its protocols is said to be "conditionally level requirements for its protocols is said to be "conditionally
compliant." compliant."
2. Product Tokens 2. Notational Conventions and Generic Grammar
Product tokens are used to allow communicating applications to This specification uses the ABNF syntax defined in Section 2.1 of
identify themselves by software name and version. Most fields using [Part1] and the core rules defined in Section 2.2 of [Part1]:
product tokens also allow sub-products which form a significant part [[abnf.dep: ABNF syntax and basic rules will be adopted from RFC
of the application to be listed, separated by white space. By 5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]]
convention, the products are listed in order of their significance
for identifying the application.
product = token ["/" product-version] DIGIT = <DIGIT, defined in [Part1], Section 2.2>
product-version = token comment = <comment, defined in [Part1], Section 2.2>
quoted-string = <quoted-string, defined in [Part1], Section 2.2>
token = <token, defined in [Part1], Section 2.2>
Examples: The ABNF rules below are defined in other parts:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 absoluteURI = <absoluteURI, defined in [Part1], Section 3.2.1>
Server: Apache/0.8.4 fragment = <fragment, defined in [Part1], Section 3.2.1>
Host = <Host, defined in [Part1], Section 8.4>
HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>
product = <product, defined in [Part1], Section 3.5>
relativeURI = <relativeURI, defined in [Part1], Section 3.2.1>
TE = <TE, defined in [Part1], Section 8.8>
Product tokens SHOULD be short and to the point. They MUST NOT be Accept = <Accept, defined in [Part3], Section 6.1>
used for advertising or other non-essential information. Although Accept-Charset =
any token character MAY appear in a product-version, this token <Accept-Charset, defined in [Part3], Section 6.2>
SHOULD only be used for a version identifier (i.e., successive Accept-Encoding =
versions of the same product SHOULD only differ in the product- <Accept-Encoding, defined in [Part3], Section 6.3>
version portion of the product value). Accept-Language =
<Accept-Language, defined in [Part3], Section 6.4>
ETag = <ETag, defined in [Part4], Section 7.1>
If-Match = <If-Match, defined in [Part4], Section 7.2>
If-Modified-Since =
<If-Modified-Since, defined in [Part4], Section 7.3>
If-None-Match = <If-None-Match, defined in [Part4], Section 7.4>
If-Unmodified-Since =
<If-Unmodified-Since, defined in [Part4], Section 7.5>
Accept-Ranges = <Accept-Ranges, defined in [Part5], Section 6.1>
If-Range = <If-Range, defined in [Part5], Section 6.3>
Range = <Range, defined in [Part5], Section 6.4>
Age = <Age, defined in [Part6], Section 16.1>
Vary = <Vary, defined in [Part6], Section 16.5>
Authorization = <Authorization, defined in [Part7], Section 4.1>
Proxy-Authenticate =
<Proxy-Authenticate, defined in [Part7], Section 4.2>
Proxy-Authorization =
<Proxy-Authorization, defined in [Part7], Section 4.3>
WWW-Authenticate =
<WWW-Authenticate, defined in [Part7], Section 4.4>
3. Method 3. Method
The Method token indicates the method to be performed on the resource The Method token indicates the method to be performed on the resource
identified by the Request-URI. The method is case-sensitive. identified by the Request-URI. The method is case-sensitive.
Method = "OPTIONS" ; Section 8.2 Method = "OPTIONS" ; Section 8.2
| "GET" ; Section 8.3 | "GET" ; Section 8.3
| "HEAD" ; Section 8.4 | "HEAD" ; Section 8.4
| "POST" ; Section 8.5 | "POST" ; Section 8.5
skipping to change at page 8, line 9 skipping to change at page 9, line 5
those specified in Section 8. those specified in Section 8.
4. Request Header Fields 4. Request Header Fields
The request-header fields allow the client to pass additional The request-header fields allow the client to pass additional
information about the request, and about the client itself, to the information about the request, and about the client itself, to the
server. These fields act as request modifiers, with semantics server. These fields act as request modifiers, with semantics
equivalent to the parameters on a programming language method equivalent to the parameters on a programming language method
invocation. invocation.
request-header = Accept ; [Part3], Section 5.1 request-header = Accept ; [Part3], Section 6.1
| Accept-Charset ; [Part3], Section 5.2 | Accept-Charset ; [Part3], Section 6.2
| Accept-Encoding ; [Part3], Section 5.3 | Accept-Encoding ; [Part3], Section 6.3
| Accept-Language ; [Part3], Section 5.4 | Accept-Language ; [Part3], Section 6.4
| Authorization ; [Part7], Section 3.1 | Authorization ; [Part7], Section 4.1
| Expect ; Section 10.2 | Expect ; Section 10.2
| From ; Section 10.3 | From ; Section 10.3
| Host ; [Part1], Section 8.4 | Host ; [Part1], Section 8.4
| If-Match ; [Part4], Section 6.2 | If-Match ; [Part4], Section 7.2
| If-Modified-Since ; [Part4], Section 6.3 | If-Modified-Since ; [Part4], Section 7.3
| If-None-Match ; [Part4], Section 6.4 | If-None-Match ; [Part4], Section 7.4
| If-Range ; [Part5], Section 5.3 | If-Range ; [Part5], Section 6.3
| If-Unmodified-Since ; [Part4], Section 6.5 | If-Unmodified-Since ; [Part4], Section 7.5
| Max-Forwards ; Section 10.5 | Max-Forwards ; Section 10.5
| Proxy-Authorization ; [Part7], Section 3.3 | Proxy-Authorization ; [Part7], Section 4.3
| Range ; [Part5], Section 5.4 | Range ; [Part5], Section 6.4
| Referer ; Section 10.6 | Referer ; Section 10.6
| TE ; [Part1], Section 8.8 | TE ; [Part1], Section 8.8
| User-Agent ; Section 10.9 | User-Agent ; Section 10.9
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.
skipping to change at page 10, line 23 skipping to change at page 11, line 23
with the response, since that entity is likely to include human- with the response, since that entity is likely to include human-
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 6.1
| Age ; [Part6], Section 15.1 | Age ; [Part6], Section 16.1
| ETag ; [Part4], Section 6.1 | ETag ; [Part4], Section 7.1
| Location ; Section 10.4 | Location ; Section 10.4
| Proxy-Authenticate ; [Part7], Section 3.2 | Proxy-Authenticate ; [Part7], Section 4.2
| Retry-After ; Section 10.7 | Retry-After ; Section 10.7
| Server ; Section 10.8 | Server ; Section 10.8
| Vary ; [Part6], Section 15.5 | Vary ; [Part6], Section 16.5
| WWW-Authenticate ; [Part7], Section 3.4 | WWW-Authenticate ; [Part7], Section 4.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 11, line 13 skipping to change at page 12, line 13
present, as described in Section 4.3 of [Part1]. The entity-body is present, as described in Section 4.3 of [Part1]. The entity-body is
obtained from the message-body by decoding any Transfer-Encoding that obtained from the message-body by decoding any Transfer-Encoding that
might have been applied to ensure safe and proper transfer of the might have been applied to ensure safe and proper transfer of the
message. message.
8. Method Definitions 8. Method Definitions
The set of common methods for HTTP/1.1 is defined below. Although The set of common methods for HTTP/1.1 is defined below. Although
this set can be expanded, additional methods cannot be assumed to this set can be expanded, additional methods cannot be assumed to
share the same semantics for separately extended clients and servers. share the same semantics for separately extended clients and servers.
The Host request-header field (Section 8.4 of [Part1]) MUST accompany
all HTTP/1.1 requests.
8.1. Safe and Idempotent Methods 8.1. Safe and Idempotent Methods
8.1.1. Safe Methods 8.1.1. Safe Methods
Implementors should be aware that the software represents the user in Implementors should be aware that the software represents the user in
their interactions over the Internet, and should be careful to allow their interactions over the Internet, and should be careful to allow
the user to be aware of any actions they might take which may have an the user to be aware of any actions they might take which may have an
unexpected significance to themselves or others. unexpected significance to themselves or others.
skipping to change at page 13, line 37 skipping to change at page 14, line 34
If-Match, If-None-Match, or If-Range header field. A conditional GET If-Match, If-None-Match, or If-Range header field. A conditional GET
method requests that the entity be transferred only under the method requests that the entity be transferred only under the
circumstances described by the conditional header field(s). The circumstances described by the conditional header field(s). The
conditional GET method is intended to reduce unnecessary network conditional GET method is intended to reduce unnecessary network
usage by allowing cached entities to be refreshed without requiring usage by allowing cached entities to be refreshed without requiring
multiple requests or transferring data already held by the client. multiple requests or transferring data already held by the client.
The semantics of the GET method change to a "partial GET" if the The semantics of the GET method change to a "partial GET" if the
request message includes a Range header field. A partial GET request message includes a Range header field. A partial GET
requests that only part of the entity be transferred, as described in requests that only part of the entity be transferred, as described in
Section 5.4 of [Part5]. The partial GET method is intended to reduce Section 6.4 of [Part5]. The partial GET method is intended to reduce
unnecessary network usage by allowing partially-retrieved entities to unnecessary network usage by allowing partially-retrieved entities to
be completed without transferring data already held by the client. be completed without transferring data already held by the client.
The response to a GET request is cacheable if and only if it meets The response to a GET request is cacheable if and only if it meets
the requirements for HTTP caching described in [Part6]. the requirements for HTTP caching described in [Part6].
See Section 12.2 for security considerations when used for forms. See Section 12.2 for security considerations when used for forms.
8.4. HEAD 8.4. HEAD
skipping to change at page 15, line 14 skipping to change at page 16, line 14
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 at the Request-URI, the origin server MUST
via the 201 (Created) response. If an existing resource is modified, inform the user agent via the 201 (Created) response. If an existing
either the 200 (OK) or 204 (No Content) response codes SHOULD be sent resource is modified, either the 200 (OK) or 204 (No Content)
to indicate successful completion of the request. If the resource response codes SHOULD be sent to indicate successful completion of
could not be created or modified with the Request-URI, an appropriate the request. If the resource could not be created or modified with
error response SHOULD be given that reflects the nature of the the Request-URI, an appropriate error response SHOULD be given that
problem. The recipient of the entity MUST NOT ignore any Content-* reflects the nature of the problem. The recipient of the entity MUST
(e.g. Content-Range) headers that it does not understand or NOT ignore any Content-* (e.g. Content-Range) headers that it does
implement and MUST return a 501 (Not Implemented) response in such not understand or implement and MUST return a 501 (Not Implemented)
cases. response in such cases.
If the request passes through a cache and the Request-URI identifies If the request passes through a cache and the Request-URI identifies
one or more currently cached entities, those entries SHOULD be one or more currently cached entities, those entries SHOULD be
treated as stale. Responses to this method are not cacheable. treated as stale. Responses to this method are not cacheable.
The fundamental difference between the POST and PUT requests is The fundamental difference between the POST and PUT requests is
reflected in the different meaning of the Request-URI. The URI in a reflected in the different meaning of the Request-URI. The URI in a
POST request identifies the resource that will handle the enclosed POST request identifies the resource that will handle the enclosed
entity. That resource might be a data-accepting process, a gateway entity. That resource might be a data-accepting process, a gateway
to some other protocol, or a separate entity that accepts to some other protocol, or a separate entity that accepts
skipping to change at page 18, line 8 skipping to change at page 19, line 8
been received and has not yet been rejected by the server. The been received and has not yet been rejected by the server. The
client SHOULD continue by sending the remainder of the request or, if client SHOULD continue by sending the remainder of the request or, if
the request has already been completed, ignore this response. The the request has already been completed, ignore this response. The
server MUST send a final response after the request has been server MUST send a final response after the request has been
completed. See Section 7.2.3 of [Part1] for detailed discussion of completed. See Section 7.2.3 of [Part1] for detailed discussion of
the use and handling of this status code. the use and handling of this status code.
9.1.2. 101 Switching Protocols 9.1.2. 101 Switching Protocols
The server understands and is willing to comply with the client's The server understands and is willing to comply with the client's
request, via the Upgrade message header field (Section 5.4 of request, via the Upgrade message header field (Section 6.4 of
[Part5]), for a change in the application protocol being used on this [Part5]), for a change in the application protocol being used on this
connection. The server will switch protocols to those defined by the connection. The server will switch protocols to those defined by the
response's Upgrade header field immediately after the empty line response's Upgrade header field immediately after the empty line
which terminates the 101 response. which terminates the 101 response.
The protocol SHOULD be switched only when it is advantageous to do The protocol SHOULD be switched only when it is advantageous to do
so. For example, switching to a newer version of HTTP is so. For example, switching to a newer version of HTTP is
advantageous over older versions, and switching to a real-time, advantageous over older versions, and switching to a real-time,
synchronous protocol might be advantageous when delivering resources synchronous protocol might be advantageous when delivering resources
that use such features. that use such features.
skipping to change at page 19, line 8 skipping to change at page 20, line 8
SHOULD include an entity containing a list of resource SHOULD include an entity containing a list of resource
characteristics and location(s) from which the user or user agent can characteristics and location(s) from which the user or user agent can
choose the one most appropriate. The entity format is specified by choose the one most appropriate. The entity format is specified by
the media type given in the Content-Type header field. The origin the media type given in the Content-Type header field. The origin
server MUST create the resource before returning the 201 status code. server MUST create the resource before returning the 201 status code.
If the action cannot be carried out immediately, the server SHOULD If the action cannot be carried out immediately, the server SHOULD
respond with 202 (Accepted) response instead. respond with 202 (Accepted) response instead.
A 201 response MAY contain an ETag response header field indicating A 201 response MAY contain an ETag response header field indicating
the current value of the entity tag for the requested variant just the current value of the entity tag for the requested variant just
created, see Section 6.1 of [Part4]. created, see Section 7.1 of [Part4].
9.2.3. 202 Accepted 9.2.3. 202 Accepted
The request has been accepted for processing, but the processing has The request has been accepted for processing, but the processing has
not been completed. The request might or might not eventually be not been completed. The request might or might not eventually be
acted upon, as it might be disallowed when processing actually takes acted upon, as it might be disallowed when processing actually takes
place. There is no facility for re-sending a status code from an place. There is no facility for re-sending a status code from an
asynchronous operation such as this. asynchronous operation such as this.
The 202 response is intentionally non-committal. Its purpose is to The 202 response is intentionally non-committal. Its purpose is to
skipping to change at page 20, line 41 skipping to change at page 21, line 41
Note: previous versions of this specification recommended a Note: previous versions of this specification recommended a
maximum of five redirections. Content developers should be aware maximum of five redirections. Content developers should be aware
that there might be clients that implement such a fixed that there might be clients that implement such a fixed
limitation. limitation.
9.3.1. 300 Multiple Choices 9.3.1. 300 Multiple Choices
The requested resource corresponds to any one of a set of The requested resource corresponds to any one of a set of
representations, each with its own specific location, and agent- representations, each with its own specific location, and agent-
driven negotiation information (Section 4 of [Part3]) is being driven negotiation information (Section 5 of [Part3]) is being
provided so that the user (or user agent) can select a preferred provided so that the user (or user agent) can select a preferred
representation and redirect its request to that location. representation and redirect its request to that location.
Unless it was a HEAD request, the response SHOULD include an entity Unless it was a HEAD request, the response SHOULD include an entity
containing a list of resource characteristics and location(s) from containing a list of resource characteristics and location(s) from
which the user or user agent can choose the one most appropriate. which the user or user agent can choose the one most appropriate.
The entity format is specified by the media type given in the The entity format is specified by the media type given in the
Content-Type header field. Depending upon the format and the Content-Type header field. Depending upon the format and the
capabilities of the user agent, selection of the most appropriate capabilities of the user agent, selection of the most appropriate
choice MAY be performed automatically. However, this specification choice MAY be performed automatically. However, this specification
skipping to change at page 27, line 25 skipping to change at page 28, line 25
buffers for reading or manipulating the Request-URI. buffers for reading or manipulating the Request-URI.
9.4.16. 415 Unsupported Media Type 9.4.16. 415 Unsupported Media Type
The server is refusing to service the request because the entity of The server is refusing to service the request because the entity of
the request is in a format not supported by the requested resource the request is in a format not supported by the requested resource
for the requested method. for the requested method.
9.4.17. 416 Requested Range Not Satisfiable 9.4.17. 416 Requested Range Not Satisfiable
The request included a Range request-header field (Section 5.4 of The request included a Range request-header field (Section 6.4 of
[Part5]) and none of the range-specifier values in this field overlap [Part5]) and none of the range-specifier values in this field overlap
the current extent of the selected resource. the current extent of the selected resource.
9.4.18. 417 Expectation Failed 9.4.18. 417 Expectation Failed
The expectation given in an Expect request-header field (see The expectation given in an Expect request-header field (see
Section 10.2) could not be met by this server, or, if the server is a Section 10.2) could not be met by this server, or, if the server is a
proxy, the server has unambiguous evidence that the request could not proxy, the server has unambiguous evidence that the request could not
be met by the next-hop server. be met by the next-hop server.
skipping to change at page 28, line 43 skipping to change at page 29, line 43
The server, while acting as a gateway or proxy, did not receive a The server, while acting as a gateway or proxy, did not receive a
timely response from the upstream server specified by the URI (e.g. timely response from the upstream server specified by the URI (e.g.
HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed
to access in attempting to complete the request. to access in attempting to complete the request.
Note: Note to implementors: some deployed proxies are known to Note: Note to implementors: some deployed proxies are known to
return 400 or 500 when DNS lookups time out. return 400 or 500 when DNS lookups time out.
9.5.6. 505 HTTP Version Not Supported 9.5.6. 505 HTTP Version Not Supported
The server does not support, or refuses to support, the HTTP protocol The server does not support, or refuses to support, the 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 HTTP/1.1 header This section defines the syntax and semantics of HTTP/1.1 header
skipping to change at page 30, line 43 skipping to change at page 31, line 43
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 Section 3.4 of [RFC2822]: in Section 3.4 of [RFC2822]:
From = "From" ":" mailbox From = "From" ":" mailbox
mailbox = <mailbox, defined in [RFC2822], Section 3.4>
An example is: An example is:
From: webmaster@example.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
skipping to change at page 31, line 35 skipping to change at page 32, line 37
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 [ "#" fragment ] Location = "Location" ":" absoluteURI [ "#" fragment ]
An example is: An example is:
Location: http://www.example.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 6.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 There are circumstances in which a fragment identifier in a Location
URL would not be appropriate: URL would not be appropriate:
o With a 201 Created response, because in this usage the Location o With a 201 Created response, because in this usage the Location
header specifies the URL for the entire created resource. header specifies the URL for the entire created resource.
skipping to change at page 33, line 19 skipping to change at page 34, line 19
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
of seconds (in decimal) after the time of the response. of seconds (in decimal) after the time of the response.
Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds )
Time spans are non-negative decimal integers, representing time in
seconds.
delta-seconds = 1*DIGIT
Two examples of its use are Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
10.8. Server 10.8. Server
The Server response-header field contains information about the The Server response-header field contains information about the
software used by the origin server to handle the request. The field software used by the origin server to handle the request. The field
can contain multiple product tokens (Section 2) and comments can contain multiple product tokens (Section 3.5 of [Part1]) and
identifying the server and any significant subproducts. The product comments identifying the server and any significant subproducts. The
tokens are listed in order of their significance for identifying the product tokens are listed in order of their significance for
application. identifying the 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
MUST 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]).
skipping to change at page 34, line 13 skipping to change at page 35, line 15
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
user agent originating the request. This is for statistical user agent originating the request. This is for statistical
purposes, the tracing of protocol violations, and automated purposes, the tracing of protocol violations, and automated
recognition of user agents for the sake of tailoring responses to recognition of user agents for the sake of tailoring responses to
avoid particular user agent limitations. User agents SHOULD include avoid particular user agent limitations. User agents SHOULD include
this field with requests. The field can contain multiple product this field with requests. The field can contain multiple product
tokens (Section 2) and comments identifying the agent and any tokens (Section 3.5 of [Part1]) and comments identifying the agent
subproducts which form a significant part of the user agent. By and any subproducts which form a significant part of the user agent.
convention, the product tokens are listed in order of their By convention, the product tokens are listed in order of their
significance for identifying the application. significance for identifying the application.
User-Agent = "User-Agent" ":" 1*( product | comment ) User-Agent = "User-Agent" ":" 1*( product | comment )
Example: Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
11. IANA Considerations 11. IANA Considerations
TBD. [[anchor1: TBD.]]
12. Security Considerations 12. Security Considerations
This section is meant to inform application developers, information This section is meant to inform application developers, information
providers, and users of the security limitations in HTTP/1.1 as providers, and users of the security limitations in HTTP/1.1 as
described by this document. The discussion does not include described by this document. The discussion does not include
definitive solutions to the problems revealed, though it does make definitive solutions to the problems revealed, though it does make
some suggestions for reducing security risks. some suggestions for reducing security risks.
12.1. Transfer of Sensitive Information 12.1. Transfer of Sensitive Information
skipping to change at page 35, line 35 skipping to change at page 36, line 37
We suggest, though do not require, that a convenient toggle interface We suggest, though do not require, that a convenient toggle interface
be provided for the user to enable or disable the sending of From and be provided for the user to enable or disable the sending of From and
Referer information. Referer information.
The User-Agent (Section 10.9) or Server (Section 10.8) header fields The User-Agent (Section 10.9) or Server (Section 10.8) header fields
can sometimes be used to determine that a specific client or server can sometimes be used to determine that a specific client or server
have a particular security hole which might be exploited. have a particular security hole which might be exploited.
Unfortunately, this same information is often used for other valuable Unfortunately, this same information is often used for other valuable
purposes for which HTTP currently has no better mechanism. purposes for which HTTP currently has no better mechanism.
12.2. Encoding Sensitive Information in URI's 12.2. Encoding Sensitive Information in URIs
Because the source of a link might be private information or might Because the source of a link might be private information or might
reveal an otherwise private information source, it is strongly reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the recommended that the user be able to select whether or not the
Referer field is sent. For example, a browser client could have a Referer field is sent. For example, a browser client could have a
toggle switch for browsing openly/anonymously, which would toggle switch for browsing openly/anonymously, which would
respectively enable/disable the sending of Referer and From respectively enable/disable the sending of Referer and From
information. information.
Clients SHOULD NOT include a Referer header field in a (non-secure) Clients SHOULD NOT include a Referer header field in a (non-secure)
HTTP request if the referring page was transferred with a secure HTTP request if the referring page was transferred with a secure
protocol. protocol.
Authors of services which use the HTTP protocol SHOULD NOT use GET Authors of services should not use GET-based forms for the submission
based forms for the submission of sensitive data, because this will of sensitive data because that data will be encoded in the Request-
cause this data to be encoded in the Request-URI. Many existing URI. Many existing servers, proxies, and user agents log or display
servers, proxies, and user agents will log the request URI in some the Request-URI in places where it might be visible to third parties.
place where it might be visible to third parties. Servers can use Such services can use POST-based form submission instead.
POST-based form submission instead
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
14. References 14. References
14.1. Normative References 14.1. Normative References
[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H., [Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections, and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
and Message Parsing", draft-ietf-httpbis-p1-messaging-01 and Message Parsing", draft-ietf-httpbis-p1-messaging-02
(work in progress), January 2008. (work in progress), February 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., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
and Content Negotiation", draft-ietf-httpbis-p3-payload-01 and Content Negotiation", draft-ietf-httpbis-p3-payload-02
(work in progress), January 2008. (work in progress), February 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., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
Requests", draft-ietf-httpbis-p4-conditional-01 (work in Requests", draft-ietf-httpbis-p4-conditional-02 (work in
progress), January 2008. progress), February 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., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
Partial Responses", draft-ietf-httpbis-p5-range-01 (work Partial Responses", draft-ietf-httpbis-p5-range-02 (work
in progress), January 2008. in progress), February 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., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 6: Caching", and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
draft-ietf-httpbis-p6-cache-01 (work in progress), draft-ietf-httpbis-p6-cache-02 (work in progress),
January 2008. February 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., Berners-Lee, T., Lafon, Y., Ed., Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication", and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
draft-ietf-httpbis-p7-auth-01 (work in progress), draft-ietf-httpbis-p7-auth-02 (work in progress),
January 2008. February 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
14.2. Informative References 14.2. Informative References
[Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web [Luo1998] Luotonen, A., "Tunneling TCP based protocols through Web
proxy servers", draft-luotonen-web-proxy-tunneling-01 proxy servers", draft-luotonen-web-proxy-tunneling-01
(work in progress), August 1998. (work in progress), August 1998.
skipping to change at page 39, line 46 skipping to change at page 41, line 5
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>: o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/65>:
"Informative references" "Informative references"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/84>: "Redundant
cross-references" cross-references"
Other changes: Other changes:
o Move definitions of 304 and 412 condition codes to [Part4] o Move definitions of 304 and 412 condition codes to [Part4]
B.3. Since draft-ietf-httpbis-p2-semantics-01
Closed issues:
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/21>: "PUT side
effects"
o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/91>: "Duplicate
Host header requirements"
Ongoing work on ABNF conversion
(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):
o Move "Product Tokens" section (back) into Part 1, as "token" is
used in the definition of the Upgrade header.
o Add explicit references to BNF syntax and rules imported from
other parts of the specification.
o Copy definition of delta-seconds from Part6 instead of referencing
it.
Index Index
1 1
100 Continue (status code) 17 100 Continue (status code) 18
101 Switching Protocols (status code) 18 101 Switching Protocols (status code) 19
2 2
200 OK (status code) 18 200 OK (status code) 19
201 Created (status code) 18 201 Created (status code) 19
202 Accepted (status code) 19 202 Accepted (status code) 20
203 Non-Authoritative Information (status code) 19 203 Non-Authoritative Information (status code) 20
204 No Content (status code) 19 204 No Content (status code) 20
205 Reset Content (status code) 20 205 Reset Content (status code) 21
206 Partial Content (status code) 20 206 Partial Content (status code) 21
3 3
300 Multiple Choices (status code) 20 300 Multiple Choices (status code) 21
301 Moved Permanently (status code) 21 301 Moved Permanently (status code) 22
302 Found (status code) 21 302 Found (status code) 22
303 See Other (status code) 22 303 See Other (status code) 23
304 Not Modified (status code) 22 304 Not Modified (status code) 23
305 Use Proxy (status code) 22 305 Use Proxy (status code) 23
306 (Unused) (status code) 23 306 (Unused) (status code) 24
307 Temporary Redirect (status code) 23 307 Temporary Redirect (status code) 24
4 4
400 Bad Request (status code) 24 400 Bad Request (status code) 25
401 Unauthorized (status code) 24 401 Unauthorized (status code) 25
402 Payment Required (status code) 24 402 Payment Required (status code) 25
403 Forbidden (status code) 24 403 Forbidden (status code) 25
404 Not Found (status code) 24 404 Not Found (status code) 25
405 Method Not Allowed (status code) 24 405 Method Not Allowed (status code) 25
406 Not Acceptable (status code) 24 406 Not Acceptable (status code) 25
407 Proxy Authentication Required (status code) 25 407 Proxy Authentication Required (status code) 26
408 Request Timeout (status code) 25 408 Request Timeout (status code) 26
409 Conflict (status code) 25 409 Conflict (status code) 26
410 Gone (status code) 26 410 Gone (status code) 27
411 Length Required (status code) 26 411 Length Required (status code) 27
412 Precondition Failed (status code) 26 412 Precondition Failed (status code) 27
413 Request Entity Too Large (status code) 26 413 Request Entity Too Large (status code) 27
414 Request-URI Too Long (status code) 27 414 Request-URI Too Long (status code) 28
415 Unsupported Media Type (status code) 27 415 Unsupported Media Type (status code) 28
416 Requested Range Not Satisfiable (status code) 27 416 Requested Range Not Satisfiable (status code) 28
417 Expectation Failed (status code) 27 417 Expectation Failed (status code) 28
5 5
500 Internal Server Error (status code) 27 500 Internal Server Error (status code) 28
501 Not Implemented (status code) 28 501 Not Implemented (status code) 29
502 Bad Gateway (status code) 28 502 Bad Gateway (status code) 29
503 Service Unavailable (status code) 28 503 Service Unavailable (status code) 29
504 Gateway Timeout (status code) 28 504 Gateway Timeout (status code) 29
505 HTTP Version Not Supported (status code) 28 505 HTTP Version Not Supported (status code) 29
A A
Allow header 29 Allow header 30
C C
CONNECT method 17 CONNECT method 18
D D
DELETE method 16 DELETE method 17
E E
Expect header 29 Expect header 30
F F
From header 30 From header 31
G G
GET method 13 GET method 14
Grammar Grammar
Allow 29 Allow 30
Expect 29 delta-seconds 34
expect-params 29 Expect 30
expectation 29 expect-params 30
expectation-extension 29 expectation 30
extension-code 9 expectation-extension 30
extension-method 7 extension-code 10
From 30 extension-method 8
Location 31 From 31
Max-Forwards 32 Location 32
Method 7 Max-Forwards 33
product 6 Method 8
product-version 6 Reason-Phrase 10
Reason-Phrase 9 Referer 33
Referer 32 request-header 9
request-header 8 response-header 11
response-header 10 Retry-After 34
Retry-After 33 Server 34
Server 33 Status-Code 10
Status-Code 9 User-Agent 35
User-Agent 34
H H
HEAD method 13 HEAD method 14
Headers Headers
Allow 29 Allow 30
Expect 29 Expect 30
From 30 From 31
Location 31 Location 32
Max-Forwards 32 Max-Forwards 33
Referer 32 Referer 33
Retry-After 33 Retry-After 34
Server 33 Server 34
User-Agent 34 User-Agent 35
L L
LINK method 38 LINK method 39
Location header 31 Location header 32
M M
Max-Forwards header 32 Max-Forwards header 33
Methods Methods
CONNECT 17 CONNECT 18
DELETE 16 DELETE 17
GET 13 GET 14
HEAD 13 HEAD 14
LINK 38 LINK 39
OPTIONS 12 OPTIONS 13
PATCH 38 PATCH 39
POST 14 POST 15
PUT 15 PUT 16
TRACE 16 TRACE 17
UNLINK 38 UNLINK 39
O O
OPTIONS method 12 OPTIONS method 13
P P
PATCH method 38 PATCH method 39
POST method 14 POST method 15
PUT method 15 PUT method 16
R R
Referer header 32 Referer header 33
Retry-After header 33 Retry-After header 34
S S
Server header 33 Server header 34
Status Codes Status Codes
100 Continue 17 100 Continue 18
101 Switching Protocols 18 101 Switching Protocols 19
200 OK 18 200 OK 19
201 Created 18 201 Created 19
202 Accepted 19 202 Accepted 20
203 Non-Authoritative Information 19 203 Non-Authoritative Information 20
204 No Content 19 204 No Content 20
205 Reset Content 20 205 Reset Content 21
206 Partial Content 20 206 Partial Content 21
300 Multiple Choices 20 300 Multiple Choices 21
301 Moved Permanently 21 301 Moved Permanently 22
302 Found 21 302 Found 22
303 See Other 22 303 See Other 23
304 Not Modified 22 304 Not Modified 23
305 Use Proxy 22 305 Use Proxy 23
306 (Unused) 23 306 (Unused) 24
307 Temporary Redirect 23 307 Temporary Redirect 24
400 Bad Request 24 400 Bad Request 25
401 Unauthorized 24 401 Unauthorized 25
402 Payment Required 24 402 Payment Required 25
403 Forbidden 24 403 Forbidden 25
404 Not Found 24 404 Not Found 25
405 Method Not Allowed 24 405 Method Not Allowed 25
406 Not Acceptable 24 406 Not Acceptable 25
407 Proxy Authentication Required 25 407 Proxy Authentication Required 26
408 Request Timeout 25 408 Request Timeout 26
409 Conflict 25 409 Conflict 26
410 Gone 26 410 Gone 27
411 Length Required 26 411 Length Required 27
412 Precondition Failed 26 412 Precondition Failed 27
413 Request Entity Too Large 26 413 Request Entity Too Large 27
414 Request-URI Too Long 27 414 Request-URI Too Long 28
415 Unsupported Media Type 27 415 Unsupported Media Type 28
416 Requested Range Not Satisfiable 27 416 Requested Range Not Satisfiable 28
417 Expectation Failed 27 417 Expectation Failed 28
500 Internal Server Error 27 500 Internal Server Error 28
501 Not Implemented 28 501 Not Implemented 29
502 Bad Gateway 28 502 Bad Gateway 29
503 Service Unavailable 28 503 Service Unavailable 29
504 Gateway Timeout 28 504 Gateway Timeout 29
505 HTTP Version Not Supported 28 505 HTTP Version Not Supported 29
T T
TRACE method 16 TRACE method 17
U U
UNLINK method 38 UNLINK method 39
User-Agent header 34 User-Agent header 35
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
 End of changes. 65 change blocks. 
323 lines changed or deleted 378 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/