draft-ietf-httpbis-p2-semantics-24.txt   draft-ietf-httpbis-p2-semantics-25.txt 
HTTPbis Working Group R. Fielding, Ed. HTTPbis Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: 2616 (if approved) J. Reschke, Ed. Obsoletes: 2616 (if approved) J. Reschke, Ed.
Updates: 2817 (if approved) greenbytes Updates: 2817 (if approved) greenbytes
Intended status: Standards Track September 25, 2013 Intended status: Standards Track November 17, 2013
Expires: March 29, 2014 Expires: May 21, 2014
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
draft-ietf-httpbis-p2-semantics-24 draft-ietf-httpbis-p2-semantics-25
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP/1.1 messages, systems. This document defines the semantics of HTTP/1.1 messages,
as expressed by request methods, request header fields, response as expressed by request methods, request header fields, response
status codes, and response header fields, along with the payload of status codes, and response header fields, along with the payload of
messages (metadata and body content) and mechanisms for content messages (metadata and body content) and mechanisms for content
negotiation. negotiation.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix E.4. The changes in this draft are summarized in Appendix E.2.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on March 29, 2014. This Internet-Draft will expire on May 21, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 34 skipping to change at page 3, line 34
5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38
5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40
5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41
5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42
5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43
5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44
5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45
5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46
6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47
6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 47 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 48
6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50
6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50
6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50
6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52
6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52
6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53
6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53
6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54
6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55
6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56
6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56
6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57
6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57
6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 58
6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58
6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58
6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58
6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 59
6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59
6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59
6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60
6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61
6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61
6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 62
6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 63
6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 62 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63
6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63
6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63
6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63
6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63
7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 63 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64
7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68
7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69
7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71
7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72
7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72
7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73
skipping to change at page 5, line 10 skipping to change at page 5, line 10
8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77
8.3.1. Considerations for New Header Fields . . . . . . . . . 78 8.3.1. Considerations for New Header Fields . . . . . . . . . 78
8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80
8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80
8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81
9. Security Considerations . . . . . . . . . . . . . . . . . . . 81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81
9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81
9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82 9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82
9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82 9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82
9.4. Product Information . . . . . . . . . . . . . . . . . . . 83 9.4. Product Information . . . . . . . . . . . . . . . . . . . 82
9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83 9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83
9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83 9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
11.1. Normative References . . . . . . . . . . . . . . . . . . . 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 84
11.2. Informative References . . . . . . . . . . . . . . . . . . 86 11.2. Informative References . . . . . . . . . . . . . . . . . . 85
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88
A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89 A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 88
A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89 A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89 A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 96 publication) . . . . . . . . . . . . . . . . . . . . 95
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 96 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95
E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 96 E.2. Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 95
E.3. Since draft-ietf-httpbis-p2-semantics-22 . . . . . . . . . 97 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
E.4. Since draft-ietf-httpbis-p2-semantics-23 . . . . . . . . . 97
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
1. Introduction 1. Introduction
Each Hypertext Transfer Protocol (HTTP) message is either a request Each Hypertext Transfer Protocol (HTTP) message is either a request
or a response. A server listens on a connection for a request, or a response. A server listens on a connection for a request,
parses each message received, interprets the message semantics in parses each message received, interprets the message semantics in
relation to the identified request target, and responds to that relation to the identified request target, and responds to that
request with one or more response messages. A client constructs request with one or more response messages. A client constructs
request messages to communicate specific intentions, and examines request messages to communicate specific intentions, and examines
received responses to see if the intentions were carried out and received responses to see if the intentions were carried out and
skipping to change at page 23, line 48 skipping to change at page 23, line 48
query parameters, such as "page?do=delete". If the purpose of such a query parameters, such as "page?do=delete". If the purpose of such a
resource is to perform an unsafe action, then the resource owner MUST resource is to perform an unsafe action, then the resource owner MUST
disable or disallow that action when it is accessed using a safe disable or disallow that action when it is accessed using a safe
request method. Failure to do so will result in unfortunate side- request method. Failure to do so will result in unfortunate side-
effects when automated processes perform a GET on every URI reference effects when automated processes perform a GET on every URI reference
for the sake of link maintenance, pre-fetching, building a search for the sake of link maintenance, pre-fetching, building a search
index, etc. index, etc.
4.2.2. Idempotent Methods 4.2.2. Idempotent Methods
Request methods are considered "idempotent" if the intended effect of A request method is considered "idempotent" if the intended effect on
multiple identical requests is the same as for a single request. Of the server of multiple identical requests with that method is the
the request methods defined by this specification, the PUT, DELETE, same as the effect for a single such request. Of the request methods
and safe request methods are idempotent. defined by this specification, PUT, DELETE, and safe request methods
are idempotent.
Like the definition of safe, the idempotent property only applies to Like the definition of safe, the idempotent property only applies to
what has been requested by the user; a server is free to log each what has been requested by the user; a server is free to log each
request separately, retain a revision control history, or implement request separately, retain a revision control history, or implement
other non-idempotent side-effects for each idempotent request. other non-idempotent side-effects for each idempotent request.
Idempotent methods are distinguished because the request can be Idempotent methods are distinguished because the request can be
repeated automatically if a communication failure occurs before the repeated automatically if a communication failure occurs before the
client is able to read the server's response. For example, if a client is able to read the server's response. For example, if a
client sends a PUT request and the underlying connection is closed client sends a PUT request and the underlying connection is closed
before any response is received, then it can establish a new before any response is received, then the client can establish a new
connection and retry the idempotent request because it knows that connection and retry the idempotent request because it knows that
repeating the request will have the same effect even if the original repeating the request will have the same effect (even if the original
request succeeded. Note, however, that repeated failures would request succeeded, though the status codes might differ in response).
indicate a problem within the server. Note, however, that repeated communication failures might indicate
that the server has failed in general, or that something in the
request is triggering a connection drop.
4.2.3. Cacheable Methods 4.2.3. Cacheable Methods
Request methods can be defined as "cacheable" to indicate that Request methods can be defined as "cacheable" to indicate that
responses to them are allowed to be stored for future reuse; for responses to them are allowed to be stored for future reuse; for
specific requirements see [Part6]. In general, safe methods that do specific requirements see [Part6]. In general, safe methods that do
not depend on a current or authoritative response are defined as not depend on a current or authoritative response are defined as
cacheable; this specification defines GET, HEAD and POST as cacheable; this specification defines GET, HEAD and POST as
cacheable, although the overwhelming majority of cache cacheable, although the overwhelming majority of cache
implementations only support GET and HEAD. implementations only support GET and HEAD.
skipping to change at page 45, line 17 skipping to change at page 45, line 17
The "Referer" [sic] header field allows the user agent to specify a The "Referer" [sic] header field allows the user agent to specify a
URI reference for the resource from which the target URI was obtained URI reference for the resource from which the target URI was obtained
(i.e., the "referrer", though the field name is misspelled). A user (i.e., the "referrer", though the field name is misspelled). A user
agent MUST NOT include the fragment and userinfo components of the agent MUST NOT include the fragment and userinfo components of the
URI reference [RFC3986], if any, when generating the Referer field URI reference [RFC3986], if any, when generating the Referer field
value. value.
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
Referer allows servers to generate back-links to other resources for The Referer header field allows servers to generate back-links to
simple analytics, logging, optimized caching, etc. It also allows other resources for simple analytics, logging, optimized caching,
obsolete or mistyped links to be found for maintenance. Some servers etc. It also allows obsolete or mistyped links to be found for
use Referer as a means of denying links from other sites (so-called maintenance. Some servers use the Referer header field as a means of
"deep linking") or restricting cross-site request forgery (CSRF), but denying links from other sites (so-called "deep linking") or
not all requests contain a Referer header field. restricting cross-site request forgery (CSRF), but not all requests
contain it.
Example: Example:
Referer: http://www.example.org/hypertext/Overview.html Referer: http://www.example.org/hypertext/Overview.html
If the target URI was obtained from a source that does not have its If the target URI was obtained from a source that does not have its
own URI (e.g., input from the user keyboard, or an entry within the own URI (e.g., input from the user keyboard, or an entry within the
user's bookmarks/favorites), the user agent MUST either exclude user's bookmarks/favorites), the user agent MUST either exclude
Referer or send it with a value of "about:blank". Referer or send it with a value of "about:blank".
skipping to change at page 48, line 7 skipping to change at page 48, line 13
valid request valid request
6.1. Overview of Status Codes 6.1. Overview of Status Codes
The status codes listed below are defined in this specification, The status codes listed below are defined in this specification,
Section 4 of [Part4], Section 4 of [Part5], and Section 3 of [Part7]. Section 4 of [Part4], Section 4 of [Part5], and Section 3 of [Part7].
The reason phrases listed here are only recommendations -- they can The reason phrases listed here are only recommendations -- they can
be replaced by local equivalents without affecting the protocol. be replaced by local equivalents without affecting the protocol.
Responses with status codes that are defined as cacheable by default Responses with status codes that are defined as cacheable by default
(e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
reused by a cache with heuristic expiration unless otherwise specification) can be reused by a cache with heuristic expiration
indicated by the method definition or explicit cache controls unless otherwise indicated by the method definition or explicit cache
[Part6]; all other status codes are not cacheable by default. controls [Part6]; all other status codes are not cacheable by
default.
+------+-------------------------------+------------------------+ +------+-------------------------------+------------------------+
| code | reason-phrase | Defined in... | | code | reason-phrase | Defined in... |
+------+-------------------------------+------------------------+ +------+-------------------------------+------------------------+
| 100 | Continue | Section 6.2.1 | | 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 | | 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 | | 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 | | 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 | | 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 | | 203 | Non-Authoritative Information | Section 6.3.4 |
skipping to change at page 51, line 47 skipping to change at page 51, line 47
TRACE a representation of the request message as received by the end TRACE a representation of the request message as received by the end
server. server.
Aside from responses to CONNECT, a 200 response always has a payload, Aside from responses to CONNECT, a 200 response always has a payload,
though an origin server MAY generate a payload body of zero length. though an origin server MAY generate a payload body of zero length.
If no payload is desired, an origin server ought to send 204 (No If no payload is desired, an origin server ought to send 204 (No
Content) instead. For CONNECT, no payload is allowed because the Content) instead. For CONNECT, no payload is allowed because the
successful result is a tunnel, which begins immediately after the 200 successful result is a tunnel, which begins immediately after the 200
response header section. response header section.
A 200 response is cacheable unless otherwise indicated by the method A 200 response is cacheable by default; i.e., unless otherwise
definition or explicit cache controls (see Section 4.2.2 of [Part6]). indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]).
6.3.2. 201 Created 6.3.2. 201 Created
The 201 (Created) status code indicates that the request has been The 201 (Created) status code indicates that the request has been
fulfilled and has resulted in one or more new resources being fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location by either a Location header field in the response or, if no Location
field is received, by the effective request URI. field is received, by the effective request URI.
The 201 response payload typically describes and links to the The 201 response payload typically describes and links to the
skipping to change at page 52, line 52 skipping to change at page 52, line 52
to notify recipients when a transformation has been applied, since to notify recipients when a transformation has been applied, since
that knowledge might impact later decisions regarding the content. that knowledge might impact later decisions regarding the content.
For example, future cache validation requests for the content might For example, future cache validation requests for the content might
only be applicable along the same request path (through the same only be applicable along the same request path (through the same
proxies). proxies).
The 203 response is similar to the Warning code of 214 Transformation The 203 response is similar to the Warning code of 214 Transformation
Applied (Section 5.5 of [Part6]), which has the advantage of being Applied (Section 5.5 of [Part6]), which has the advantage of being
applicable to responses with any status code. applicable to responses with any status code.
A 203 response is cacheable unless otherwise indicated by the method A 203 response is cacheable by default; i.e., unless otherwise
definition or explicit cache controls (see Section 4.2.2 of [Part6]). indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]).
6.3.5. 204 No Content 6.3.5. 204 No Content
The 204 (No Content) status code indicates that the server has The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional successfully fulfilled the request and that there is no additional
content to send in the response payload body. Metadata in the content to send in the response payload body. Metadata in the
response header fields refer to the target resource and its selected response header fields refer to the target resource and its selected
representation after the requested action was applied. representation after the requested action was applied.
For example, if a 204 status code is received in response to a PUT For example, if a 204 status code is received in response to a PUT
skipping to change at page 53, line 36 skipping to change at page 53, line 37
For example, a 204 status code is commonly used with document editing For example, a 204 status code is commonly used with document editing
interfaces corresponding to a "save" action, such that the document interfaces corresponding to a "save" action, such that the document
being saved remains available to the user for editing. It is also being saved remains available to the user for editing. It is also
frequently used with interfaces that expect automated data transfers frequently used with interfaces that expect automated data transfers
to be prevalent, such as within distributed version control systems. to be prevalent, such as within distributed version control systems.
A 204 response is terminated by the first empty line after the header A 204 response is terminated by the first empty line after the header
fields because it cannot contain a message body. fields because it cannot contain a message body.
A 204 response is cacheable unless otherwise indicated by the method A 204 response is cacheable by default; i.e., unless otherwise
definition or explicit cache controls (see Section 4.2.2 of [Part6]). indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]).
6.3.6. 205 Reset Content 6.3.6. 205 Reset Content
The 205 (Reset Content) status code indicates that the server has The 205 (Reset Content) status code indicates that the server has
fulfilled the request and desires that the user agent reset the fulfilled the request and desires that the user agent reset the
"document view", which caused the request to be sent, to its original "document view", which caused the request to be sent, to its original
state as received from the origin server. state as received from the origin server.
This response is intended to support a common data entry use case This response is intended to support a common data entry use case
where the user receives content that supports data entry (a form, where the user receives content that supports data entry (a form,
skipping to change at page 55, line 43 skipping to change at page 55, line 46
redirection. redirection.
For request methods other than HEAD, the server SHOULD generate a For request methods other than HEAD, the server SHOULD generate a
payload in the 300 response containing a list of representation payload in the 300 response containing a list of representation
metadata and URI reference(s) from which the user or user agent can metadata and URI reference(s) from which the user or user agent can
choose the one most preferred. The user agent MAY make a selection choose the one most preferred. The user agent MAY make a selection
from that list automatically, depending upon the list format, but from that list automatically, depending upon the list format, but
this specification does not define a standard for such automatic this specification does not define a standard for such automatic
selection. selection.
A 300 response is cacheable unless otherwise indicated by the method A 300 response is cacheable by default; i.e., unless otherwise
definition or explicit cache controls (see Section 4.2.2 of [Part6]). indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]).
Note: The original proposal for 300 defined the URI header field Note: The original proposal for 300 defined the URI header field
as providing a list of alternative representations, such that it as providing a list of alternative representations, such that it
would be usable for 200, 300, and 406 responses and be transferred would be usable for 200, 300, and 406 responses and be transferred
in responses to the HEAD method. However, lack of deployment and in responses to the HEAD method. However, lack of deployment and
disagreement over syntax led to both URI and Alternates (a disagreement over syntax led to both URI and Alternates (a
subsequent proposal) being dropped from this specification. It is subsequent proposal) being dropped from this specification. It is
possible to communicate the list using a set of Link header fields possible to communicate the list using a set of Link header fields
[RFC5988], each with a relationship of "alternate", though [RFC5988], each with a relationship of "alternate", though
deployment is a chicken-and-egg problem. deployment is a chicken-and-egg problem.
skipping to change at page 56, line 28 skipping to change at page 56, line 35
containing a preferred URI reference for the new permanent URI. The containing a preferred URI reference for the new permanent URI. The
user agent MAY use the Location field value for automatic user agent MAY use the Location field value for automatic
redirection. The server's response payload usually contains a short redirection. The server's response payload usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
Note: For historic reasons, a user agent MAY change the request Note: For historic reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead. can be used instead.
A 301 response is cacheable unless otherwise indicated by the method A 301 response is cacheable by default; i.e., unless otherwise
definition or explicit cache controls (see Section 4.2.2 of [Part6]). indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]).
6.4.3. 302 Found 6.4.3. 302 Found
The 302 (Found) status code indicates that the target resource The 302 (Found) status code indicates that the target resource
resides temporarily under a different URI. Since the redirection resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the might be altered on occasion, the client ought to continue to use the
effective request URI for future requests. effective request URI for future requests.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
skipping to change at page 59, line 26 skipping to change at page 59, line 33
6.5.4. 404 Not Found 6.5.4. 404 Not Found
The 404 (Not Found) status code indicates that the origin server did The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not not find a current representation for the target resource or is not
willing to disclose that one exists. A 404 status code does not willing to disclose that one exists. A 404 status code does not
indicate whether this lack of representation is temporary or indicate whether this lack of representation is temporary or
permanent; the 410 (Gone) status code is preferred over 404 if the permanent; the 410 (Gone) status code is preferred over 404 if the
origin server knows, presumably through some configurable means, that origin server knows, presumably through some configurable means, that
the condition is likely to be permanent. the condition is likely to be permanent.
A 404 response is cacheable unless otherwise indicated by the method A 404 response is cacheable by default; i.e., unless otherwise
definition or explicit cache controls (see Section 4.2.2 of [Part6]). indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]).
6.5.5. 405 Method Not Allowed 6.5.5. 405 Method Not Allowed
The 405 (Method Not Allowed) status code indicates that the method The 405 (Method Not Allowed) status code indicates that the method
received in the request-line is known by the origin server but not received in the request-line is known by the origin server but not
supported by the target resource. The origin server MUST generate an supported by the target resource. The origin server MUST generate an
Allow header field in a 405 response containing a list of the target Allow header field in a 405 response containing a list of the target
resource's currently supported methods. resource's currently supported methods.
A 405 response is cacheable unless otherwise indicated by the method A 405 response is cacheable by default; i.e., unless otherwise
definition or explicit cache controls (see Section 4.2.2 of [Part6]). indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]).
6.5.6. 406 Not Acceptable 6.5.6. 406 Not Acceptable
The 406 (Not Acceptable) status code indicates that the target The 406 (Not Acceptable) status code indicates that the target
resource does not have a current representation that would be resource does not have a current representation that would be
acceptable to the user agent, according to the proactive negotiation acceptable to the user agent, according to the proactive negotiation
header fields received in the request (Section 5.3), and the server header fields received in the request (Section 5.3), and the server
is unwilling to supply a default representation. is unwilling to supply a default representation.
The server SHOULD generate a payload containing a list of available The server SHOULD generate a payload containing a list of available
skipping to change at page 61, line 5 skipping to change at page 61, line 15
The 410 response is primarily intended to assist the task of web The 410 response is primarily intended to assist the task of web
maintenance by notifying the recipient that the resource is maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common remote links to that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging to for limited-time, promotional services and for resources belonging to
individuals no longer associated with the origin server's site. It individuals no longer associated with the origin server's site. It
is not necessary to mark all permanently unavailable resources as is not necessary to mark all permanently unavailable resources as
"gone" or to keep the mark for any length of time -- that is left to "gone" or to keep the mark for any length of time -- that is left to
the discretion of the server owner. the discretion of the server owner.
A 410 response is cacheable unless otherwise indicated by the method A 410 response is cacheable by default; i.e., unless otherwise
definition or explicit cache controls (see Section 4.2.2 of [Part6]). indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]).
6.5.10. 411 Length Required 6.5.10. 411 Length Required
The 411 (Length Required) status code indicates that the server The 411 (Length Required) status code indicates that the server
refuses to accept the request without a defined Content-Length refuses to accept the request without a defined Content-Length
(Section 3.3.2 of [Part1]). The client MAY repeat the request if it (Section 3.3.2 of [Part1]). The client MAY repeat the request if it
adds a valid Content-Length header field containing the length of the adds a valid Content-Length header field containing the length of the
message body in the request message. message body in the request message.
6.5.11. 413 Payload Too Large 6.5.11. 413 Payload Too Large
skipping to change at page 61, line 39 skipping to change at page 61, line 50
The 414 (URI Too Long) status code indicates that the server is The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the request-target (Section refusing to service the request because the request-target (Section
5.3 of [Part1]) is longer than the server is willing to interpret. 5.3 of [Part1]) is longer than the server is willing to interpret.
This rare condition is only likely to occur when a client has This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query improperly converted a POST request to a GET request with long query
information, when the client has descended into a "black hole" of information, when the client has descended into a "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of redirection (e.g., a redirected URI prefix that points to a suffix of
itself), or when the server is under attack by a client attempting to itself), or when the server is under attack by a client attempting to
exploit potential security holes. exploit potential security holes.
A 414 response is cacheable unless otherwise indicated by the method A 414 response is cacheable by default; i.e., unless otherwise
definition or explicit cache controls (see Section 4.2.2 of [Part6]). indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]).
6.5.13. 415 Unsupported Media Type 6.5.13. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource. is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated Content- The format problem might be due to the request's indicated Content-
Type or Content-Encoding, or as a result of inspecting the data Type or Content-Encoding, or as a result of inspecting the data
directly. directly.
skipping to change at page 63, line 6 skipping to change at page 63, line 18
encountered an unexpected condition that prevented it from fulfilling encountered an unexpected condition that prevented it from fulfilling
the request. the request.
6.6.2. 501 Not Implemented 6.6.2. 501 Not Implemented
The 501 (Not Implemented) status code indicates that the server does The 501 (Not Implemented) status code indicates that the server does
not support the functionality required to fulfill the request. This not support the functionality required to fulfill the request. This
is the appropriate response when the server does not recognize the is the appropriate response when the server does not recognize the
request method and is not capable of supporting it for any resource. request method and is not capable of supporting it for any resource.
A 501 response is cacheable unless otherwise indicated by the method A 501 response is cacheable by default; i.e., unless otherwise
definition or explicit cache controls (see Section 4.2.2 of [Part6]). indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]).
6.6.3. 502 Bad Gateway 6.6.3. 502 Bad Gateway
The 502 (Bad Gateway) status code indicates that the server, while The 502 (Bad Gateway) status code indicates that the server, while
acting as a gateway or proxy, received an invalid response from an acting as a gateway or proxy, received an invalid response from an
inbound server it accessed while attempting to fulfill the request. inbound server it accessed while attempting to fulfill the request.
6.6.4. 503 Service Unavailable 6.6.4. 503 Service Unavailable
The 503 (Service Unavailable) status code indicates that the server The 503 (Service Unavailable) status code indicates that the server
skipping to change at page 65, line 13 skipping to change at page 65, line 25
MUST accept all three HTTP-date formats. When a sender generates a MUST accept all three HTTP-date formats. When a sender generates a
header field that contains one or more timestamps defined as HTTP- header field that contains one or more timestamps defined as HTTP-
date, the sender MUST generate those timestamps in the IMF-fixdate date, the sender MUST generate those timestamps in the IMF-fixdate
format. format.
An HTTP-date value represents time as an instance of Coordinated An HTTP-date value represents time as an instance of Coordinated
Universal Time (UTC). The first two formats indicate UTC by the Universal Time (UTC). The first two formats indicate UTC by the
three-letter abbreviation for Greenwich Mean Time, "GMT", a three-letter abbreviation for Greenwich Mean Time, "GMT", a
predecessor of the UTC name; values in the asctime format are assumed predecessor of the UTC name; values in the asctime format are assumed
to be in UTC. A sender that generates HTTP-date values from a local to be in UTC. A sender that generates HTTP-date values from a local
clock ought to use NTP ([RFC1305]) or some similar protocol to clock ought to use NTP ([RFC5905]) or some similar protocol to
synchronize its clock to UTC. synchronize its clock to UTC.
Preferred format: Preferred format:
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone subset of the format defined in ; fixed length/zone subset of the format defined in
; Section 3.3 of [RFC5322] ; Section 3.3 of [RFC5322]
day-name = %x4D.6F.6E ; "Mon", case-sensitive day-name = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive / %x54.75.65 ; "Tue", case-sensitive
skipping to change at page 70, line 7 skipping to change at page 70, line 7
7.1.3. Retry-After 7.1.3. Retry-After
Servers send the "Retry-After" header field to indicate how long the Servers send the "Retry-After" header field to indicate how long the
user agent ought to wait before making a follow-up request. When user agent ought to wait before making a follow-up request. When
sent with a 503 (Service Unavailable) response, Retry-After indicates sent with a 503 (Service Unavailable) response, Retry-After indicates
how long the service is expected to be unavailable to the client. how long the service is expected to be unavailable to the client.
When sent with any 3xx (Redirection) response, Retry-After indicates When sent with any 3xx (Redirection) response, Retry-After indicates
the minimum time that the user agent is asked to wait before issuing the minimum time that the user agent is asked to wait before issuing
the redirected request. the redirected request.
The value of this field can be either an HTTP-date or an integer The value of this field can be either an HTTP-date or a number of
number of seconds (in decimal) after the time of the response. seconds to delay after the response is received.
Retry-After = HTTP-date / delta-seconds Retry-After = HTTP-date / delay-seconds
Time spans are non-negative decimal integers, representing time in A delay-seconds value is a non-negative decimal integer, representing
seconds. time in seconds.
delta-seconds = 1*DIGIT delay-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.
7.1.4. Vary 7.1.4. Vary
skipping to change at page 74, line 8 skipping to change at page 74, line 8
subproducts by third parties. Overly long and detailed Server field subproducts by third parties. Overly long and detailed Server field
values increase response latency and potentially reveal internal values increase response latency and potentially reveal internal
implementation details that might make it (slightly) easier for implementation details that might make it (slightly) easier for
attackers to find and exploit known security holes. attackers to find and exploit known security holes.
8. IANA Considerations 8. IANA Considerations
8.1. Method Registry 8.1. Method Registry
The HTTP Method Registry defines the name space for the request The HTTP Method Registry defines the name space for the request
method token (Section 4). The method registry will be created and method token (Section 4). The method registry will be created and
maintained at <http://www.iana.org/assignments/http-methods>. maintained at (the suggested URI)
<http://www.iana.org/assignments/http-methods>.
8.1.1. Procedure 8.1.1. Procedure
HTTP method registrations MUST include the following fields: HTTP method registrations MUST include the following fields:
o Method Name (see Section 4) o Method Name (see Section 4)
o Safe ("yes" or "no", see Section 4.2.1) o Safe ("yes" or "no", see Section 4.2.1)
o Idempotent ("yes" or "no", see Section 4.2.2) o Idempotent ("yes" or "no", see Section 4.2.2)
skipping to change at page 78, line 13 skipping to change at page 78, line 13
message-header-index.html>, as defined by [BCP90]. message-header-index.html>, as defined by [BCP90].
8.3.1. Considerations for New Header Fields 8.3.1. Considerations for New Header Fields
Header fields are key:value pairs that can be used to communicate Header fields are key:value pairs that can be used to communicate
data about the message, its payload, the target resource, or the data about the message, its payload, the target resource, or the
connection (i.e., control data). See Section 3.2 of [Part1] for a connection (i.e., control data). See Section 3.2 of [Part1] for a
general definition of header field syntax in HTTP messages. general definition of header field syntax in HTTP messages.
The requirements for header field names are defined in [BCP90]. The requirements for header field names are defined in [BCP90].
Authors of specifications defining new fields are advised to keep the Authors of specifications defining new fields are advised to keep the
name as short as practical and to not prefix the name with "X-" name as short as practical and to not prefix the name with "X-"
unless the header field will never be used on the Internet. (The unless the header field will never be used on the Internet. (The
"x-" prefix idiom has been extensively misused in practice; it was "x-" prefix idiom has been extensively misused in practice; it was
intended to only be used as a mechanism for avoiding name collisions intended to only be used as a mechanism for avoiding name collisions
inside proprietary software or intranet processing, since the prefix inside proprietary software or intranet processing, since the prefix
would ensure that private names never collide with a newly registered would ensure that private names never collide with a newly registered
Internet name.) Internet name; see [BCP178] for further information)
New header field values typically have their syntax defined using New header field values typically have their syntax defined using
ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1] ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1]
as necessary, and are usually constrained to the range of ASCII as necessary, and are usually constrained to the range of ASCII
characters. Header fields needing a greater range of characters can characters. Header fields needing a greater range of characters can
use an encoding such as the one defined in [RFC5987]. use an encoding such as the one defined in [RFC5987].
Leading and trailing whitespace in raw field values is removed upon Leading and trailing whitespace in raw field values is removed upon
field parsing (Section 3.2.4 of [Part1]). Field definitions where field parsing (Section 3.2.4 of [Part1]). Field definitions where
leading or trailing whitespace in values is significant will have to leading or trailing whitespace in values is significant will have to
skipping to change at page 81, line 25 skipping to change at page 81, line 25
Values to be added to this name space require IETF Review (see Values to be added to this name space require IETF Review (see
Section 4.1 of [RFC5226]), and MUST conform to the purpose of content Section 4.1 of [RFC5226]), and MUST conform to the purpose of content
coding defined in this section. coding defined in this section.
8.4.2. Registrations 8.4.2. Registrations
The HTTP Content Codings Registry shall be updated with the The HTTP Content Codings Registry shall be updated with the
registrations below: registrations below:
+------------+--------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| Name | Description | Reference | | Name | Description | Reference |
+------------+--------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| compress | UNIX "compress" data format [Welch] | Section 4.2.1 | | identity | Reserved (synonym for "no encoding" in | Section 5.3.4 |
| | | of [Part1] | | | Accept-Encoding) | |
| deflate | "deflate" compressed data | Section 4.2.2 | +----------+----------------------------------------+---------------+
| | ([RFC1951]) inside the "zlib" data | of [Part1] |
| | format ([RFC1950]) | |
| gzip | GZIP file format [RFC1952] | Section 4.2.3 |
| | | of [Part1] |
| identity | Reserved (synonym for "no encoding" | Section 5.3.4 |
| | in Accept-Encoding) | |
| x-compress | Deprecated (alias for compress) | Section 4.2.1 |
| | | of [Part1] |
| x-gzip | Deprecated (alias for gzip) | Section 4.2.3 |
| | | of [Part1] |
+------------+--------------------------------------+---------------+
9. Security Considerations 9. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns relevant to HTTP/1.1 semantics and users of known security concerns relevant to HTTP/1.1 semantics
and its use for transferring information over the Internet. and its use for transferring information over the Internet.
9.1. Attacks Based On File and Path Names 9.1. Attacks Based On File and Path Names
Origin servers frequently make use of their local file system to Origin servers frequently make use of their local file system to
skipping to change at page 84, line 48 skipping to change at page 84, line 37
10. Acknowledgments 10. Acknowledgments
See Section 10 of [Part1]. See Section 10 of [Part1].
11. References 11. References
11.1. Normative References 11.1. Normative References
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and Transfer Protocol (HTTP/1.1): Message Syntax and
Routing", draft-ietf-httpbis-p1-messaging-24 (work in Routing", draft-ietf-httpbis-p1-messaging-25 (work in
progress), September 2013. progress), November 2013.
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-24 (work in draft-ietf-httpbis-p4-conditional-25 (work in
progress), September 2013. progress), November 2013.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range "Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-24 (work in Requests", draft-ietf-httpbis-p5-range-25 (work in
progress), September 2013. progress), November 2013.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-24 (work in progress), draft-ietf-httpbis-p6-cache-25 (work in progress),
September 2013. November 2013.
[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-24 (work in progress), draft-ietf-httpbis-p7-auth-25 (work in progress),
September 2013. November 2013.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
G. Randers-Pehrson, "GZIP file format specification
version 4.3", RFC 1952, May 1996.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part One: Format of Internet Mail Extensions (MIME) Part One: Format of Internet
Message Bodies", RFC 2045, November 1996. Message Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Two: Media Types", Mail Extensions (MIME) Part Two: Media Types",
RFC 2046, November 1996. RFC 2046, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 86, line 15 skipping to change at page 85, line 42
January 2008. January 2008.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for
Identifying Languages", BCP 47, RFC 5646, Identifying Languages", BCP 47, RFC 5646,
September 2009. September 2009.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
September 2011. September 2011.
[Welch] Welch, T., "A Technique for High Performance Data
Compression", IEEE Computer 17(6), June 1984.
11.2. Informative References 11.2. Informative References
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013. RFC 6838, January 2013.
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, Procedures for Message Header Fields", BCP 90,
RFC 3864, September 2004. RFC 3864, September 2004.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Doctoral Network-based Software Architectures", Doctoral
Dissertation, University of California, Irvine , Dissertation, University of California, Irvine ,
September 2000, September 2000,
<http://roy.gbiv.com/pubs/dissertation/top.htm>. <http://roy.gbiv.com/pubs/dissertation/top.htm>.
[RFC1305] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation", RFC 1305, March 1992.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen,
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945,
May 1996. May 1996.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet
Mail Extensions (MIME) Part Five: Conformance Criteria Mail Extensions (MIME) Part Five: Conformance Criteria
and Examples", RFC 2049, November 1996. and Examples", RFC 2049, November 1996.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and
T. Berners-Lee, "Hypertext Transfer Protocol -- T. Berners-Lee, "Hypertext Transfer Protocol --
skipping to change at page 87, line 35 skipping to change at page 87, line 11
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, an IANA Considerations Section in RFCs", BCP 26,
RFC 5226, May 2008. RFC 5226, May 2008.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. October 2008.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, March 2010. RFC 5789, March 2010.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and
Algorithms Specification", RFC 5905, June 2010.
[RFC5987] Reschke, J., "Character Set and Language Encoding for [RFC5987] Reschke, J., "Character Set and Language Encoding for
Hypertext Transfer Protocol (HTTP) Header Field Hypertext Transfer Protocol (HTTP) Header Field
Parameters", RFC 5987, August 2010. Parameters", RFC 5987, August 2010.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6266] Reschke, J., "Use of the Content-Disposition Header [RFC6266] Reschke, J., "Use of the Content-Disposition Header
skipping to change at page 94, line 4 skipping to change at page 93, line 22
Expect = "100-continue" Expect = "100-continue"
From = mailbox From = mailbox
GMT = %x47.4D.54 ; GMT GMT = %x47.4D.54 ; GMT
HTTP-date = IMF-fixdate / obs-date HTTP-date = IMF-fixdate / obs-date
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
Location = URI-reference Location = URI-reference
Max-Forwards = 1*DIGIT Max-Forwards = 1*DIGIT
OWS = <OWS, defined in [Part1], Section 3.2.3> OWS = <OWS, defined in [Part1], Section 3.2.3>
RWS = <RWS, defined in [Part1], Section 3.2.3> RWS = <RWS, defined in [Part1], Section 3.2.3>
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delta-seconds Retry-After = HTTP-date / delay-seconds
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
URI-reference = <URI-reference, defined in [Part1], Section 2.7> URI-reference = <URI-reference, defined in [Part1], Section 2.7>
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
) ) ) )
absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
skipping to change at page 94, line 51 skipping to change at page 94, line 22
/ %x46.72.69 ; Fri / %x46.72.69 ; Fri
/ %x53.61.74 ; Sat / %x53.61.74 ; Sat
/ %x53.75.6E ; Sun / %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday / %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday / %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday / %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday / %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday / %x53.75.6E.64.61.79 ; Sunday
delta-seconds = 1*DIGIT delay-seconds = 1*DIGIT
field-name = <comment, defined in [Part1], Section 3.2> field-name = <comment, defined in [Part1], Section 3.2>
hour = 2DIGIT hour = 2DIGIT
language-range = <language-range, defined in [RFC4647], Section 2.1> language-range = <language-range, defined in [RFC4647], Section 2.1>
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, defined in [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" OWS parameter ) ";" OWS parameter )
skipping to change at page 96, line 12 skipping to change at page 95, line 32
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
word = <word, defined in [Part1], Section 3.2.6> word = <word, defined in [Part1], Section 3.2.6>
year = 4DIGIT year = 4DIGIT
Appendix E. Change Log (to be removed by RFC Editor before publication) Appendix E. Change Log (to be removed by RFC Editor before publication)
E.1. Since RFC 2616 E.1. Since RFC 2616
Changes up to the first Working Group Last Call draft are summarized Changes up to the IETF Last Call draft are summarized in <http://
in <http://trac.tools.ietf.org/html/ trac.tools.ietf.org/html/
draft-ietf-httpbis-p2-semantics-21#appendix-F>. draft-ietf-httpbis-p2-semantics-24#appendix-E>.
E.2. Since draft-ietf-httpbis-p2-semantics-21
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/22>: "ETag (and
other metadata) in status messages"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/96>: "Conditional
GET text"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/146>: "Clarify
description of 405 (Not Allowed)"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
heuristic caching for new status codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/315>: "method
semantics: retrieval/representation"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/388>: "User
confirmation for unsafe methods"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/404>: "Tentative
Status Codes"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/418>: "No-Transform"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/419>: "p2 editorial
feedback"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/424>: "Absence of
Accept-Encoding"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/428>: "Accept-
Language ordering for identical qvalues"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Identify
additional status codes as cacheable by default"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in
header field considerations that leading/trailing WS is lossy"
E.3. Since draft-ietf-httpbis-p2-semantics-22
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list
expansion in ABNF appendices"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/448>: "Fallback for
Accept-Language"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a
higher minor HTTP version number"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/456>: "Language-tag
vs. language-range"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering
x-gzip and x-deflate"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/459>: "RFC2774 and
method registrations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/488>: "Selection
based upon request target"
E.4. Since draft-ietf-httpbis-p2-semantics-23 E.2. Since draft-ietf-httpbis-p2-semantics-24
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Review
isn't generic" Cachability of Status Codes WRT 'Negative Caching'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/450>: "p2 Editorial
feedback"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/452>: "Content-
Length in HEAD responses"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/458>: "Requirements
upon proxies for Expect"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/468>: "Expectation
Extensions"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/470>: "What is o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref
'Cacheable'?" needs to be updated to 5905"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/478>: "MUSTs and o <http://tools.ietf.org/wg/httpbis/trac/ticket/501>: "idempotency:
other feedback" clarify 'effect'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/487>: "Resubmission o <http://tools.ietf.org/wg/httpbis/trac/ticket/503>: "APPSDIR
of 403" review of draft-ietf-httpbis-p2-semantics-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/491>: "does 205 o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA
allow chunked encoding?" registrations to correct draft"
Index Index
1 1
1xx Informational (status code class) 50 1xx Informational (status code class) 50
2 2
2xx Successful (status code class) 51 2xx Successful (status code class) 51
3 3
skipping to change at page 99, line 7 skipping to change at page 96, line 44
203 Non-Authoritative Information (status code) 52 203 Non-Authoritative Information (status code) 52
204 No Content (status code) 53 204 No Content (status code) 53
205 Reset Content (status code) 53 205 Reset Content (status code) 53
3 3
300 Multiple Choices (status code) 55 300 Multiple Choices (status code) 55
301 Moved Permanently (status code) 56 301 Moved Permanently (status code) 56
302 Found (status code) 56 302 Found (status code) 56
303 See Other (status code) 57 303 See Other (status code) 57
305 Use Proxy (status code) 57 305 Use Proxy (status code) 57
306 (Unused) (status code) 57 306 (Unused) (status code) 58
307 Temporary Redirect (status code) 58 307 Temporary Redirect (status code) 58
4 4
400 Bad Request (status code) 58 400 Bad Request (status code) 58
402 Payment Required (status code) 58 402 Payment Required (status code) 58
403 Forbidden (status code) 58 403 Forbidden (status code) 59
404 Not Found (status code) 59 404 Not Found (status code) 59
405 Method Not Allowed (status code) 59 405 Method Not Allowed (status code) 59
406 Not Acceptable (status code) 59 406 Not Acceptable (status code) 59
408 Request Timeout (status code) 60 408 Request Timeout (status code) 60
409 Conflict (status code) 60 409 Conflict (status code) 60
410 Gone (status code) 60 410 Gone (status code) 60
411 Length Required (status code) 61 411 Length Required (status code) 61
413 Payload Too Large (status code) 61 413 Payload Too Large (status code) 61
414 URI Too Long (status code) 61 414 URI Too Long (status code) 61
415 Unsupported Media Type (status code) 61 415 Unsupported Media Type (status code) 62
417 Expectation Failed (status code) 62 417 Expectation Failed (status code) 62
426 Upgrade Required (status code) 62 426 Upgrade Required (status code) 62
5 5
500 Internal Server Error (status code) 62 500 Internal Server Error (status code) 63
501 Not Implemented (status code) 62 501 Not Implemented (status code) 63
502 Bad Gateway (status code) 63 502 Bad Gateway (status code) 63
503 Service Unavailable (status code) 63 503 Service Unavailable (status code) 63
504 Gateway Timeout (status code) 63 504 Gateway Timeout (status code) 63
505 HTTP Version Not Supported (status code) 63 505 HTTP Version Not Supported (status code) 63
A A
Accept header field 38 Accept header field 38
Accept-Charset header field 40 Accept-Charset header field 40
Accept-Encoding header field 41 Accept-Encoding header field 41
Accept-Language header field 42 Accept-Language header field 42
skipping to change at page 100, line 42 skipping to change at page 98, line 30
content-coding 11 content-coding 11
Content-Encoding 12 Content-Encoding 12
Content-Language 13 Content-Language 13
Content-Location 15 Content-Location 15
Content-Type 10 Content-Type 10
Date 67 Date 67
date1 66 date1 66
day 66 day 66
day-name 66 day-name 66
day-name-l 66 day-name-l 66
delta-seconds 70 delay-seconds 70
Expect 34 Expect 34
From 44 From 44
GMT 66 GMT 66
hour 66 hour 66
HTTP-date 64 HTTP-date 64
IMF-fixdate 66 IMF-fixdate 66
language-range 42 language-range 42
language-tag 13 language-tag 13
Location 68 Location 68
Max-Forwards 36 Max-Forwards 36
 End of changes. 64 change blocks. 
216 lines changed or deleted 135 lines changed or added

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