draft-ietf-httpbis-p2-semantics-26.txt   draft-ietf-httpbis-p2-semantics-latest.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 February 6, 2014 Intended status: Standards Track June 2014
Expires: August 10, 2014 Expires: December 3, 2014
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
draft-ietf-httpbis-p2-semantics-26 draft-ietf-httpbis-p2-semantics-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level 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.3. _This is a temporary document for the purpose of tracking the
editorial changes made during the AUTH48 (RFC publication) phase._
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 August 10, 2014.
This Internet-Draft will expire on December 3, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 2, line 50 skipping to change at page 3, line 4
3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8
3.1.1. Processing Representation Data . . . . . . . . . . . . 8 3.1.1. Processing Representation Data . . . . . . . . . . . . 8
3.1.2. Encoding for Compression or Integrity . . . . . . . . 11 3.1.2. Encoding for Compression or Integrity . . . . . . . . 11
3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13
3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14 3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14
3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17
3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17
3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18
3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19
3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20
4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21 4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22 4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22
4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22 4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22
4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23 4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23
4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24 4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24
4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24 4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24
4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32
5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33
5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 33 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36
5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36
5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37
5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37
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 . . . . . . . . . . . . . . . . . . . . . . . 44 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 . . . . . . . . . . . . . . . . . . . . 49 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50
6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 49 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50
6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 49 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50
6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 50 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 50 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51
6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 51 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 51 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52
6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 52 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53
6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 52 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53
6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 53 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54
6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 54 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55
6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 55 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56
6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 55 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56
6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 56 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57
6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 56 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57
6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 56 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57
6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 57 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58
6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 57 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58
6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 57 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58
6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 57 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58
6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 57 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58
6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 58 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59
6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 58 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59
6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 58 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59
6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 59 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60
6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 59 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60
6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 59 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60
6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 60 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61
6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 60 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61
6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 60 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61
6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 60 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61
6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 61 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62
6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 61 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62
6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 61 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62
6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 61 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62
6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 62 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63
6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 62 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63
6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 62 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63
6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 62 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63
6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 62 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63
7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 63 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64
7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 63 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64
7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 63 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64
7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 67 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68
7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 68 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69
7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 69 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 70 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71
7.3. Authentication Challenges . . . . . . . . . . . . . . . . 71 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72
7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 71 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72
7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 71 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 72 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 73 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74
8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 73 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74
8.1.2. Considerations for New Methods . . . . . . . . . . . . 73 8.1.2. Considerations for New Methods . . . . . . . . . . . . 74
8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 74 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75
8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 74 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75
8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75
8.2.2. Considerations for New Status Codes . . . . . . . . . 75 8.2.2. Considerations for New Status Codes . . . . . . . . . 76
8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76
8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 76 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77
8.3.1. Considerations for New Header Fields . . . . . . . . . 77 8.3.1. Considerations for New Header Fields . . . . . . . . . 78
8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 79 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80
8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 79 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 81
8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 80 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81
9. Security Considerations . . . . . . . . . . . . . . . . . . . 80 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81
9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81 9.1. Attacks Based on File and Path Names . . . . . . . . . . . 82
9.2. Attacks Based On Command, Code, or Query Injection . . . . 81 9.2. Attacks Based on Command, Code, or Query Injection . . . . 82
9.3. Disclosure of Personal Information . . . . . . . . . . . . 82 9.3. Disclosure of Personal Information . . . . . . . . . . . . 83
9.4. Disclosure of Sensitive Information in URIs . . . . . . . 82 9.4. Disclosure of Sensitive Information in URIs . . . . . . . 83
9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 82 9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 83
9.6. Disclosure of Product Information . . . . . . . . . . . . 83 9.6. Disclosure of Product Information . . . . . . . . . . . . 84
9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83 9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . . 84 11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . . 85 11.2. Informative References . . . . . . . . . . . . . . . . . . 86
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 87 Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 89
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 89
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89
A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89 A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89
A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89 A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 90
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89 A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 90
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93
Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 95
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95
E.2. Since draft-ietf-httpbis-p2-semantics-24 . . . . . . . . . 95
E.3. Since draft-ietf-httpbis-p2-semantics-25 . . . . . . . . . 96
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
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, examines
received responses to see if the intentions were carried out and received responses to see if the intentions were carried out, and
determine how to interpret the results. This document defines determines how to interpret the results. This document defines
HTTP/1.1 request and response semantics in terms of the architecture HTTP/1.1 request and response semantics in terms of the architecture
defined in [Part1]. defined in [RFC7230].
HTTP provides a uniform interface for interacting with a resource HTTP provides a uniform interface for interacting with a resource
(Section 2), regardless of its type, nature, or implementation, via (Section 2), regardless of its type, nature, or implementation, via
the manipulation and transfer of representations (Section 3). the manipulation and transfer of representations (Section 3).
HTTP semantics include the intentions defined by each request method HTTP semantics include the intentions defined by each request method
(Section 4), extensions to those semantics that might be described in (Section 4), extensions to those semantics that might be described in
request header fields (Section 5), the meaning of status codes to request header fields (Section 5), the meaning of status codes to
indicate a machine-readable response (Section 6), and the meaning of indicate a machine-readable response (Section 6), and the meaning of
other control data and resource metadata that might be given in other control data and resource metadata that might be given in
skipping to change at page 6, line 42 skipping to change at page 6, line 42
selection algorithms that are collectively referred to as ""content selection algorithms that are collectively referred to as ""content
negotiation"" (Section 3.4). negotiation"" (Section 3.4).
1.1. Conformance and Error Handling 1.1. Conformance and Error Handling
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 2.5 of [Part1]. defined in Section 2.5 of [RFC7230].
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] with a list extension, defined in Section 7 of notation of [RFC5234] with a list extension, defined in Section 7 of
[Part1], that allows for compact definition of comma-separated lists [RFC7230], that allows for compact definition of comma-separated
using a '#' operator (similar to how the '*' operator indicates lists using a '#' operator (similar to how the '*' operator indicates
repetition). Appendix C describes rules imported from other repetition). Appendix C describes rules imported from other
documents. Appendix D shows the collected grammar with all list documents. Appendix D shows the collected grammar with all list
operators expanded to standard ABNF notation. operators expanded to standard ABNF notation.
This specification uses the terms "character", "character encoding This specification uses the terms "character", "character encoding
scheme", "charset", and "protocol element" as they are defined in scheme", "charset", and "protocol element" as they are defined in
[RFC6365]. [RFC6365].
2. Resources 2. Resources
The target of an HTTP request is called a resource. HTTP does not The target of an HTTP request is called a ""resource"". HTTP does
limit the nature of a resource; it merely defines an interface that not limit the nature of a resource; it merely defines an interface
might be used to interact with resources. Each resource is that might be used to interact with resources. Each resource is
identified by a Uniform Resource Identifier (URI), as described in identified by a Uniform Resource Identifier (URI), as described in
Section 2.7 of [Part1]. Section 2.7 of [RFC7230].
When a client constructs an HTTP/1.1 request message, it sends the When a client constructs an HTTP/1.1 request message, it sends the
target URI in one of various forms, as defined in (Section 5.3 of target URI in one of various forms, as defined in (Section 5.3 of
[Part1]). When a request is received, the server reconstructs an [RFC7230]). When a request is received, the server reconstructs an
effective request URI for the target resource (Section 5.5 of effective request URI for the target resource (Section 5.5 of
[Part1]). [RFC7230]).
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
semantics in the request method (Section 4) and a few request- semantics in the request method (Section 4) and a few request-
modifying header fields (Section 5). If there is a conflict between modifying header fields (Section 5). If there is a conflict between
the method semantics and any semantic implied by the URI itself, as the method semantics and any semantic implied by the URI itself, as
described in Section 4.2.1, the method semantics take precedence. described in Section 4.2.1, the method semantics take precedence.
3. Representations 3. Representations
skipping to change at page 7, line 46 skipping to change at page 7, line 46
abstraction is needed to represent ("take the place of") the current abstraction is needed to represent ("take the place of") the current
or desired state of that thing in our communications. That or desired state of that thing in our communications. That
abstraction is called a representation [REST]. abstraction is called a representation [REST].
For the purposes of HTTP, a ""representation"" is information that is For the purposes of HTTP, a ""representation"" is information that is
intended to reflect a past, current, or desired state of a given intended to reflect a past, current, or desired state of a given
resource, in a format that can be readily communicated via the resource, in a format that can be readily communicated via the
protocol, and that consists of a set of representation metadata and a protocol, and that consists of a set of representation metadata and a
potentially unbounded stream of representation data. potentially unbounded stream of representation data.
An origin server might be provided with, or capable of generating, An origin server might be provided with, or be capable of generating,
multiple representations that are each intended to reflect the multiple representations that are each intended to reflect the
current state of a target resource. In such cases, some algorithm is current state of a target resource. In such cases, some algorithm is
used by the origin server to select one of those representations as used by the origin server to select one of those representations as
most applicable to a given request, usually based on content most applicable to a given request, usually based on content
negotiation. This ""selected representation"" is used to provide the negotiation. This ""selected representation"" is used to provide the
data and metadata for evaluating conditional requests [Part4] and data and metadata for evaluating conditional requests [RFC7232] and
constructing the payload for 200 (OK) and 304 (Not Modified) constructing the payload for 200 (OK) and 304 (Not Modified)
responses to GET (Section 4.3.1). responses to GET (Section 4.3.1).
3.1. Representation Metadata 3.1. Representation Metadata
Representation header fields provide metadata about the Representation header fields provide metadata about the
representation. When a message includes a payload body, the representation. When a message includes a payload body, the
representation header fields describe how to interpret the representation header fields describe how to interpret the
representation data enclosed in the payload body. In a response to a representation data enclosed in the payload body. In a response to a
HEAD request, the representation header fields describe the HEAD request, the representation header fields describe the
skipping to change at page 8, line 32 skipping to change at page 8, line 32
| Content-Type | Section 3.1.1.5 | | Content-Type | Section 3.1.1.5 |
| Content-Encoding | Section 3.1.2.2 | | Content-Encoding | Section 3.1.2.2 |
| Content-Language | Section 3.1.3.2 | | Content-Language | Section 3.1.3.2 |
| Content-Location | Section 3.1.4.2 | | Content-Location | Section 3.1.4.2 |
+-------------------+-----------------+ +-------------------+-----------------+
3.1.1. Processing Representation Data 3.1.1. Processing Representation Data
3.1.1.1. Media Type 3.1.1.1. Media Type
HTTP uses Internet Media Types [RFC2046] in the Content-Type HTTP uses Internet media types [RFC2046] in the Content-Type
(Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order
to provide open and extensible data typing and type negotiation. to provide open and extensible data typing and type negotiation.
Media types define both a data format and various processing models: Media types define both a data format and various processing models:
how to process that data in accordance with each context in which it how to process that data in accordance with each context in which it
is received. is received.
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token type = token
subtype = token subtype = token
skipping to change at page 9, line 7 skipping to change at page 9, line 7
parameter = token "=" ( token / quoted-string ) parameter = token "=" ( token / quoted-string )
The type, subtype, and parameter name tokens are case-insensitive. The type, subtype, and parameter name tokens are case-insensitive.
Parameter values might or might not be case-sensitive, depending on Parameter values might or might not be case-sensitive, depending on
the semantics of the parameter name. The presence or absence of a the semantics of the parameter name. The presence or absence of a
parameter might be significant to the processing of a media-type, parameter might be significant to the processing of a media-type,
depending on its definition within the media type registry. depending on its definition within the media type registry.
A parameter value that matches the token production can be A parameter value that matches the token production can be
transmitted as either a token or within a quoted-string. The quoted transmitted either as a token or within a quoted-string. The quoted
and unquoted values are equivalent. For example, the following and unquoted values are equivalent. For example, the following
examples are all equivalent, but the first is preferred for examples are all equivalent, but the first is preferred for
consistency: consistency:
text/html;charset=utf-8 text/html;charset=utf-8
text/html;charset=UTF-8 text/html;charset=UTF-8
Text/HTML;Charset="utf-8" Text/HTML;Charset="utf-8"
text/html; charset="utf-8" text/html; charset="utf-8"
Internet media types ought to be registered with IANA according to Internet media types ought to be registered with IANA according to
skipping to change at page 9, line 32 skipping to change at page 9, line 32
around the "=" character. around the "=" character.
3.1.1.2. Charset 3.1.1.2. Charset
HTTP uses "charset" names to indicate or negotiate the character HTTP uses "charset" names to indicate or negotiate the character
encoding scheme of a textual representation [RFC6365]. A charset is encoding scheme of a textual representation [RFC6365]. A charset is
identified by a case-insensitive token. identified by a case-insensitive token.
charset = token charset = token
Charset names ought to be registered in IANA Character Set registry Charset names ought to be registered in the IANA "Character Sets"
(<http://www.iana.org/assignments/character-sets>) according to the registry (<http://www.iana.org/assignments/character-sets>) according
procedures defined in [RFC2978]. to the procedures defined in [RFC2978].
3.1.1.3. Canonicalization and Text Defaults 3.1.1.3. Canonicalization and Text Defaults
Internet media types are registered with a canonical form in order to Internet media types are registered with a canonical form in order to
be interoperable among systems with varying native encoding formats. be interoperable among systems with varying native encoding formats.
Representations selected or transferred via HTTP ought to be in Representations selected or transferred via HTTP ought to be in
canonical form, for many of the same reasons described by the canonical form, for many of the same reasons described by the
Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the
performance characteristics of email deployments (i.e., store and performance characteristics of email deployments (i.e., store and
forward messages to peers) are significantly different from those forward messages to peers) are significantly different from those
skipping to change at page 10, line 32 skipping to change at page 10, line 32
[RFC2046], and include a boundary parameter as part of the media type [RFC2046], and include a boundary parameter as part of the media type
value. The message body is itself a protocol element; a sender MUST value. The message body is itself a protocol element; a sender MUST
generate only CRLF to represent line breaks between body parts. generate only CRLF to represent line breaks between body parts.
HTTP message framing does not use the multipart boundary as an HTTP message framing does not use the multipart boundary as an
indicator of message body length, though it might be used by indicator of message body length, though it might be used by
implementations that generate or process the payload. For example, implementations that generate or process the payload. For example,
the "multipart/form-data" type is often used for carrying form data the "multipart/form-data" type is often used for carrying form data
in a request, as described in [RFC2388], and the "multipart/ in a request, as described in [RFC2388], and the "multipart/
byteranges" type is defined by this specification for use in some 206 byteranges" type is defined by this specification for use in some 206
(Partial Content) responses [Part5]. (Partial Content) responses [RFC7233].
3.1.1.5. Content-Type 3.1.1.5. Content-Type
The "Content-Type" header field indicates the media type of the The "Content-Type" header field indicates the media type of the
associated representation: either the representation enclosed in the associated representation: either the representation enclosed in the
message payload or the selected representation, as determined by the message payload or the selected representation, as determined by the
message semantics. The indicated media type defines both the data message semantics. The indicated media type defines both the data
format and how that data is intended to be processed by a recipient, format and how that data is intended to be processed by a recipient,
within the scope of the received message semantics, after any content within the scope of the received message semantics, after any content
codings indicated by Content-Encoding are decoded. codings indicated by Content-Encoding are decoded.
skipping to change at page 11, line 36 skipping to change at page 11, line 36
been or can be applied to a representation. Content codings are been or can be applied to a representation. Content codings are
primarily used to allow a representation to be compressed or primarily used to allow a representation to be compressed or
otherwise usefully transformed without losing the identity of its otherwise usefully transformed without losing the identity of its
underlying media type and without loss of information. Frequently, underlying media type and without loss of information. Frequently,
the representation is stored in coded form, transmitted directly, and the representation is stored in coded form, transmitted directly, and
only decoded by the final recipient. only decoded by the final recipient.
content-coding = token content-coding = token
All content-coding values are case-insensitive and ought to be All content-coding values are case-insensitive and ought to be
registered within the HTTP Content Coding registry, as defined in registered within the "HTTP Content Coding Registry", as defined in
Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) Section 8.4. They are used in the Accept-Encoding (Section 5.3.4)
and Content-Encoding (Section 3.1.2.2) header fields. and Content-Encoding (Section 3.1.2.2) header fields.
The following content-coding values are defined by this The following content-coding values are defined by this
specification: specification:
compress (and x-compress): See Section 4.2.1 of [Part1]. compress (and x-compress): See Section 4.2.1 of [RFC7230].
deflate: See Section 4.2.2 of [Part1]. deflate: See Section 4.2.2 of [RFC7230].
gzip (and x-gzip): See Section 4.2.3 of [Part1]. gzip (and x-gzip): See Section 4.2.3 of [RFC7230].
3.1.2.2. Content-Encoding 3.1.2.2. Content-Encoding
The "Content-Encoding" header field indicates what content codings The "Content-Encoding" header field indicates what content codings
have been applied to the representation, beyond those inherent in the have been applied to the representation, beyond those inherent in the
media type, and thus what decoding mechanisms have to be applied in media type, and thus what decoding mechanisms have to be applied in
order to obtain data in the media type referenced by the Content-Type order to obtain data in the media type referenced by the Content-Type
header field. Content-Encoding is primarily used to allow a header field. Content-Encoding is primarily used to allow a
representation's data to be compressed without losing the identity of representation's data to be compressed without losing the identity of
its underlying media type. its underlying media type.
skipping to change at page 12, line 28 skipping to change at page 12, line 28
Content-Encoding: gzip Content-Encoding: gzip
If one or more encodings have been applied to a representation, the If one or more encodings have been applied to a representation, the
sender that applied the encodings MUST generate a Content-Encoding sender that applied the encodings MUST generate a Content-Encoding
header field that lists the content codings in the order in which header field that lists the content codings in the order in which
they were applied. Additional information about the encoding they were applied. Additional information about the encoding
parameters can be provided by other header fields not defined by this parameters can be provided by other header fields not defined by this
specification. specification.
Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings Unlike Transfer-Encoding (Section 3.3.1 of [RFC7230]), the codings
listed in Content-Encoding are a characteristic of the listed in Content-Encoding are a characteristic of the
representation; the representation is defined in terms of the coded representation; the representation is defined in terms of the coded
form, and all other metadata about the representation is about the form, and all other metadata about the representation is about the
coded form unless otherwise noted in the metadata definition. coded form unless otherwise noted in the metadata definition.
Typically, the representation is only decoded just prior to rendering Typically, the representation is only decoded just prior to rendering
or analogous usage. or analogous usage.
If the media type includes an inherent encoding, such as a data If the media type includes an inherent encoding, such as a data
format that is always compressed, then that encoding would not be format that is always compressed, then that encoding would not be
restated in Content-Encoding even if it happens to be the same restated in Content-Encoding even if it happens to be the same
skipping to change at page 13, line 19 skipping to change at page 13, line 19
A language tag, as defined in [RFC5646], identifies a natural A language tag, as defined in [RFC5646], identifies a natural
language spoken, written, or otherwise conveyed by human beings for language spoken, written, or otherwise conveyed by human beings for
communication of information to other human beings. Computer communication of information to other human beings. Computer
languages are explicitly excluded. languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and Content- HTTP uses language tags within the Accept-Language and Content-
Language header fields. Accept-Language uses the broader language- Language header fields. Accept-Language uses the broader language-
range production defined in Section 5.3.5, whereas Content-Language range production defined in Section 5.3.5, whereas Content-Language
uses the language-tag production defined below. uses the language-tag production defined below.
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> language-tag = <Language-Tag, see [RFC5646], Section 2.1>
A language tag is a sequence of one or more case-insensitive subtags, A language tag is a sequence of one or more case-insensitive subtags,
each separated by a hyphen character ("-", %x2D). In most cases, a each separated by a hyphen character ("-", %x2D). In most cases, a
language tag consists of a primary language subtag that identifies a language tag consists of a primary language subtag that identifies a
broad family of related languages (e.g., "en" = English) which is broad family of related languages (e.g., "en" = English), which is
optionally followed by a series of subtags that refine or narrow that optionally followed by a series of subtags that refine or narrow that
language's range (e.g., "en-CA" = the variety of English as language's range (e.g., "en-CA" = the variety of English as
communicated in Canada). Whitespace is not allowed within a language communicated in Canada). Whitespace is not allowed within a language
tag. Example tags include: tag. Example tags include:
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
See [RFC5646] for further information. See [RFC5646] for further information.
3.1.3.2. Content-Language 3.1.3.2. Content-Language
skipping to change at page 14, line 50 skipping to change at page 14, line 50
might still be useful for revision history links. might still be useful for revision history links.
o Otherwise, the payload is unidentified. o Otherwise, the payload is unidentified.
For a response message, the following rules are applied in order For a response message, the following rules are applied in order
until a match is found: until a match is found:
1. If the request method is GET or HEAD and the response status code 1. If the request method is GET or HEAD and the response status code
is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not
Modified), the payload is a representation of the resource Modified), the payload is a representation of the resource
identified by the effective request URI (Section 5.5 of [Part1]). identified by the effective request URI (Section 5.5 of
[RFC7230]).
2. If the request method is GET or HEAD and the response status code 2. If the request method is GET or HEAD and the response status code
is 203 (Non-Authoritative Information), the payload is a is 203 (Non-Authoritative Information), the payload is a
potentially modified or enhanced representation of the target potentially modified or enhanced representation of the target
resource as provided by an intermediary. resource as provided by an intermediary.
3. If the response has a Content-Location header field and its 3. If the response has a Content-Location header field and its
field-value is a reference to the same URI as the effective field-value is a reference to the same URI as the effective
request URI, the payload is a representation of the resource request URI, the payload is a representation of the resource
identified by the effective request URI. identified by the effective request URI.
skipping to change at page 15, line 37 skipping to change at page 15, line 37
The "Content-Location" header field references a URI that can be used The "Content-Location" header field references a URI that can be used
as an identifier for a specific resource corresponding to the as an identifier for a specific resource corresponding to the
representation in this message's payload. In other words, if one representation in this message's payload. In other words, if one
were to perform a GET request on this URI at the time of this were to perform a GET request on this URI at the time of this
message's generation, then a 200 (OK) response would contain the same message's generation, then a 200 (OK) response would contain the same
representation that is enclosed as payload in this message. representation that is enclosed as payload in this message.
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
The Content-Location value is not a replacement for the effective The Content-Location value is not a replacement for the effective
Request URI (Section 5.5 of [Part1]). It is representation metadata. Request URI (Section 5.5 of [RFC7230]). It is representation
It has the same syntax and semantics as the header field of the same metadata. It has the same syntax and semantics as the header field
name defined for MIME body parts in Section 4 of [RFC2557]. However, of the same name defined for MIME body parts in Section 4 of
its appearance in an HTTP message has some special implications for [RFC2557]. However, its appearance in an HTTP message has some
HTTP recipients. special implications for HTTP recipients.
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its value refers (after conversion to absolute form) to a message and its value refers (after conversion to absolute form) to a
URI that is the same as the effective request URI, then the recipient URI that is the same as the effective request URI, then the recipient
MAY consider the payload to be a current representation of that MAY consider the payload to be a current representation of that
resource at the time indicated by the message origination date. For resource at the time indicated by the message origination date. For
a GET (Section 4.3.1) or HEAD (Section 4.3.2) request, this is the a GET (Section 4.3.1) or HEAD (Section 4.3.2) request, this is the
same as the default semantics when no Content-Location is provided by same as the default semantics when no Content-Location is provided by
the server. For a state-changing request like PUT (Section 4.3.4) or the server. For a state-changing request like PUT (Section 4.3.4) or
POST (Section 4.3.3), it implies that the server's response contains POST (Section 4.3.3), it implies that the server's response contains
skipping to change at page 18, line 10 skipping to change at page 18, line 10
applying the processing. Response messages with an error status code applying the processing. Response messages with an error status code
usually contain a payload that represents the error condition, such usually contain a payload that represents the error condition, such
that it describes the error state and what next steps are suggested that it describes the error state and what next steps are suggested
for resolving it. for resolving it.
Header fields that specifically describe the payload, rather than the Header fields that specifically describe the payload, rather than the
associated representation, are referred to as "payload header associated representation, are referred to as "payload header
fields". Payload header fields are defined in other parts of this fields". Payload header fields are defined in other parts of this
specification, due to their impact on message parsing. specification, due to their impact on message parsing.
+-------------------+--------------------------+ +-------------------+----------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+--------------------------+ +-------------------+----------------------------+
| Content-Length | Section 3.3.2 of [Part1] | | Content-Length | Section 3.3.2 of [RFC7230] |
| Content-Range | Section 4.2 of [Part5] | | Content-Range | Section 4.2 of [RFC7233] |
| Trailer | Section 4.4 of [Part1] | | Trailer | Section 4.4 of [RFC7230] |
| Transfer-Encoding | Section 3.3.1 of [Part1] | | Transfer-Encoding | Section 3.3.1 of [RFC7230] |
+-------------------+--------------------------+ +-------------------+----------------------------+
3.4. Content Negotiation 3.4. Content Negotiation
When responses convey payload information, whether indicating a When responses convey payload information, whether indicating a
success or an error, the origin server often has different ways of success or an error, the origin server often has different ways of
representing that information; for example, in different formats, representing that information; for example, in different formats,
languages, or encodings. Likewise, different users or user agents languages, or encodings. Likewise, different users or user agents
might have differing capabilities, characteristics, or preferences might have differing capabilities, characteristics, or preferences
that could influence which representation, among those available, that could influence which representation, among those available,
would be best to deliver. For this reason, HTTP provides mechanisms would be best to deliver. For this reason, HTTP provides mechanisms
skipping to change at page 19, line 22 skipping to change at page 19, line 22
it might vary, such as language, content-coding, etc.) compared to it might vary, such as language, content-coding, etc.) compared to
various information supplied in the request, including both the various information supplied in the request, including both the
explicit negotiation fields of Section 5.3 and implicit explicit negotiation fields of Section 5.3 and implicit
characteristics, such as the client's network address or parts of the characteristics, such as the client's network address or parts of the
User-Agent field. User-Agent field.
Proactive negotiation is advantageous when the algorithm for Proactive negotiation is advantageous when the algorithm for
selecting from among the available representations is difficult to selecting from among the available representations is difficult to
describe to a user agent, or when the server desires to send its describe to a user agent, or when the server desires to send its
"best guess" to the user agent along with the first response (hoping "best guess" to the user agent along with the first response (hoping
to avoid the round-trip delay of a subsequent request if the "best to avoid the round trip delay of a subsequent request if the "best
guess" is good enough for the user). In order to improve the guess" is good enough for the user). In order to improve the
server's guess, a user agent MAY send request header fields that server's guess, a user agent MAY send request header fields that
describe its preferences. describe its preferences.
Proactive negotiation has serious disadvantages: Proactive negotiation has serious disadvantages:
o It is impossible for the server to accurately determine what might o It is impossible for the server to accurately determine what might
be "best" for any given user, since that would require complete be "best" for any given user, since that would require complete
knowledge of both the capabilities of the user agent and the knowledge of both the capabilities of the user agent and the
intended use for the response (e.g., does the user want to view it intended use for the response (e.g., does the user want to view it
skipping to change at page 20, line 38 skipping to change at page 20, line 38
A server might choose not to send an initial representation, other A server might choose not to send an initial representation, other
than the list of alternatives, and thereby indicate that reactive than the list of alternatives, and thereby indicate that reactive
negotiation by the user agent is preferred. For example, the negotiation by the user agent is preferred. For example, the
alternatives listed in responses with the 300 (Multiple Choices) and alternatives listed in responses with the 300 (Multiple Choices) and
406 (Not Acceptable) status codes include information about the 406 (Not Acceptable) status codes include information about the
available representations so that the user or user agent can react by available representations so that the user or user agent can react by
making a selection. making a selection.
Reactive negotiation is advantageous when the response would vary Reactive negotiation is advantageous when the response would vary
over commonly-used dimensions (such as type, language, or encoding), over commonly used dimensions (such as type, language, or encoding),
when the origin server is unable to determine a user agent's when the origin server is unable to determine a user agent's
capabilities from examining the request, and generally when public capabilities from examining the request, and generally when public
caches are used to distribute server load and reduce network usage. caches are used to distribute server load and reduce network usage.
Reactive negotiation suffers from the disadvantages of transmitting a Reactive negotiation suffers from the disadvantages of transmitting a
list of alternatives to the user agent, which degrades user-perceived list of alternatives to the user agent, which degrades user-perceived
latency if transmitted in the header section, and needing a second latency if transmitted in the header section, and needing a second
request to obtain an alternate representation. Furthermore, this request to obtain an alternate representation. Furthermore, this
specification does not define a mechanism for supporting automatic specification does not define a mechanism for supporting automatic
selection, though it does not prevent such a mechanism from being selection, though it does not prevent such a mechanism from being
skipping to change at page 21, line 18 skipping to change at page 21, line 18
The request method token is the primary source of request semantics; The request method token is the primary source of request semantics;
it indicates the purpose for which the client has made this request it indicates the purpose for which the client has made this request
and what is expected by the client as a successful result. and what is expected by the client as a successful result.
The request method's semantics might be further specialized by the The request method's semantics might be further specialized by the
semantics of some header fields when present in a request (Section 5) semantics of some header fields when present in a request (Section 5)
if those additional semantics do not conflict with the method. For if those additional semantics do not conflict with the method. For
example, a client can send conditional request header fields example, a client can send conditional request header fields
(Section 5.2) to make the requested action conditional on the current (Section 5.2) to make the requested action conditional on the current
state of the target resource ([Part4]). state of the target resource ([RFC7232]).
method = token method = token
HTTP was originally designed to be usable as an interface to HTTP was originally designed to be usable as an interface to
distributed object systems. The request method was envisioned as distributed object systems. The request method was envisioned as
applying semantics to a target resource in much the same way as applying semantics to a target resource in much the same way as
invoking a defined method on an identified object would apply invoking a defined method on an identified object would apply
semantics. The method token is case-sensitive because it might be semantics. The method token is case-sensitive because it might be
used as a gateway to object-based systems with case-sensitive method used as a gateway to object-based systems with case-sensitive method
names. names.
Unlike distributed objects, the standardized request methods in HTTP Unlike distributed objects, the standardized request methods in HTTP
are not resource-specific, since uniform interfaces provide for are not resource-specific, since uniform interfaces provide for
better visibility and reuse in network-based systems [REST]. Once better visibility and reuse in network-based systems [REST]. Once
defined, a standardized method ought to have the same semantics when defined, a standardized method ought to have the same semantics when
applied to any resource, though each resource determines for itself applied to any resource, though each resource determines for itself
whether those semantics are implemented or allowed. whether those semantics are implemented or allowed.
This specification defines a number of standardized methods that are This specification defines a number of standardized methods that are
commonly used in HTTP, as outlined by the following table. By commonly used in HTTP, as outlined by the following table. By
convention, standardized methods are defined in all-uppercase ASCII convention, standardized methods are defined in all-uppercase US-
letters. ASCII letters.
+---------+-------------------------------------------------+-------+ +---------+-------------------------------------------------+-------+
| Method | Description | Sec. | | Method | Description | Sec. |
+---------+-------------------------------------------------+-------+ +---------+-------------------------------------------------+-------+
| GET | Transfer a current representation of the target | 4.3.1 | | GET | Transfer a current representation of the target | 4.3.1 |
| | resource. | | | | resource. | |
| HEAD | Same as GET, but only transfer the status line | 4.3.2 | | HEAD | Same as GET, but only transfer the status line | 4.3.2 |
| | and header section. | | | | and header section. | |
| POST | Perform resource-specific processing on the | 4.3.3 | | POST | Perform resource-specific processing on the | 4.3.3 |
| | request payload. | | | | request payload. | |
skipping to change at page 22, line 31 skipping to change at page 22, line 31
| | target resource. | | | | target resource. | |
| TRACE | Perform a message loop-back test along the path | 4.3.8 | | TRACE | Perform a message loop-back test along the path | 4.3.8 |
| | to the target resource. | | | | to the target resource. | |
+---------+-------------------------------------------------+-------+ +---------+-------------------------------------------------+-------+
All general-purpose servers MUST support the methods GET and HEAD. All general-purpose servers MUST support the methods GET and HEAD.
All other methods are OPTIONAL. All other methods are OPTIONAL.
Additional methods, outside the scope of this specification, have Additional methods, outside the scope of this specification, have
been standardized for use in HTTP. All such methods ought to be been standardized for use in HTTP. All such methods ought to be
registered within the HTTP Method Registry maintained by IANA, as registered within the "Hypertext Transfer Protocol (HTTP) Method
defined in Section 8.1. Registry" maintained by IANA, as defined in Section 8.1.
The set of methods allowed by a target resource can be listed in an The set of methods allowed by a target resource can be listed in an
Allow header field (Section 7.4.1). However, the set of allowed Allow header field (Section 7.4.1). However, the set of allowed
methods can change dynamically. When a request method is received methods can change dynamically. When a request method is received
that is unrecognized or not implemented by an origin server, the that is unrecognized or not implemented by an origin server, the
origin server SHOULD respond with the 501 (Not Implemented) status origin server SHOULD respond with the 501 (Not Implemented) status
code. When a request method is received that is known by an origin code. When a request method is received that is known by an origin
server but not allowed for the target resource, the origin server server but not allowed for the target resource, the origin server
SHOULD respond with the 405 (Method Not Allowed) status code. SHOULD respond with the 405 (Method Not Allowed) status code.
skipping to change at page 23, line 6 skipping to change at page 23, line 6
4.2.1. Safe Methods 4.2.1. Safe Methods
Request methods are considered ""safe"" if their defined semantics Request methods are considered ""safe"" if their defined semantics
are essentially read-only; i.e., the client does not request, and are essentially read-only; i.e., the client does not request, and
does not expect, any state change on the origin server as a result of does not expect, any state change on the origin server as a result of
applying a safe method to a target resource. Likewise, reasonable applying a safe method to a target resource. Likewise, reasonable
use of a safe method is not expected to cause any harm, loss of use of a safe method is not expected to cause any harm, loss of
property, or unusual burden on the origin server. property, or unusual burden on the origin server.
This definition of safe methods does not prevent an implementation This definition of safe methods does not prevent an implementation
from including behavior that is potentially harmful, not entirely from including behavior that is potentially harmful, that is not
read-only, or which causes side-effects while invoking a safe method. entirely read-only, or that causes side effects while invoking a safe
What is important, however, is that the client did not request that method. What is important, however, is that the client did not
additional behavior and cannot be held accountable for it. For request that additional behavior and cannot be held accountable for
example, most servers append request information to access log files it. For example, most servers append request information to access
at the completion of every response, regardless of the method, and log files at the completion of every response, regardless of the
that is considered safe even though the log storage might become full method, and that is considered safe even though the log storage might
and crash the server. Likewise, a safe request initiated by become full and crash the server. Likewise, a safe request initiated
selecting an advertisement on the Web will often have the side-effect by selecting an advertisement on the Web will often have the side
of charging an advertising account. effect of charging an advertising account.
Of the request methods defined by this specification, the GET, HEAD, Of the request methods defined by this specification, the GET, HEAD,
OPTIONS, and TRACE methods are defined to be safe. OPTIONS, and TRACE methods are defined to be safe.
The purpose of distinguishing between safe and unsafe methods is to The purpose of distinguishing between safe and unsafe methods is to
allow automated retrieval processes (spiders) and cache performance allow automated retrieval processes (spiders) and cache performance
optimization (pre-fetching) to work without fear of causing harm. In optimization (pre-fetching) to work without fear of causing harm. In
addition, it allows a user agent to apply appropriate constraints on addition, it allows a user agent to apply appropriate constraints on
the automated use of unsafe methods when processing potentially the automated use of unsafe methods when processing potentially
untrusted content. untrusted content.
skipping to change at page 23, line 39 skipping to change at page 23, line 39
made aware of an unsafe action before it is requested. made aware of an unsafe action before it is requested.
When a resource is constructed such that parameters within the When a resource is constructed such that parameters within the
effective request URI have the effect of selecting an action, it is effective request URI have the effect of selecting an action, it is
the resource owner's responsibility to ensure that the action is the resource owner's responsibility to ensure that the action is
consistent with the request method semantics. For example, it is consistent with the request method semantics. For example, it is
common for Web-based content editing software to use actions within common for Web-based content editing software to use actions within
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
A request method is considered ""idempotent"" if the intended effect A request method is considered ""idempotent"" if the intended effect
on the server of multiple identical requests with that method is the on the server of multiple identical requests with that method is the
same as the effect for a single such request. Of the request methods same as the effect for a single such request. Of the request methods
defined by this specification, PUT, DELETE, and safe request methods defined by this specification, PUT, DELETE, and safe request methods
are idempotent. 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 the client can establish a new before any response is received, then the client can establish a new
connection and retry the idempotent request. It knows that repeating connection and retry the idempotent request. It knows that repeating
the request will have the same intended effect, even if the original the request will have the same intended effect, even if the original
request succeeded, though the response might differ. request succeeded, though the response might differ.
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 [RFC7234]. In general, safe methods that
not depend on a current or authoritative response are defined as do 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.
4.3. Method Definitions 4.3. Method Definitions
4.3.1. GET 4.3.1. GET
The GET method requests transfer of a current selected representation The GET method requests transfer of a current selected representation
for the target resource. GET is the primary mechanism of information for the target resource. GET is the primary mechanism of information
retrieval and the focus of almost all performance optimizations. retrieval and the focus of almost all performance optimizations.
Hence, when people speak of retrieving some identifiable information Hence, when people speak of retrieving some identifiable information
via HTTP, they are generally referring to making a GET request. via HTTP, they are generally referring to making a GET request.
It is tempting to think of resource identifiers as remote file system It is tempting to think of resource identifiers as remote file system
pathnames, and of representations as being a copy of the contents of pathnames and of representations as being a copy of the contents of
such files. In fact, that is how many resources are implemented (see such files. In fact, that is how many resources are implemented (see
Section 9.1 for related security considerations). However, there are Section 9.1 for related security considerations). However, there are
no such limitations in practice. The HTTP interface for a resource no such limitations in practice. The HTTP interface for a resource
is just as likely to be implemented as a tree of content objects, a is just as likely to be implemented as a tree of content objects, a
programmatic view on various database records, or a gateway to other programmatic view on various database records, or a gateway to other
information systems. Even when the URI mapping mechanism is tied to information systems. Even when the URI mapping mechanism is tied to
a file system, an origin server might be configured to execute the a file system, an origin server might be configured to execute the
files with the request as input and send the output as the files with the request as input and send the output as the
representation, rather than transfer the files directly. Regardless, representation rather than transfer the files directly. Regardless,
only the origin server needs to know how each of its resource only the origin server needs to know how each of its resource
identifiers corresponds to an implementation, and how each identifiers corresponds to an implementation and how each
implementation manages to select and send a current representation of implementation manages to select and send a current representation of
the target resource in a response to GET. the target resource in a response to GET.
A client can alter the semantics of GET to be a "range request", A client can alter the semantics of GET to be a "range request",
requesting transfer of only some part(s) of the selected requesting transfer of only some part(s) of the selected
representation, by sending a Range header field in the request representation, by sending a Range header field in the request
([Part5]). ([RFC7233]).
A payload within a GET request message has no defined semantics; A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing sending a payload body on a GET request might cause some existing
implementations to reject the request. implementations to reject the request.
The response to a GET request is cacheable; a cache MAY use it to The response to a GET request is cacheable; a cache MAY use it to
satisfy subsequent GET and HEAD requests unless otherwise indicated satisfy subsequent GET and HEAD requests unless otherwise indicated
by the Cache-Control header field (Section 5.2 of [Part6]). by the Cache-Control header field (Section 5.2 of [RFC7234]).
4.3.2. HEAD 4.3.2. HEAD
The HEAD method is identical to GET except that the server MUST NOT The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at send a message body in the response (i.e., the response terminates at
the end of the header section). The server SHOULD send the same the end of the header section). The server SHOULD send the same
header fields in response to a HEAD request as it would have sent if header fields in response to a HEAD request as it would have sent if
the request had been a GET, except that the payload header fields the request had been a GET, except that the payload header fields
(Section 3.3) MAY be omitted. This method can be used for obtaining (Section 3.3) MAY be omitted. This method can be used for obtaining
metadata about the selected representation without transferring the metadata about the selected representation without transferring the
representation data and is often used for testing hypertext links for representation data and is often used for testing hypertext links for
validity, accessibility, and recent modification. validity, accessibility, and recent modification.
A payload within a HEAD request message has no defined semantics; A payload within a HEAD request message has no defined semantics;
sending a payload body on a HEAD request might cause some existing sending a payload body on a HEAD request might cause some existing
implementations to reject the request. implementations to reject the request.
The response to a HEAD request is cacheable; a cache MAY use it to The response to a HEAD request is cacheable; a cache MAY use it to
satisfy subsequent HEAD requests unless otherwise indicated by the satisfy subsequent HEAD requests unless otherwise indicated by the
Cache-Control header field (Section 5.2 of [Part6]). A HEAD response Cache-Control header field (Section 5.2 of [RFC7234]). A HEAD
might also have an effect on previously cached responses to GET; see response might also have an effect on previously cached responses to
Section 4.3.5 of [Part6]. GET; see Section 4.3.5 of [RFC7234].
4.3.3. POST 4.3.3. POST
The POST method requests that the target resource process the The POST method requests that the target resource process the
representation enclosed in the request according to the resource's representation enclosed in the request according to the resource's
own specific semantics. For example, POST is used for the following own specific semantics. For example, POST is used for the following
functions (among others): functions (among others):
o Providing a block of data, such as the fields entered into an HTML o Providing a block of data, such as the fields entered into an HTML
form, to a data-handling process; form, to a data-handling process;
skipping to change at page 26, line 14 skipping to change at page 26, line 14
o Creating a new resource that has yet to be identified by the o Creating a new resource that has yet to be identified by the
origin server; and origin server; and
o Appending data to a resource's existing representation(s). o Appending data to a resource's existing representation(s).
An origin server indicates response semantics by choosing an An origin server indicates response semantics by choosing an
appropriate status code depending on the result of processing the appropriate status code depending on the result of processing the
POST request; almost all of the status codes defined by this POST request; almost all of the status codes defined by this
specification might be received in a response to POST (the exceptions specification might be received in a response to POST (the exceptions
being 206, 304, and 416). being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
Satisfiable)).
If one or more resources has been created on the origin server as a If one or more resources has been created on the origin server as a
result of successfully processing a POST request, the origin server result of successfully processing a POST request, the origin server
SHOULD send a 201 (Created) response containing a Location header SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created field that provides an identifier for the primary resource created
(Section 7.1.2) and a representation that describes the status of the (Section 7.1.2) and a representation that describes the status of the
request while referring to the new resource(s). request while referring to the new resource(s).
Responses to POST requests are only cacheable when they include Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 4.2.1 of [Part6]). explicit freshness information (see Section 4.2.1 of [RFC7234]).
However, POST caching is not widely implemented. For cases where an However, POST caching is not widely implemented. For cases where an
origin server wishes the client to be able to cache the result of a origin server wishes the client to be able to cache the result of a
POST in a way that can be reused by a later GET, the origin server POST in a way that can be reused by a later GET, the origin server
MAY send a 200 (OK) response containing the result and a Content- MAY send a 200 (OK) response containing the result and a Content-
Location header field that has the same value as the POST's effective Location header field that has the same value as the POST's effective
request URI (Section 3.1.4.2). request URI (Section 3.1.4.2).
If the result of processing a POST would be equivalent to a If the result of processing a POST would be equivalent to a
representation of an existing resource, an origin server MAY redirect representation of an existing resource, an origin server MAY redirect
the user agent to that resource by sending a 303 (See Other) response the user agent to that resource by sending a 303 (See Other) response
skipping to change at page 28, line 18 skipping to change at page 28, line 19
intentionally hidden by the server. intentionally hidden by the server.
An origin server MUST NOT send a validator header field An origin server MUST NOT send a validator header field
(Section 7.2), such as an ETag or Last-Modified field, in a (Section 7.2), such as an ETag or Last-Modified field, in a
successful response to PUT unless the request's representation data successful response to PUT unless the request's representation data
was saved without any transformation applied to the body (i.e., the was saved without any transformation applied to the body (i.e., the
resource's new representation data is identical to the representation resource's new representation data is identical to the representation
data received in the PUT request) and the validator field value data received in the PUT request) and the validator field value
reflects the new representation. This requirement allows a user reflects the new representation. This requirement allows a user
agent to know when the representation body it has in memory remains agent to know when the representation body it has in memory remains
current as a result of the PUT, thus not in need of retrieving again current as a result of the PUT, thus not in need of being retrieved
from the origin server, and that the new validator(s) received in the again from the origin server, and that the new validator(s) received
response can be used for future conditional requests in order to in the response can be used for future conditional requests in order
prevent accidental overwrites (Section 5.2). to prevent accidental overwrites (Section 5.2).
The fundamental difference between the POST and PUT methods is The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation. highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics, enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server. effect is only known by the origin server.
skipping to change at page 28, line 43 skipping to change at page 28, line 44
knows which target resource is desired. A service that selects a knows which target resource is desired. A service that selects a
proper URI on behalf of the client, after receiving a state-changing proper URI on behalf of the client, after receiving a state-changing
request, SHOULD be implemented using the POST method rather than PUT. request, SHOULD be implemented using the POST method rather than PUT.
If the origin server will not make the requested PUT state change to If the origin server will not make the requested PUT state change to
the target resource and instead wishes to have it applied to a the target resource and instead wishes to have it applied to a
different resource, such as when the resource has been moved to a different resource, such as when the resource has been moved to a
different URI, then the origin server MUST send an appropriate 3xx different URI, then the origin server MUST send an appropriate 3xx
(Redirection) response; the user agent MAY then make its own decision (Redirection) response; the user agent MAY then make its own decision
regarding whether or not to redirect the request. regarding whether or not to redirect the request.
A PUT request applied to the target resource can have side-effects on A PUT request applied to the target resource can have side effects on
other resources. For example, an article might have a URI for other resources. For example, an article might have a URI for
identifying "the current version" (a resource) that is separate from identifying "the current version" (a resource) that is separate from
the URIs identifying each particular version (different resources the URIs identifying each particular version (different resources
that at one point shared the same state as the current version that at one point shared the same state as the current version
resource). A successful PUT request on "the current version" URI resource). A successful PUT request on "the current version" URI
might therefore create a new version resource in addition to changing might therefore create a new version resource in addition to changing
the state of the target resource, and might also cause links to be the state of the target resource, and might also cause links to be
added between the related resources. added between the related resources.
An origin server that allows PUT on a given target resource MUST send An origin server that allows PUT on a given target resource MUST send
a 400 (Bad Request) response to a PUT request that contains a a 400 (Bad Request) response to a PUT request that contains a
Content-Range header field (Section 4.2 of [Part5]), since the Content-Range header field (Section 4.2 of [RFC7233]), since the
payload is likely to be partial content that has been mistakenly PUT payload is likely to be partial content that has been mistakenly PUT
as a full representation. Partial content updates are possible by as a full representation. Partial content updates are possible by
targeting a separately identified resource with state that overlaps a targeting a separately identified resource with state that overlaps a
portion of the larger resource, or by using a different method that portion of the larger resource, or by using a different method that
has been specifically defined for partial updates (for example, the has been specifically defined for partial updates (for example, the
PATCH method defined in [RFC5789]). PATCH method defined in [RFC5789]).
Responses to the PUT method are not cacheable. If a successful PUT Responses to the PUT method are not cacheable. If a successful PUT
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the effective request URI, those stored responses will be for the effective request URI, those stored responses will be
invalidated (see Section 4.4 of [Part6]). invalidated (see Section 4.4 of [RFC7234]).
4.3.5. DELETE 4.3.5. DELETE
The DELETE method requests that the origin server remove the The DELETE method requests that the origin server remove the
association between the target resource and its current association between the target resource and its current
functionality. In effect, this method is similar to the rm command functionality. In effect, this method is similar to the rm command
in UNIX: it expresses a deletion operation on the URI mapping of the in UNIX: it expresses a deletion operation on the URI mapping of the
origin server, rather than an expectation that the previously origin server rather than an expectation that the previously
associated information be deleted. associated information be deleted.
If the target resource has one or more current representations, they If the target resource has one or more current representations, they
might or might not be destroyed by the origin server, and the might or might not be destroyed by the origin server, and the
associated storage might or might not be reclaimed, depending associated storage might or might not be reclaimed, depending
entirely on the nature of the resource and its implementation by the entirely on the nature of the resource and its implementation by the
origin server (which are beyond the scope of this specification). origin server (which are beyond the scope of this specification).
Likewise, other implementation aspects of a resource might need to be Likewise, other implementation aspects of a resource might need to be
deactivated or archived as a result of a DELETE, such as database or deactivated or archived as a result of a DELETE, such as database or
gateway connections. In general, it is assumed that the origin gateway connections. In general, it is assumed that the origin
skipping to change at page 30, line 17 skipping to change at page 30, line 19
or a 200 (OK) status code if the action has been enacted and the or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status. response message includes a representation describing the status.
A payload within a DELETE request message has no defined semantics; A payload within a DELETE request message has no defined semantics;
sending a payload body on a DELETE request might cause some existing sending a payload body on a DELETE request might cause some existing
implementations to reject the request. implementations to reject the request.
Responses to the DELETE method are not cacheable. If a DELETE Responses to the DELETE method are not cacheable. If a DELETE
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the effective request URI, those stored responses will be for the effective request URI, those stored responses will be
invalidated (see Section 4.4 of [Part6]). invalidated (see Section 4.4 of [RFC7234]).
4.3.6. CONNECT 4.3.6. CONNECT
The CONNECT method requests that the recipient establish a tunnel to The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target and, the destination origin server identified by the request-target and,
if successful, thereafter restrict its behavior to blind forwarding if successful, thereafter restrict its behavior to blind forwarding
of packets, in both directions, until the tunnel is closed. Tunnels of packets, in both directions, until the tunnel is closed. Tunnels
are commonly used to create an end-to-end virtual connection, through are commonly used to create an end-to-end virtual connection, through
one or more proxies, which can then be secured using TLS (Transport one or more proxies, which can then be secured using TLS (Transport
Layer Security, [RFC5246]). Layer Security, [RFC5246]).
CONNECT is intended only for use in requests to a proxy. An origin CONNECT is intended only for use in requests to a proxy. An origin
server that receives a CONNECT request for itself MAY respond with a server that receives a CONNECT request for itself MAY respond with a
2xx status code to indicate that a connection is established. 2xx (Successful) status code to indicate that a connection is
However, most origin servers do not implement CONNECT. established. However, most origin servers do not implement CONNECT.
A client sending a CONNECT request MUST send the authority form of A client sending a CONNECT request MUST send the authority form of
request-target (Section 5.3 of [Part1]); i.e., the request-target request-target (Section 5.3 of [RFC7230]); i.e., the request-target
consists of only the host name and port number of the tunnel consists of only the host name and port number of the tunnel
destination, separated by a colon. For example, destination, separated by a colon. For example,
CONNECT server.example.com:80 HTTP/1.1 CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80 Host: server.example.com:80
The recipient proxy can establish a tunnel either by directly The recipient proxy can establish a tunnel either by directly
connecting to the request-target or, if configured to use another connecting to the request-target or, if configured to use another
proxy, by forwarding the CONNECT request to the next inbound proxy. proxy, by forwarding the CONNECT request to the next inbound proxy.
Any 2xx (Successful) response indicates that the sender (and all Any 2xx (Successful) response indicates that the sender (and all
skipping to change at page 31, line 42 skipping to change at page 31, line 43
A payload within a CONNECT request message has no defined semantics; A payload within a CONNECT request message has no defined semantics;
sending a payload body on a CONNECT request might cause some existing sending a payload body on a CONNECT request might cause some existing
implementations to reject the request. implementations to reject the request.
Responses to the CONNECT method are not cacheable. Responses to the CONNECT method are not cacheable.
4.3.7. OPTIONS 4.3.7. OPTIONS
The OPTIONS method requests information about the communication The OPTIONS method requests information about the communication
options available for the target resource, either at the origin options available for the target resource, at either the origin
server or an intervening intermediary. This method allows a client server or an intervening intermediary. This method allows a client
to determine the options and/or requirements associated with a to determine the options and/or requirements associated with a
resource, or the capabilities of a server, without implying a resource, or the capabilities of a server, without implying a
resource action. resource action.
An OPTIONS request with an asterisk ("*") as the request-target An OPTIONS request with an asterisk ("*") as the request-target
(Section 5.3 of [Part1]) applies to the server in general rather than (Section 5.3 of [RFC7230]) applies to the server in general rather
to a specific resource. Since a server's communication options than to a specific resource. Since a server's communication options
typically depend on the resource, the "*" request is only useful as a typically depend on the resource, the "*" request is only useful as a
"ping" or "no-op" type of method; it does nothing beyond allowing the "ping" or "no-op" type of method; it does nothing beyond allowing the
client to test the capabilities of the server. For example, this can client to test the capabilities of the server. For example, this can
be used to test a proxy for HTTP/1.1 conformance (or lack thereof). be used to test a proxy for HTTP/1.1 conformance (or lack thereof).
If the request-target is not an asterisk, the OPTIONS request applies If the request-target is not an asterisk, the OPTIONS request applies
to the options that are available when communicating with the target to the options that are available when communicating with the target
resource. resource.
A server generating a successful response to OPTIONS SHOULD send any A server generating a successful response to OPTIONS SHOULD send any
skipping to change at page 32, line 45 skipping to change at page 32, line 46
resource. resource.
Responses to the OPTIONS method are not cacheable. Responses to the OPTIONS method are not cacheable.
4.3.8. TRACE 4.3.8. TRACE
The TRACE method requests a remote, application-level loop-back of The TRACE method requests a remote, application-level loop-back of
the request message. The final recipient of the request SHOULD the request message. The final recipient of the request SHOULD
reflect the message received, excluding some fields described below, reflect the message received, excluding some fields described below,
back to the client as the message body of a 200 (OK) response with a back to the client as the message body of a 200 (OK) response with a
Content-Type of "message/http" (Section 8.3.1 of [Part1]). The final Content-Type of "message/http" (Section 8.3.1 of [RFC7230]). The
recipient is either the origin server or the first server to receive final recipient is either the origin server or the first server to
a Max-Forwards value of zero (0) in the request (Section 5.1.2). receive a Max-Forwards value of zero (0) in the request
(Section 5.1.2).
A client MUST NOT generate header fields in a TRACE request A client MUST NOT generate header fields in a TRACE request
containing sensitive data that might be disclosed by the response. containing sensitive data that might be disclosed by the response.
For example, it would be foolish for a user agent to send stored user For example, it would be foolish for a user agent to send stored user
credentials [Part7] or cookies [RFC6265] in a TRACE request. The credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The
final recipient of the request SHOULD exclude any request header final recipient of the request SHOULD exclude any request header
fields that are likely to contain sensitive data when that recipient fields that are likely to contain sensitive data when that recipient
generates the response body. generates the response body.
TRACE allows the client to see what is being received at the other TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (Section 5.7.1 of information. The value of the Via header field (Section 5.7.1 of
[Part1]) is of particular interest, since it acts as a trace of the [RFC7230]) is of particular interest, since it acts as a trace of the
request chain. Use of the Max-Forwards header field allows the request chain. Use of the Max-Forwards header field allows the
client to limit the length of the request chain, which is useful for client to limit the length of the request chain, which is useful for
testing a chain of proxies forwarding messages in an infinite loop. testing a chain of proxies forwarding messages in an infinite loop.
A client MUST NOT send a message body in a TRACE request. A client MUST NOT send a message body in a TRACE request.
Responses to the TRACE method are not cacheable. Responses to the TRACE method are not cacheable.
5. Request Header Fields 5. Request Header Fields
skipping to change at page 33, line 35 skipping to change at page 33, line 37
target resource state, suggest preferred formats for the response, target resource state, suggest preferred formats for the response,
supply authentication credentials, or modify the expected request supply authentication credentials, or modify the expected request
processing. These fields act as request modifiers, similar to the processing. These fields act as request modifiers, similar to the
parameters on a programming language method invocation. parameters on a programming language method invocation.
5.1. Controls 5.1. Controls
Controls are request header fields that direct specific handling of Controls are request header fields that direct specific handling of
the request. the request.
+-------------------+------------------------+ +-------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+------------------------+ +-------------------+--------------------------+
| Cache-Control | Section 5.2 of [Part6] | | Cache-Control | Section 5.2 of [RFC7234] |
| Expect | Section 5.1.1 | | Expect | Section 5.1.1 |
| Host | Section 5.4 of [Part1] | | Host | Section 5.4 of [RFC7230] |
| Max-Forwards | Section 5.1.2 | | Max-Forwards | Section 5.1.2 |
| Pragma | Section 5.4 of [Part6] | | Pragma | Section 5.4 of [RFC7234] |
| Range | Section 3.1 of [Part5] | | Range | Section 3.1 of [RFC7233] |
| TE | Section 4.3 of [Part1] | | TE | Section 4.3 of [RFC7230] |
+-------------------+------------------------+ +-------------------+--------------------------+
5.1.1. Expect 5.1.1. Expect
The "Expect" header field in a request indicates a certain set of The "Expect" header field in a request indicates a certain set of
behaviors (expectations) that need to be supported by the server in behaviors (expectations) that need to be supported by the server in
order to properly handle this request. The only such expectation order to properly handle this request. The only such expectation
defined by this specification is 100-continue. defined by this specification is 100-continue.
Expect = "100-continue" Expect = "100-continue"
skipping to change at page 35, line 30 skipping to change at page 35, line 35
corresponding request, or if the framing indicates that there is corresponding request, or if the framing indicates that there is
no message body. no message body.
o A server that sends a 100 (Continue) response MUST ultimately send o A server that sends a 100 (Continue) response MUST ultimately send
a final status code, once the message body is received and a final status code, once the message body is received and
processed, unless the connection is closed prematurely. processed, unless the connection is closed prematurely.
o A server that responds with a final status code before reading the o A server that responds with a final status code before reading the
entire message body SHOULD indicate in that response whether it entire message body SHOULD indicate in that response whether it
intends to close the connection or continue reading and discarding intends to close the connection or continue reading and discarding
the request message (see Section 6.6 of [Part1]). the request message (see Section 6.6 of [RFC7230]).
An origin server MUST, upon receiving an HTTP/1.1 (or later) request- An origin server MUST, upon receiving an HTTP/1.1 (or later) request-
line and a complete header section that contains a 100-continue line and a complete header section that contains a 100-continue
expectation and indicates a request message body will follow, either expectation and indicates a request message body will follow, either
send an immediate response with a final status code, if that status send an immediate response with a final status code, if that status
can be determined by examining just the request-line and header can be determined by examining just the request-line and header
fields, or send an immediate 100 (Continue) response to encourage the fields, or send an immediate 100 (Continue) response to encourage the
client to send the request's message body. The origin server MUST client to send the request's message body. The origin server MUST
NOT wait for the message body before sending the 100 (Continue) NOT wait for the message body before sending the 100 (Continue)
response. response.
skipping to change at page 36, line 8 skipping to change at page 36, line 12
determined by examining just the request-line and header fields, or determined by examining just the request-line and header fields, or
begin forwarding the request toward the origin server by sending a begin forwarding the request toward the origin server by sending a
corresponding request-line and header section to the next inbound corresponding request-line and header section to the next inbound
server. If the proxy believes (from configuration or past server. If the proxy believes (from configuration or past
interaction) that the next inbound server only supports HTTP/1.0, the interaction) that the next inbound server only supports HTTP/1.0, the
proxy MAY generate an immediate 100 (Continue) response to encourage proxy MAY generate an immediate 100 (Continue) response to encourage
the client to begin sending the message body. the client to begin sending the message body.
Note: The Expect header field was added after the original Note: The Expect header field was added after the original
publication of HTTP/1.1 [RFC2068] as both the means to request an publication of HTTP/1.1 [RFC2068] as both the means to request an
interim 100 response and the general mechanism for indicating interim 100 (Continue) response and the general mechanism for
must-understand extensions. However, the extension mechanism has indicating must-understand extensions. However, the extension
not been used by clients and the must-understand requirements have mechanism has not been used by clients and the must-understand
not been implemented by many servers, rendering the extension requirements have not been implemented by many servers, rendering
mechanism useless. This specification has removed the extension the extension mechanism useless. This specification has removed
mechanism in order to simplify the definition and processing of the extension mechanism in order to simplify the definition and
100-continue. processing of 100-continue.
5.1.2. Max-Forwards 5.1.2. Max-Forwards
The "Max-Forwards" header field provides a mechanism with the TRACE The "Max-Forwards" header field provides a mechanism with the TRACE
(Section 4.3.8) and OPTIONS (Section 4.3.7) request methods to limit (Section 4.3.8) and OPTIONS (Section 4.3.7) request methods to limit
the number of times that the request is forwarded by proxies. This the number of times that the request is forwarded by proxies. This
can be useful when the client is attempting to trace a request that can be useful when the client is attempting to trace a request that
appears to be failing or looping mid-chain. appears to be failing or looping mid-chain.
Max-Forwards = 1*DIGIT Max-Forwards = 1*DIGIT
skipping to change at page 36, line 36 skipping to change at page 36, line 40
The Max-Forwards value is a decimal integer indicating the remaining The Max-Forwards value is a decimal integer indicating the remaining
number of times this request message can be forwarded. number of times this request message can be forwarded.
Each intermediary that receives a TRACE or OPTIONS request containing Each intermediary that receives a TRACE or OPTIONS request containing
a Max-Forwards header field MUST check and update its value prior to a Max-Forwards header field MUST check and update its value prior to
forwarding the request. If the received value is zero (0), the forwarding the request. If the received value is zero (0), the
intermediary MUST NOT forward the request; instead, the intermediary intermediary MUST NOT forward the request; instead, the intermediary
MUST respond as the final recipient. If the received Max-Forwards MUST respond as the final recipient. If the received Max-Forwards
value is greater than zero, the intermediary MUST generate an updated value is greater than zero, the intermediary MUST generate an updated
Max-Forwards field in the forwarded message with a field-value that Max-Forwards field in the forwarded message with a field-value that
is the lesser of: a) the received value decremented by one (1), or b) is the lesser of a) the received value decremented by one (1) or b)
the recipient's maximum supported value for Max-Forwards. the recipient's maximum supported value for Max-Forwards.
A recipient MAY ignore a Max-Forwards header field received with any A recipient MAY ignore a Max-Forwards header field received with any
other request methods. other request methods.
5.2. Conditionals 5.2. Conditionals
The HTTP conditional request header fields [Part4] allow a client to The HTTP conditional request header fields [RFC7232] allow a client
place a precondition on the state of the target resource, so that the to place a precondition on the state of the target resource, so that
action corresponding to the method semantics will not be applied if the action corresponding to the method semantics will not be applied
the precondition evaluates to false. Each precondition defined by if the precondition evaluates to false. Each precondition defined by
this specification consists of a comparison between a set of this specification consists of a comparison between a set of
validators obtained from prior representations of the target resource validators obtained from prior representations of the target resource
to the current state of validators for the selected representation to the current state of validators for the selected representation
(Section 7.2). Hence, these preconditions evaluate whether the state (Section 7.2). Hence, these preconditions evaluate whether the state
of the target resource has changed since a given state known by the of the target resource has changed since a given state known by the
client. The effect of such an evaluation depends on the method client. The effect of such an evaluation depends on the method
semantics and choice of conditional, as defined in Section 5 of semantics and choice of conditional, as defined in Section 5 of
[Part4]. [RFC7232].
+---------------------+------------------------+ +---------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+---------------------+------------------------+ +---------------------+--------------------------+
| If-Match | Section 3.1 of [Part4] | | If-Match | Section 3.1 of [RFC7232] |
| If-None-Match | Section 3.2 of [Part4] | | If-None-Match | Section 3.2 of [RFC7232] |
| If-Modified-Since | Section 3.3 of [Part4] | | If-Modified-Since | Section 3.3 of [RFC7232] |
| If-Unmodified-Since | Section 3.4 of [Part4] | | If-Unmodified-Since | Section 3.4 of [RFC7232] |
| If-Range | Section 3.2 of [Part5] | | If-Range | Section 3.2 of [RFC7233] |
+---------------------+------------------------+ +---------------------+--------------------------+
5.3. Content Negotiation 5.3. Content Negotiation
The following request header fields are sent by a user agent to The following request header fields are sent by a user agent to
engage in proactive negotiation of the response content, as defined engage in proactive negotiation of the response content, as defined
in Section 3.4.1. The preferences sent in these fields apply to any in Section 3.4.1. The preferences sent in these fields apply to any
content in the response, including representations of the target content in the response, including representations of the target
resource, representations of error or processing status, and resource, representations of error or processing status, and
potentially even the miscellaneous text strings that might appear potentially even the miscellaneous text strings that might appear
within the protocol. within the protocol.
skipping to change at page 39, line 4 skipping to change at page 39, line 8
Note: Use of the "q" parameter name to separate media type Note: Use of the "q" parameter name to separate media type
parameters from Accept extension parameters is due to historical parameters from Accept extension parameters is due to historical
practice. Although this prevents any media type parameter named practice. Although this prevents any media type parameter named
"q" from being used with a media range, such an event is believed "q" from being used with a media range, such an event is believed
to be unlikely given the lack of any "q" parameters in the IANA to be unlikely given the lack of any "q" parameters in the IANA
media type registry and the rare usage of any media type media type registry and the rare usage of any media type
parameters in Accept. Future media types are discouraged from parameters in Accept. Future media types are discouraged from
registering any parameter named "q". registering any parameter named "q".
The example The example
Accept: audio/*; q=0.2, audio/basic Accept: audio/*; q=0.2, audio/basic
is interpreted as "I prefer audio/basic, but send me any audio type is interpreted as "I prefer audio/basic, but send me any audio type
if it is the best available after an 80% mark-down in quality". if it is the best available after an 80% markdown in quality".
A request without any Accept header field implies that the user agent A request without any Accept header field implies that the user agent
will accept any media type in response. If the header field is will accept any media type in response. If the header field is
present in a request and none of the available representations for present in a request and none of the available representations for
the response have a media type that is listed as acceptable, the the response have a media type that is listed as acceptable, the
origin server can either honor the header field by sending a 406 (Not origin server can either honor the header field by sending a 406 (Not
Acceptable) response or disregard the header field by treating the Acceptable) response or disregard the header field by treating the
response as if it is not subject to content negotiation. response as if it is not subject to content negotiation.
A more elaborate example is A more elaborate example is
skipping to change at page 42, line 32 skipping to change at page 42, line 37
not work and are not permitted with x-gzip or x-compress. not work and are not permitted with x-gzip or x-compress.
5.3.5. Accept-Language 5.3.5. Accept-Language
The "Accept-Language" header field can be used by user agents to The "Accept-Language" header field can be used by user agents to
indicate the set of natural languages that are preferred in the indicate the set of natural languages that are preferred in the
response. Language tags are defined in Section 3.1.3.1. response. Language tags are defined in Section 3.1.3.1.
Accept-Language = 1#( language-range [ weight ] ) Accept-Language = 1#( language-range [ weight ] )
language-range = language-range =
<language-range, defined in [RFC4647], Section 2.1> <language-range, see [RFC4647], Section 2.1>
Each language-range can be given an associated quality value Each language-range can be given an associated quality value
representing an estimate of the user's preference for the languages representing an estimate of the user's preference for the languages
specified by that range, as defined in Section 5.3.1. For example, specified by that range, as defined in Section 5.3.1. For example,
Accept-Language: da, en-gb;q=0.8, en;q=0.7 Accept-Language: da, en-gb;q=0.8, en;q=0.7
would mean: "I prefer Danish, but will accept British English and would mean: "I prefer Danish, but will accept British English and
other types of English". other types of English".
A request without any Accept-Language header field implies that the A request without any Accept-Language header field implies that the
user agent will accept any language in response. If the header field user agent will accept any language in response. If the header field
is present in a request and none of the available representations for is present in a request and none of the available representations for
the response have a matching language tag, the origin server can the response have a matching language tag, the origin server can
either disregard the header field by treating the response as if it either disregard the header field by treating the response as if it
is not subject to content negotiation, or honor the header field by is not subject to content negotiation or honor the header field by
sending a 406 (Not Acceptable) response. However, the latter is not sending a 406 (Not Acceptable) response. However, the latter is not
encouraged, as doing so can prevent users from accessing content that encouraged, as doing so can prevent users from accessing content that
they might be able to use (with translation software, for example). they might be able to use (with translation software, for example).
Note that some recipients treat the order in which language tags are Note that some recipients treat the order in which language tags are
listed as an indication of descending priority, particularly for tags listed as an indication of descending priority, particularly for tags
that are assigned equal quality values (no value is the same as q=1). that are assigned equal quality values (no value is the same as q=1).
However, this behavior cannot be relied upon. For consistency and to However, this behavior cannot be relied upon. For consistency and to
maximize interoperability, many user agents assign each language tag maximize interoperability, many user agents assign each language tag
a unique quality value while also listing them in order of decreasing a unique quality value while also listing them in order of decreasing
skipping to change at page 43, line 26 skipping to change at page 43, line 30
scheme for their requirements. The "Basic Filtering" scheme scheme for their requirements. The "Basic Filtering" scheme
([RFC4647], Section 3.3.1) is identical to the matching scheme that ([RFC4647], Section 3.3.1) is identical to the matching scheme that
was previously defined for HTTP in Section 14.4 of [RFC2616]. was previously defined for HTTP in Section 14.4 of [RFC2616].
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header field with the complete linguistic an Accept-Language header field with the complete linguistic
preferences of the user in every request (Section 9.7). preferences of the user in every request (Section 9.7).
Since intelligibility is highly dependent on the individual user, Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic preference user agents need to allow user control over the linguistic preference
(either through configuration of the user agent itself, or by (either through configuration of the user agent itself or by
defaulting to a user controllable system setting). A user agent that defaulting to a user controllable system setting). A user agent that
does not provide such control to the user MUST NOT send an Accept- does not provide such control to the user MUST NOT send an Accept-
Language header field. Language header field.
Note: User agents ought to provide guidance to users when setting Note: User agents ought to provide guidance to users when setting
a preference, since users are rarely familiar with the details of a preference, since users are rarely familiar with the details of
language matching as described above. For example, users might language matching as described above. For example, users might
assume that on selecting "en-gb", they will be served any kind of assume that on selecting "en-gb", they will be served any kind of
English document if British English is not available. A user English document if British English is not available. A user
agent might suggest, in such a case, to add "en" to the list for agent might suggest, in such a case, to add "en" to the list for
better matching behavior. better matching behavior.
5.4. Authentication Credentials 5.4. Authentication Credentials
Two header fields are used for carrying authentication credentials, Two header fields are used for carrying authentication credentials,
as defined in [Part7]. Note that various custom mechanisms for user as defined in [RFC7235]. Note that various custom mechanisms for
authentication use the Cookie header field for this purpose, as user authentication use the Cookie header field for this purpose, as
defined in [RFC6265]. defined in [RFC6265].
+---------------------+------------------------+ +---------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+---------------------+------------------------+ +---------------------+--------------------------+
| Authorization | Section 4.2 of [Part7] | | Authorization | Section 4.2 of [RFC7235] |
| Proxy-Authorization | Section 4.4 of [Part7] | | Proxy-Authorization | Section 4.4 of [RFC7235] |
+---------------------+------------------------+ +---------------------+--------------------------+
5.5. Request Context 5.5. Request Context
The following request header fields provide additional information The following request header fields provide additional information
about the request context, including information about the user, user about the request context, including information about the user, user
agent, and resource behind the request. agent, and resource behind the request.
+-------------------+---------------+ +-------------------+---------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+---------------+ +-------------------+---------------+
skipping to change at page 44, line 28 skipping to change at page 44, line 35
5.5.1. From 5.5.1. From
The "From" header field contains an Internet email address for a The "From" header field contains an Internet email address for a
human user who controls the requesting user agent. The address ought human user who controls the requesting user agent. The address ought
to be machine-usable, as defined by "mailbox" in Section 3.4 of to be machine-usable, as defined by "mailbox" in Section 3.4 of
[RFC5322]: [RFC5322]:
From = mailbox From = mailbox
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
An example is: An example is:
From: webmaster@example.org From: webmaster@example.org
The From header field is rarely sent by non-robotic user agents. A The From header field is rarely sent by non-robotic user agents. A
user agent SHOULD NOT send a From header field without explicit user agent SHOULD NOT send a From header field without explicit
configuration by the user, since that might conflict with the user's configuration by the user, since that might conflict with the user's
privacy interests or their site's security policy. privacy interests or their site's security policy.
skipping to change at page 45, line 24 skipping to change at page 45, line 31
denying links from other sites (so-called "deep linking") or denying links from other sites (so-called "deep linking") or
restricting cross-site request forgery (CSRF), but not all requests restricting cross-site request forgery (CSRF), but not all requests
contain it. 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 the
Referer or send it with a value of "about:blank". Referer field or send it with a value of "about:blank".
The Referer field has the potential to reveal information about the The Referer field has the potential to reveal information about the
request context or browsing history of the user, which is a privacy request context or browsing history of the user, which is a privacy
concern if the referring resource's identifier reveals personal concern if the referring resource's identifier reveals personal
information (such as an account name) or a resource that is supposed information (such as an account name) or a resource that is supposed
to be confidential (such as behind a firewall or internal to a to be confidential (such as behind a firewall or internal to a
secured service). Most general-purpose user agents do not send the secured service). Most general-purpose user agents do not send the
Referer header field when the referring resource is a local "file" or Referer header field when the referring resource is a local "file" or
"data" URI. A user agent MUST NOT send a Referer header field in an "data" URI. A user agent MUST NOT send a Referer header field in an
unsecured HTTP request if the referring page was received with a unsecured HTTP request if the referring page was received with a
secure protocol. See Section 9.4 for additional security secure protocol. See Section 9.4 for additional security
considerations. considerations.
Some intermediaries have been known to indiscriminately remove Some intermediaries have been known to indiscriminately remove
Referer header fields from outgoing requests. This has the Referer header fields from outgoing requests. This has the
unfortunate side-effect of interfering with protection against CSRF unfortunate side effect of interfering with protection against CSRF
attacks, which can be far more harmful to their users. attacks, which can be far more harmful to their users.
Intermediaries and user agent extensions that wish to limit Intermediaries and user agent extensions that wish to limit
information disclosure in Referer ought to restrict their changes to information disclosure in Referer ought to restrict their changes to
specific edits, such as replacing internal domain names with specific edits, such as replacing internal domain names with
pseudonyms or truncating the query and/or path components. An pseudonyms or truncating the query and/or path components. An
intermediary SHOULD NOT modify or delete the Referer header field intermediary SHOULD NOT modify or delete the Referer header field
when the field value shares the same scheme and host as the request when the field value shares the same scheme and host as the request
target. target.
5.5.3. User-Agent 5.5.3. User-Agent
skipping to change at page 46, line 19 skipping to change at page 46, line 24
identify the scope of reported interoperability problems, to work identify the scope of reported interoperability problems, to work
around or tailor responses to avoid particular user agent around or tailor responses to avoid particular user agent
limitations, and for analytics regarding browser or operating system limitations, and for analytics regarding browser or operating system
use. A user agent SHOULD send a User-Agent field in each request use. A user agent SHOULD send a User-Agent field in each request
unless specifically configured not to do so. unless specifically configured not to do so.
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
The User-Agent field-value consists of one or more product The User-Agent field-value consists of one or more product
identifiers, each followed by zero or more comments (Section 3.2 of identifiers, each followed by zero or more comments (Section 3.2 of
[Part1]), which together identify the user agent software and its [RFC7230]), which together identify the user agent software and its
significant subproducts. By convention, the product identifiers are significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the listed in decreasing order of their significance for identifying the
user agent software. Each product identifier consists of a name and user agent software. Each product identifier consists of a name and
optional version. optional version.
product = token ["/" product-version] product = token ["/" product-version]
product-version = token product-version = token
A sender SHOULD limit generated product identifiers to what is A sender SHOULD limit generated product identifiers to what is
necessary to identify the product; a sender MUST NOT generate necessary to identify the product; a sender MUST NOT generate
advertising or other non-essential information within the product advertising or other nonessential information within the product
identifier. A sender SHOULD NOT generate information in product- identifier. A sender SHOULD NOT generate information in product-
version that is not a version identifier (i.e., successive versions version that is not a version identifier (i.e., successive versions
of the same product name ought to only differ in the product-version of the same product name ought to differ only in the product-version
portion of the product identifier). portion of the product identifier).
Example: Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
A user agent SHOULD NOT generate a User-Agent field containing A user agent SHOULD NOT generate a User-Agent field containing
needlessly fine-grained detail and SHOULD limit the addition of needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed User-Agent subproducts by third parties. Overly long and detailed User-Agent
field values increase request latency and the risk of a user being field values increase request latency and the risk of a user being
skipping to change at page 47, line 7 skipping to change at page 47, line 13
Likewise, implementations are encouraged not to use the product Likewise, implementations are encouraged not to use the product
tokens of other implementations in order to declare compatibility tokens of other implementations in order to declare compatibility
with them, as this circumvents the purpose of the field. If a user with them, as this circumvents the purpose of the field. If a user
agent masquerades as a different user agent, recipients can assume agent masquerades as a different user agent, recipients can assume
that the user intentionally desires to see responses tailored for that the user intentionally desires to see responses tailored for
that identified user agent, even if they might not work as well for that identified user agent, even if they might not work as well for
the actual user agent being used. the actual user agent being used.
6. Response Status Codes 6. Response Status Codes
The status-code element is a 3-digit integer code giving the result The status-code element is a three-digit integer code giving the
of the attempt to understand and satisfy the request. result of the attempt to understand and satisfy the request.
HTTP status codes are extensible. HTTP clients are not required to HTTP status codes are extensible. HTTP clients are not required to
understand the meaning of all registered status codes, though such understand the meaning of all registered status codes, though such
understanding is obviously desirable. However, a client MUST understanding is obviously desirable. However, a client MUST
understand the class of any status code, as indicated by the first understand the class of any status code, as indicated by the first
digit, and treat an unrecognized status code as being equivalent to digit, and treat an unrecognized status code as being equivalent to
the x00 status code of that class, with the exception that a the x00 status code of that class, with the exception that a
recipient MUST NOT cache a response with an unrecognized status code. recipient MUST NOT cache a response with an unrecognized status code.
For example, if an unrecognized status code of 471 is received by a For example, if an unrecognized status code of 471 is received by a
client, the client can assume that there was something wrong with its client, the client can assume that there was something wrong with its
request and treat the response as if it had received a 400 status request and treat the response as if it had received a 400 (Bad
code. The response message will usually contain a representation Request) status code. The response message will usually contain a
that explains the status. representation that explains the status.
The first digit of the status-code defines the class of response. The first digit of the status-code defines the class of response.
The last two digits do not have any categorization role. There are 5 The last two digits do not have any categorization role. There are
values for the first digit: five values for the first digit:
o 1xx (Informational): The request was received, continuing process o 1xx (Informational): The request was received, continuing process
o 2xx (Successful): The request was successfully received, o 2xx (Successful): The request was successfully received,
understood, and accepted understood, and accepted
o 3xx (Redirection): Further action needs to be taken in order to o 3xx (Redirection): Further action needs to be taken in order to
complete the request complete the request
o 4xx (Client Error): The request contains bad syntax or cannot be o 4xx (Client Error): The request contains bad syntax or cannot be
fulfilled fulfilled
o 5xx (Server Error): The server failed to fulfill an apparently o 5xx (Server Error): The server failed to fulfill an apparently
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 [RFC7232], Section 4 of [RFC7233], and Section 3 of
The reason phrases listed here are only recommendations -- they can [RFC7235]. The reason phrases listed here are only recommendations
be replaced by local equivalents without affecting the protocol. -- they can 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, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
specification) can be reused by a cache with heuristic expiration this specification) can be reused by a cache with heuristic
unless otherwise indicated by the method definition or explicit cache expiration unless otherwise indicated by the method definition or
controls [Part6]; all other status codes are not cacheable by explicit cache controls [RFC7234]; all other status codes are not
default. cacheable by default.
+------+-------------------------------+--------------------------+
| Code | Reason-Phrase | Defined in... |
+------+-------------------------------+--------------------------+
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | Section 4.1 of [RFC7233] |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | Section 4.1 of [RFC7232] |
| 305 | Use Proxy | Section 6.4.5 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | Section 3.1 of [RFC7235] |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | Section 3.2 of [RFC7235] |
| 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | Section 4.2 of [RFC7232] |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | Section 4.4 of [RFC7233] |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
+------+-------------------------------+--------------------------+
+------+-------------------------------+------------------------+
| code | reason-phrase | Defined in... |
+------+-------------------------------+------------------------+
| 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 |
| 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | Section 4.1 of [Part5] |
| 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | Section 4.1 of [Part4] |
| 305 | Use Proxy | Section 6.4.5 |
| 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | Section 3.1 of [Part7] |
| 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | Section 3.2 of [Part7] |
| 408 | Request Time-out | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | Section 4.2 of [Part4] |
| 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | Section 4.4 of [Part5] |
| 417 | Expectation Failed | Section 6.5.14 |
| 426 | Upgrade Required | Section 6.5.15 |
| 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Time-out | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 |
+------+-------------------------------+------------------------+
Note that this list is not exhaustive -- it does not include Note that this list is not exhaustive -- it does not include
extension status codes defined in other specifications. The complete extension status codes defined in other specifications. The complete
list of status codes is maintained by IANA. See Section 8.2 for list of status codes is maintained by IANA. See Section 8.2 for
details. details.
6.2. Informational 1xx 6.2. Informational 1xx
The "1xx (Informational)" class of status code indicates an interim The "1xx (Informational)" class of status code indicates an interim
response for communicating connection status or request progress response for communicating connection status or request progress
prior to completing the requested action and sending a final prior to completing the requested action and sending a final
response. All 1xx responses consist of only the status-line and response. 1xx responses are terminated by the first empty line after
optional header fields, and thus are terminated by the empty line at the status-line (the empty line signaling the end of the header
the end of the header section. Since HTTP/1.0 did not define any 1xx section). Since HTTP/1.0 did not define any 1xx status codes, a
status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 server MUST NOT send a 1xx response to an HTTP/1.0 client.
client.
A client MUST be able to parse one or more 1xx responses received A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one. A prior to a final response, even if the client does not expect one. A
user agent MAY ignore unexpected 1xx responses. user agent MAY ignore unexpected 1xx responses.
A proxy MUST forward 1xx responses unless the proxy itself requested A proxy MUST forward 1xx responses unless the proxy itself requested
the generation of the 1xx response. For example, if a proxy adds an the generation of the 1xx response. For example, if a proxy adds an
"Expect: 100-continue" field when it forwards a request, then it need "Expect: 100-continue" field when it forwards a request, then it need
not forward the corresponding 100 (Continue) response(s). not forward the corresponding 100 (Continue) response(s).
skipping to change at page 49, line 50 skipping to change at page 50, line 47
discard the 100 response. discard the 100 response.
If the request did not contain an Expect header field containing the If the request did not contain an Expect header field containing the
100-continue expectation, the client can simply discard this interim 100-continue expectation, the client can simply discard this interim
response. response.
6.2.2. 101 Switching Protocols 6.2.2. 101 Switching Protocols
The "101 (Switching Protocols)" status code indicates that the server The "101 (Switching Protocols)" status code indicates that the server
understands and is willing to comply with the client's request, via understands and is willing to comply with the client's request, via
the Upgrade header field (Section 6.7 of [Part1]), for a change in the Upgrade header field (Section 6.7 of [RFC7230]), for a change in
the application protocol being used on this connection. The server the application protocol being used on this connection. The server
MUST generate an Upgrade header field in the response that indicates MUST generate an Upgrade header field in the response that indicates
which protocol(s) will be switched to immediately after the empty which protocol(s) will be switched to immediately after the empty
line that terminates the 101 response. line that terminates the 101 response.
It is assumed that the server will only agree to switch protocols It is assumed that the server will only agree to switch protocols
when it is advantageous to do so. For example, switching to a newer when it is advantageous to do so. For example, switching to a newer
version of HTTP might be advantageous over older versions, and version of HTTP might be advantageous over older versions, and
switching to a real-time, synchronous protocol might be advantageous switching to a real-time, synchronous protocol might be advantageous
when delivering resources that use such features. when delivering resources that use such features.
skipping to change at page 50, line 50 skipping to change at page 51, line 47
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 by default; i.e., unless otherwise A 200 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [RFC7234]).
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 51, line 27 skipping to change at page 52, line 22
6.3.3. 202 Accepted 6.3.3. 202 Accepted
The "202 (Accepted)" status code indicates that the request has been The "202 (Accepted)" status code indicates that the request has been
accepted for processing, but the processing has not been completed. accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place. There is no be disallowed when processing actually takes place. There is no
facility in HTTP for re-sending a status code from an asynchronous facility in HTTP for re-sending a status code from an asynchronous
operation. operation.
The 202 response is intentionally non-committal. Its purpose is to The 202 response is intentionally noncommittal. Its purpose is to
allow a server to accept a request for some other process (perhaps a allow a server to accept a request for some other process (perhaps a
batch-oriented process that is only run once per day) without batch-oriented process that is only run once per day) without
requiring that the user agent's connection to the server persist requiring that the user agent's connection to the server persist
until the process is completed. The representation sent with this until the process is completed. The representation sent with this
response ought to describe the request's current status and point to response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an (or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled. estimate of when the request will be fulfilled.
6.3.4. 203 Non-Authoritative Information 6.3.4. 203 Non-Authoritative Information
The "203 (Non-Authoritative Information)" status code indicates that The "203 (Non-Authoritative Information)" status code indicates that
the request was successful but the enclosed payload has been modified the request was successful but the enclosed payload has been modified
from that of the origin server's 200 (OK) response by a transforming from that of the origin server's 200 (OK) response by a transforming
proxy (Section 5.7.2 of [Part1]). This status code allows the proxy proxy (Section 5.7.2 of [RFC7230]). This status code allows the
to notify recipients when a transformation has been applied, since proxy to notify recipients when a transformation has been applied,
that knowledge might impact later decisions regarding the content. since that knowledge might impact later decisions regarding the
For example, future cache validation requests for the content might content. For example, future cache validation requests for the
only be applicable along the same request path (through the same content might only be applicable along the same request path (through
proxies). the same 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 [RFC7234]), 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 by default; i.e., unless otherwise A 203 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [RFC7234]).
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 52, line 39 skipping to change at page 53, line 37
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 by default; i.e., unless otherwise A 204 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [RFC7234]).
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 4 skipping to change at page 55, line 49
from that list automatically if it understands the provided media from that list automatically if it understands the provided media
type. A specific format for automatic selection is not defined by type. A specific format for automatic selection is not defined by
this specification because HTTP tries to remain orthogonal to the this specification because HTTP tries to remain orthogonal to the
definition of its payloads. In practice, the representation is definition of its payloads. In practice, the representation is
provided in some easily parsed format believed to be acceptable to provided in some easily parsed format believed to be acceptable to
the user agent, as determined by shared design or content the user agent, as determined by shared design or content
negotiation, or in some commonly accepted hypertext format. negotiation, or in some commonly accepted hypertext format.
A 300 response is cacheable by default; i.e., unless otherwise A 300 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [RFC7234]).
Note: The original proposal for 300 defined the URI header field Note: The original proposal for the 300 status code defined the
as providing a list of alternative representations, such that it URI header field as providing a list of alternative
would be usable for 200, 300, and 406 responses and be transferred representations, such that it would be usable for 200, 300, and
in responses to the HEAD method. However, lack of deployment and 406 responses and be transferred in responses to the HEAD method.
disagreement over syntax led to both URI and Alternates (a However, lack of deployment and disagreement over syntax led to
subsequent proposal) being dropped from this specification. It is both URI and Alternates (a subsequent proposal) being dropped from
possible to communicate the list using a set of Link header fields this specification. It is possible to communicate the list using
[RFC5988], each with a relationship of "alternate", though a set of Link header fields [RFC5988], each with a relationship of
deployment is a chicken-and-egg problem. "alternate", though deployment is a chicken-and-egg problem.
6.4.2. 301 Moved Permanently 6.4.2. 301 Moved Permanently
The "301 (Moved Permanently)" status code indicates that the target The "301 (Moved Permanently)" status code indicates that the target
resource has been assigned a new permanent URI and any future resource has been assigned a new permanent URI and any future
references to this resource ought to use one of the enclosed URIs. references to this resource ought to use one of the enclosed URIs.
Clients with link editing capabilities ought to automatically re-link Clients with link-editing capabilities ought to automatically re-link
references to the effective request URI to one or more of the new references to the effective request URI to one or more of the new
references sent by the server, where possible. references sent by the server, where possible.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
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 historical reasons, a user agent MAY change the request Note: For historical 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 by default; i.e., unless otherwise A 301 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [RFC7234]).
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 56, line 26 skipping to change at page 57, line 26
a retrieval request targeting that URI (a GET or HEAD request if a retrieval request targeting that URI (a GET or HEAD request if
using HTTP), which might also be redirected, and present the eventual using HTTP), which might also be redirected, and present the eventual
result as an answer to the original request. Note that the new URI result as an answer to the original request. Note that the new URI
in the Location header field is not considered equivalent to the in the Location header field is not considered equivalent to the
effective request URI. effective request URI.
This status code is applicable to any HTTP method. It is primarily This status code is applicable to any HTTP method. It is primarily
used to allow the output of a POST action to redirect the user agent used to allow the output of a POST action to redirect the user agent
to a selected resource, since doing so provides the information to a selected resource, since doing so provides the information
corresponding to the POST response in a form that can be separately corresponding to the POST response in a form that can be separately
identified, bookmarked, and cached independent of the original identified, bookmarked, and cached, independent of the original
request. request.
A 303 response to a GET request indicates that the origin server does A 303 response to a GET request indicates that the origin server does
not have a representation of the target resource that can be not have a representation of the target resource that can be
transferred by the server over HTTP. However, the Location field transferred by the server over HTTP. However, the Location field
value refers to a resource that is descriptive of the target value refers to a resource that is descriptive of the target
resource, such that making a retrieval request on that other resource resource, such that making a retrieval request on that other resource
might result in a representation that is useful to recipients without might result in a representation that is useful to recipients without
implying that it represents the original target resource. Note that implying that it represents the original target resource. Note that
answers to the questions of what can be represented, what answers to the questions of what can be represented, what
skipping to change at page 57, line 23 skipping to change at page 58, line 23
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
use the Location field value for automatic redirection. The server's use the Location field value for automatic redirection. The server's
response payload usually contains a short hypertext note with a response payload usually contains a short hypertext note with a
hyperlink to the different URI(s). hyperlink to the different URI(s).
Note: This status code is similar to 302 (Found), except that it Note: This status code is similar to 302 (Found), except that it
does not allow changing the request method from POST to GET. This does not allow changing the request method from POST to GET. This
specification defines no equivalent counterpart for 301 (Moved specification defines no equivalent counterpart for 301 (Moved
Permanently) ([status-308], however, defines the status code 308 Permanently) ([RFC7238], however, defines the status code 308
(Permanent Redirect) for this purpose). (Permanent Redirect) for this purpose).
6.5. Client Error 4xx 6.5. Client Error 4xx
The "4xx (Client Error)" class of status code indicates that the The "4xx (Client Error)" class of status code indicates that the
client seems to have erred. Except when responding to a HEAD client seems to have erred. Except when responding to a HEAD
request, the server SHOULD send a representation containing an request, the server SHOULD send a representation containing an
explanation of the error situation, and whether it is a temporary or explanation of the error situation, and whether it is a temporary or
permanent condition. These status codes are applicable to any permanent condition. These status codes are applicable to any
request method. User agents SHOULD display any included request method. User agents SHOULD display any included
representation to the user. representation to the user.
6.5.1. 400 Bad Request 6.5.1. 400 Bad Request
The "400 (Bad Request)" status code indicates that the server cannot The "400 (Bad Request)" status code indicates that the server cannot
or will not process the request due to something which is perceived or will not process the request due to something that is perceived to
to be a client error (e.g., malformed request syntax, invalid request be a client error (e.g., malformed request syntax, invalid request
message framing, or deceptive request routing). message framing, or deceptive request routing).
6.5.2. 402 Payment Required 6.5.2. 402 Payment Required
The "402 (Payment Required)" status code is reserved for future use. The "402 (Payment Required)" status code is reserved for future use.
6.5.3. 403 Forbidden 6.5.3. 403 Forbidden
The "403 (Forbidden)" status code indicates that the server The "403 (Forbidden)" status code indicates that the server
understood the request but refuses to authorize it. A server that understood the request but refuses to authorize it. A server that
skipping to change at page 58, line 28 skipping to change at page 59, line 28
The "404 (Not Found)" status code indicates that the origin server The "404 (Not Found)" status code indicates that the origin server
did not find a current representation for the target resource or is did not find a current representation for the target resource or is
not willing to disclose that one exists. A 404 status code does not 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 by default; i.e., unless otherwise A 404 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [RFC7234]).
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 by default; i.e., unless otherwise A 405 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [RFC7234]).
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 59, line 13 skipping to change at page 60, line 13
from which the user or user agent can choose the one most from which the user or user agent can choose the one most
appropriate. A user agent MAY automatically select the most appropriate. A user agent MAY automatically select the most
appropriate choice from that list. However, this specification does appropriate choice from that list. However, this specification does
not define any standard for such automatic selection, as described in not define any standard for such automatic selection, as described in
Section 6.4.1. Section 6.4.1.
6.5.7. 408 Request Timeout 6.5.7. 408 Request Timeout
The "408 (Request Timeout)" status code indicates that the server did The "408 (Request Timeout)" status code indicates that the server did
not receive a complete request message within the time that it was not receive a complete request message within the time that it was
prepared to wait. A server SHOULD send the close connection option prepared to wait. A server SHOULD send the "close" connection option
(Section 6.1 of [Part1]) in the response, since 408 implies that the (Section 6.1 of [RFC7230]) in the response, since 408 implies that
server has decided to close the connection rather than continue the server has decided to close the connection rather than continue
waiting. If the client has an outstanding request in transit, the waiting. If the client has an outstanding request in transit, the
client MAY repeat that request on a new connection. client MAY repeat that request on a new connection.
6.5.8. 409 Conflict 6.5.8. 409 Conflict
The "409 (Conflict)" status code indicates that the request could not The "409 (Conflict)" status code indicates that the request could not
be completed due to a conflict with the current state of the target be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server able to resolve the conflict and resubmit the request. The server
SHOULD generate a payload that includes enough information for a user SHOULD generate a payload that includes enough information for a user
skipping to change at page 60, line 9 skipping to change at page 61, line 9
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 by default; i.e., unless otherwise A 410 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [RFC7234]).
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 [RFC7230]). The client MAY repeat the request if
adds a valid Content-Length header field containing the length of the it adds a valid Content-Length header field containing the length of
message body in the request message. the message body in the request message.
6.5.11. 413 Payload Too Large 6.5.11. 413 Payload Too Large
The "413 (Payload Too Large)" status code indicates that the server The "413 (Payload Too Large)" status code indicates that the server
is refusing to process a request because the request payload is is refusing to process a request because the request payload is
larger than the server is willing or able to process. The server MAY larger than the server is willing or able to process. The server MAY
close the connection to prevent the client from continuing the close the connection to prevent the client from continuing the
request. request.
If the condition is temporary, the server SHOULD generate a Retry- If the condition is temporary, the server SHOULD generate a Retry-
After header field to indicate that it is temporary and after what After header field to indicate that it is temporary and after what
time the client MAY try again. time the client MAY try again.
6.5.12. 414 URI Too Long 6.5.12. 414 URI Too Long
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 [RFC7230]) 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 by default; i.e., unless otherwise A 414 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [RFC7234]).
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 61, line 23 skipping to change at page 62, line 23
(Section 5.1.1) could not be met by at least one of the inbound (Section 5.1.1) could not be met by at least one of the inbound
servers. servers.
6.5.15. 426 Upgrade Required 6.5.15. 426 Upgrade Required
The "426 (Upgrade Required)" status code indicates that the server The "426 (Upgrade Required)" status code indicates that the server
refuses to perform the request using the current protocol but might refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different be willing to do so after the client upgrades to a different
protocol. The server MUST send an Upgrade header field in a 426 protocol. The server MUST send an Upgrade header field in a 426
response to indicate the required protocol(s) (Section 6.7 of response to indicate the required protocol(s) (Section 6.7 of
[Part1]). [RFC7230]).
Example: Example:
HTTP/1.1 426 Upgrade Required HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0 Upgrade: HTTP/3.0
Connection: Upgrade Connection: Upgrade
Content-Length: 53 Content-Length: 53
Content-Type: text/plain Content-Type: text/plain
This service requires use of the HTTP/3.0 protocol. This service requires use of the HTTP/3.0 protocol.
skipping to change at page 62, line 15 skipping to change at page 63, line 15
6.6.2. 501 Not Implemented 6.6.2. 501 Not Implemented
The "501 (Not Implemented)" status code indicates that the server The "501 (Not Implemented)" status code indicates that the server
does not support the functionality required to fulfill the request. does not support the functionality required to fulfill the request.
This is the appropriate response when the server does not recognize This is the appropriate response when the server does not recognize
the request method and is not capable of supporting it for any the request method and is not capable of supporting it for any
resource. resource.
A 501 response is cacheable by default; i.e., unless otherwise A 501 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [Part6]). Section 4.2.2 of [RFC7234]).
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 62, line 49 skipping to change at page 63, line 49
while acting as a gateway or proxy, did not receive a timely response while acting as a gateway or proxy, did not receive a timely response
from an upstream server it needed to access in order to complete the from an upstream server it needed to access in order to complete the
request. request.
6.6.6. 505 HTTP Version Not Supported 6.6.6. 505 HTTP Version Not Supported
The "505 (HTTP Version Not Supported)" status code indicates that the The "505 (HTTP Version Not Supported)" status code indicates that the
server does not support, or refuses to support, the major version of server does not support, or refuses to support, the major version of
HTTP that was used in the request message. The server is indicating HTTP that was used in the request message. The server is indicating
that it is unable or unwilling to complete the request using the same that it is unable or unwilling to complete the request using the same
major version as the client, as described in Section 2.6 of [Part1], major version as the client, as described in Section 2.6 of
other than with this error message. The server SHOULD generate a [RFC7230], other than with this error message. The server SHOULD
representation for the 505 response that describes why that version generate a representation for the 505 response that describes why
is not supported and what other protocols are supported by that that version is not supported and what other protocols are supported
server. by that server.
7. Response Header Fields 7. 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 beyond what is placed in the status- information about the response beyond what is placed in the status-
line. These header fields give information about the server, about line. These header fields give information about the server, about
further access to the target resource, or about related resources. further access to the target resource, or about related resources.
Although each response header field has a defined meaning, in Although each response header field has a defined meaning, in
general, the precise semantics might be further refined by the general, the precise semantics might be further refined by the
semantics of the request method and/or response status code. semantics of the request method and/or response status code.
7.1. Control Data 7.1. Control Data
Response header fields can supply control data that supplements the Response header fields can supply control data that supplements the
status code, directs caching, or instructs the client where to go status code, directs caching, or instructs the client where to go
next. next.
+-------------------+------------------------+ +-------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+------------------------+ +-------------------+--------------------------+
| Age | Section 5.1 of [Part6] | | Age | Section 5.1 of [RFC7234] |
| Cache-Control | Section 5.2 of [Part6] | | Cache-Control | Section 5.2 of [RFC7234] |
| Expires | Section 5.3 of [Part6] | | Expires | Section 5.3 of [RFC7234] |
| Date | Section 7.1.1.2 | | Date | Section 7.1.1.2 |
| Location | Section 7.1.2 | | Location | Section 7.1.2 |
| Retry-After | Section 7.1.3 | | Retry-After | Section 7.1.3 |
| Vary | Section 7.1.4 | | Vary | Section 7.1.4 |
| Warning | Section 5.5 of [Part6] | | Warning | Section 5.5 of [RFC7234] |
+-------------------+------------------------+ +-------------------+--------------------------+
7.1.1. Origination Date 7.1.1. Origination Date
7.1.1.1. Date/Time Formats 7.1.1.1. Date/Time Formats
Prior to 1995, there were three different formats commonly used by Prior to 1995, there were three different formats commonly used by
servers to communicate timestamps. For compatibility with old servers to communicate timestamps. For compatibility with old
implementations, all three are defined here. The preferred format is implementations, all three are defined here. The preferred format is
a fixed-length and single-zone subset of the date and time a fixed-length and single-zone subset of the date and time
specification used by the Internet Message Format [RFC5322]. specification used by the Internet Message Format [RFC5322].
skipping to change at page 65, line 7 skipping to change at page 66, line 7
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 ([RFC5905]) 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/capitalization subset of the format ; fixed length/zone/capitalization subset of the format
; defined in Section 3.3 of [RFC5322] ; see 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
/ %x57.65.64 ; "Wed", case-sensitive / %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive / %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive / %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive / %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive / %x53.75.6E ; "Sun", case-sensitive
date1 = day SP month SP year date1 = day SP month SP year
skipping to change at page 68, line 5 skipping to change at page 69, line 5
The field value consists of a single URI-reference. When it has the The field value consists of a single URI-reference. When it has the
form of a relative reference ([RFC3986], Section 4.2), the final form of a relative reference ([RFC3986], Section 4.2), the final
value is computed by resolving it against the effective request URI value is computed by resolving it against the effective request URI
([RFC3986], Section 5). ([RFC3986], Section 5).
For 201 (Created) responses, the Location value refers to the primary For 201 (Created) responses, the Location value refers to the primary
resource created by the request. For 3xx (Redirection) responses, resource created by the request. For 3xx (Redirection) responses,
the Location value refers to the preferred target resource for the Location value refers to the preferred target resource for
automatically redirecting the request. automatically redirecting the request.
If the Location value provided in a 3xx (Redirection) does not have a If the Location value provided in a 3xx (Redirection) response does
fragment component, a user agent MUST process the redirection as if not have a fragment component, a user agent MUST process the
the value inherits the fragment component of the URI reference used redirection as if the value inherits the fragment component of the
to generate the request target (i.e., the redirection inherits the URI reference used to generate the request target (i.e., the
original reference's fragment, if any). redirection inherits the original reference's fragment, if any).
For example, a GET request generated for the URI reference For example, a GET request generated for the URI reference
"http://www.example.org/~tim" might result in a 303 (See Other) "http://www.example.org/~tim" might result in a 303 (See Other)
response containing the header field: response containing the header field:
Location: /People.html#tim Location: /People.html#tim
which suggests that the user agent redirect to which suggests that the user agent redirect to
"http://www.example.org/People.html#tim" "http://www.example.org/People.html#tim"
skipping to change at page 70, line 19 skipping to change at page 71, line 19
indicates that the origin server might have used the request's indicates that the origin server might have used the request's
Accept-Encoding and Accept-Language fields (or lack thereof) as Accept-Encoding and Accept-Language fields (or lack thereof) as
determining factors while choosing the content for this response. determining factors while choosing the content for this response.
An origin server might send Vary with a list of fields for two An origin server might send Vary with a list of fields for two
purposes: purposes:
1. To inform cache recipients that they MUST NOT use this response 1. To inform cache recipients that they MUST NOT use this response
to satisfy a later request unless the later request has the same to satisfy a later request unless the later request has the same
values for the listed fields as the original request (Section 4.1 values for the listed fields as the original request (Section 4.1
of [Part6]). In other words, Vary expands the cache key required of [RFC7234]). In other words, Vary expands the cache key
to match a new request to the stored cache entry. required to match a new request to the stored cache entry.
2. To inform user agent recipients that this response is subject to 2. To inform user agent recipients that this response is subject to
content negotiation (Section 5.3) and that a different content negotiation (Section 5.3) and that a different
representation might be sent in a subsequent request if representation might be sent in a subsequent request if
additional parameters are provided in the listed header fields additional parameters are provided in the listed header fields
(proactive negotiation). (proactive negotiation).
An origin server SHOULD send a Vary header field when its algorithm An origin server SHOULD send a Vary header field when its algorithm
for selecting a representation varies based on aspects of the request for selecting a representation varies based on aspects of the request
message other than the method and request target, unless the variance message other than the method and request target, unless the variance
cannot be crossed or the origin server has been deliberately cannot be crossed or the origin server has been deliberately
configured to prevent cache transparency. For example, there is no configured to prevent cache transparency. For example, there is no
need to send the Authorization field name in Vary because reuse need to send the Authorization field name in Vary because reuse
across users is constrained by the field definition (Section 4.2 of across users is constrained by the field definition (Section 4.2 of
[Part7]). Likewise, an origin server might use Cache-Control [RFC7235]). Likewise, an origin server might use Cache-Control
directives (Section 5.2 of [Part6]) to supplant Vary if it considers directives (Section 5.2 of [RFC7234]) to supplant Vary if it
the variance less significant than the performance cost of Vary's considers the variance less significant than the performance cost of
impact on caching. Vary's impact on caching.
7.2. Validator Header Fields 7.2. Validator Header Fields
Validator header fields convey metadata about the selected Validator header fields convey metadata about the selected
representation (Section 3). In responses to safe requests, validator representation (Section 3). In responses to safe requests, validator
fields describe the selected representation chosen by the origin fields describe the selected representation chosen by the origin
server while handling the response. Note that, depending on the server while handling the response. Note that, depending on the
status code semantics, the selected representation for a given status code semantics, the selected representation for a given
response is not necessarily the same as the representation enclosed response is not necessarily the same as the representation enclosed
as response payload. as response payload.
In a successful response to a state-changing request, validator In a successful response to a state-changing request, validator
fields describe the new representation that has replaced the prior fields describe the new representation that has replaced the prior
selected representation as a result of processing the request. selected representation as a result of processing the request.
For example, an ETag header field in a 201 response communicates the For example, an ETag header field in a 201 (Created) response
entity-tag of the newly created resource's representation, so that it communicates the entity-tag of the newly created resource's
can be used in later conditional requests to prevent the "lost representation, so that it can be used in later conditional requests
update" problem [Part4]. to prevent the "lost update" problem [RFC7232].
+-------------------+------------------------+ +-------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+------------------------+ +-------------------+--------------------------+
| ETag | Section 2.3 of [Part4] | | ETag | Section 2.3 of [RFC7232] |
| Last-Modified | Section 2.2 of [Part4] | | Last-Modified | Section 2.2 of [RFC7232] |
+-------------------+------------------------+ +-------------------+--------------------------+
7.3. Authentication Challenges 7.3. Authentication Challenges
Authentication challenges indicate what mechanisms are available for Authentication challenges indicate what mechanisms are available for
the client to provide authentication credentials in future requests. the client to provide authentication credentials in future requests.
+--------------------+------------------------+ +--------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+--------------------+------------------------+ +--------------------+--------------------------+
| WWW-Authenticate | Section 4.1 of [Part7] | | WWW-Authenticate | Section 4.1 of [RFC7235] |
| Proxy-Authenticate | Section 4.3 of [Part7] | | Proxy-Authenticate | Section 4.3 of [RFC7235] |
+--------------------+------------------------+ +--------------------+--------------------------+
7.4. Response Context 7.4. Response Context
The remaining response header fields provide more information about The remaining response header fields provide more information about
the target resource for potential use in later requests. the target resource for potential use in later requests.
+-------------------+------------------------+ +-------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+------------------------+ +-------------------+--------------------------+
| Accept-Ranges | Section 2.3 of [Part5] | | Accept-Ranges | Section 2.3 of [RFC7233] |
| Allow | Section 7.4.1 | | Allow | Section 7.4.1 |
| Server | Section 7.4.2 | | Server | Section 7.4.2 |
+-------------------+------------------------+ +-------------------+--------------------------+
7.4.1. Allow 7.4.1. Allow
The "Allow" header field lists the set of methods advertised as The "Allow" header field lists the set of methods advertised as
supported by the target resource. The purpose of this field is supported by the target resource. The purpose of this field is
strictly to inform the recipient of valid request methods associated strictly to inform the recipient of valid request methods associated
with the resource. with the resource.
Allow = #method Allow = #method
skipping to change at page 72, line 31 skipping to change at page 73, line 31
used by the origin server to handle the request, which is often used used by the origin server to handle the request, which is often used
by clients to help identify the scope of reported interoperability by clients to help identify the scope of reported interoperability
problems, to work around or tailor requests to avoid particular problems, to work around or tailor requests to avoid particular
server limitations, and for analytics regarding server or operating server limitations, and for analytics regarding server or operating
system use. An origin server MAY generate a Server field in its system use. An origin server MAY generate a Server field in its
responses. responses.
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers, The Server field-value consists of one or more product identifiers,
each followed by zero or more comments (Section 3.2 of [Part1]), each followed by zero or more comments (Section 3.2 of [RFC7230]),
which together identify the origin server software and its which together identify the origin server software and its
significant subproducts. By convention, the product identifiers are significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the listed in decreasing order of their significance for identifying the
origin server software. Each product identifier consists of a name origin server software. Each product identifier consists of a name
and optional version, as defined in Section 5.5.3. and optional version, as defined in Section 5.5.3.
Example: Example:
Server: CERN/3.0 libwww/2.17 Server: CERN/3.0 libwww/2.17
An origin server SHOULD NOT generate a Server field containing An origin server SHOULD NOT generate a Server field containing
needlessly fine-grained detail and SHOULD limit the addition of needlessly fine-grained detail and SHOULD limit the addition of
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 "Hypertext Transfer Protocol (HTTP) Method Registry" defines the
method token (Section 4). The method registry will be created and namespace for the request method token (Section 4). The method
maintained at (the suggested URI) registry has been created and is now maintained at
<http://www.iana.org/assignments/http-methods>. <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)
o Pointer to specification text o Pointer to specification text
Values to be added to this name space require IETF Review (see Values to be added to this namespace require IETF Review (see
[RFC5226], Section 4.1). [RFC5226], Section 4.1).
8.1.2. Considerations for New Methods 8.1.2. Considerations for New Methods
Standardized methods are generic; that is, they are potentially Standardized methods are generic; that is, they are potentially
applicable to any resource, not just one particular media type, kind applicable to any resource, not just one particular media type, kind
of resource, or application. As such, it is preferred that new of resource, or application. As such, it is preferred that new
methods be registered in a document that isn't specific to a single methods be registered in a document that isn't specific to a single
application or data format, since orthogonal technologies deserve application or data format, since orthogonal technologies deserve
orthogonal specification. orthogonal specification.
Since message parsing (Section 3.3 of [Part1]) needs to be Since message parsing (Section 3.3 of [RFC7230]) needs to be
independent of method semantics (aside from responses to HEAD), independent of method semantics (aside from responses to HEAD),
definitions of new methods cannot change the parsing algorithm or definitions of new methods cannot change the parsing algorithm or
prohibit the presence of a message body on either the request or the prohibit the presence of a message body on either the request or the
response message. Definitions of new methods can specify that only a response message. Definitions of new methods can specify that only a
zero-length message body is allowed by requiring a Content-Length zero-length message body is allowed by requiring a Content-Length
header field with a value of "0". header field with a value of "0".
A new method definition needs to indicate whether it is safe A new method definition needs to indicate whether it is safe
(Section 4.2.1), idempotent (Section 4.2.2), cacheable (Section 4.2.1), idempotent (Section 4.2.2), cacheable
(Section 4.2.3), what semantics are to be associated with the payload (Section 4.2.3), what semantics are to be associated with the payload
body if any is present in the request, and what refinements the body if any is present in the request and what refinements the method
method makes to header field or status code semantics. If the new makes to header field or status code semantics. If the new method is
method is cacheable, its definition ought to describe how, and under cacheable, its definition ought to describe how, and under what
what conditions, a cache can store a response and use it to satisfy a conditions, a cache can store a response and use it to satisfy a
subsequent request. The new method ought to describe whether it can subsequent request. The new method ought to describe whether it can
be made conditional (Section 5.2) and, if so, how a server responds be made conditional (Section 5.2) and, if so, how a server responds
when the condition is false. Likewise, if the new method might have when the condition is false. Likewise, if the new method might have
some use for partial response semantics ([Part5]), it ought to some use for partial response semantics ([RFC7233]), it ought to
document this too. document this, too.
Note: Avoid defining a method name that starts with "M-", since Note: Avoid defining a method name that starts with "M-", since
that prefix might be misinterpreted as having the semantics that prefix might be misinterpreted as having the semantics
assigned to it by [RFC2774]. assigned to it by [RFC2774].
8.1.3. Registrations 8.1.3. Registrations
The HTTP Method Registry shall be populated with the registrations The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
below: populated with the registrations below:
+---------+------+------------+---------------+ +---------+------+------------+---------------+
| Method | Safe | Idempotent | Reference | | Method | Safe | Idempotent | Reference |
+---------+------+------------+---------------+ +---------+------+------------+---------------+
| CONNECT | no | no | Section 4.3.6 | | CONNECT | no | no | Section 4.3.6 |
| DELETE | no | yes | Section 4.3.5 | | DELETE | no | yes | Section 4.3.5 |
| GET | yes | yes | Section 4.3.1 | | GET | yes | yes | Section 4.3.1 |
| HEAD | yes | yes | Section 4.3.2 | | HEAD | yes | yes | Section 4.3.2 |
| OPTIONS | yes | yes | Section 4.3.7 | | OPTIONS | yes | yes | Section 4.3.7 |
| POST | no | no | Section 4.3.3 | | POST | no | no | Section 4.3.3 |
| PUT | no | yes | Section 4.3.4 | | PUT | no | yes | Section 4.3.4 |
| TRACE | yes | yes | Section 4.3.8 | | TRACE | yes | yes | Section 4.3.8 |
+---------+------+------------+---------------+ +---------+------+------------+---------------+
8.2. Status Code Registry 8.2. Status Code Registry
The HTTP Status Code Registry defines the name space for the response The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
status-code token (Section 6). The status code registry is the namespace for the response status-code token (Section 6). The
maintained at <http://www.iana.org/assignments/http-status-codes>. status code registry is maintained at
<http://www.iana.org/assignments/http-status-codes>.
This Section replaces the registration procedure for HTTP Status This section replaces the registration procedure for HTTP Status
Codes previously defined in Section 7.1 of [RFC2817]. Codes previously defined in Section 7.1 of [RFC2817].
8.2.1. Procedure 8.2.1. Procedure
A registration MUST include the following fields: A registration MUST include the following fields:
o Status Code (3 digits) o Status Code (3 digits)
o Short Description o Short Description
o Pointer to specification text o Pointer to specification text
Values to be added to the HTTP status code name space require IETF Values to be added to the HTTP status code namespace require IETF
Review (see [RFC5226], Section 4.1). Review (see [RFC5226], Section 4.1).
8.2.2. Considerations for New Status Codes 8.2.2. Considerations for New Status Codes
When it is necessary to express semantics for a response that are not When it is necessary to express semantics for a response that are not
defined by current status codes, a new status code can be registered. defined by current status codes, a new status code can be registered.
Status codes are generic; they are potentially applicable to any Status codes are generic; they are potentially applicable to any
resource, not just one particular media type, kind of resource, or resource, not just one particular media type, kind of resource, or
application of HTTP. As such, it is preferred that new status codes application of HTTP. As such, it is preferred that new status codes
be registered in a document that isn't specific to a single be registered in a document that isn't specific to a single
skipping to change at page 75, line 41 skipping to change at page 76, line 41
are required, what fields can modify the semantics, and what header are required, what fields can modify the semantics, and what header
field semantics are further refined when used with the new status field semantics are further refined when used with the new status
code). code).
The definition of a new status code ought to specify whether or not The definition of a new status code ought to specify whether or not
it is cacheable. Note that all status codes can be cached if the it is cacheable. Note that all status codes can be cached if the
response they occur in has explicit freshness information; however, response they occur in has explicit freshness information; however,
status codes that are defined as being cacheable are allowed to be status codes that are defined as being cacheable are allowed to be
cached without explicit freshness information. Likewise, the cached without explicit freshness information. Likewise, the
definition of a status code can place constraints upon cache definition of a status code can place constraints upon cache
behavior. See [Part6] for more information. behavior. See [RFC7234] for more information.
Finally, the definition of a new status code ought to indicate Finally, the definition of a new status code ought to indicate
whether the payload has any implied association with an identified whether the payload has any implied association with an identified
resource (Section 3.1.4.1). resource (Section 3.1.4.1).
8.2.3. Registrations 8.2.3. Registrations
The HTTP Status Code Registry shall be updated with the registrations The status code registry has been updated with the registrations
below: below:
+-------+-------------------------------+----------------+ +-------+-------------------------------+----------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------+----------------+ +-------+-------------------------------+----------------+
| 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 |
skipping to change at page 76, line 48 skipping to change at page 77, line 48
| 500 | Internal Server Error | Section 6.6.1 | | 500 | Internal Server Error | Section 6.6.1 |
| 501 | Not Implemented | Section 6.6.2 | | 501 | Not Implemented | Section 6.6.2 |
| 502 | Bad Gateway | Section 6.6.3 | | 502 | Bad Gateway | Section 6.6.3 |
| 503 | Service Unavailable | Section 6.6.4 | | 503 | Service Unavailable | Section 6.6.4 |
| 504 | Gateway Timeout | Section 6.6.5 | | 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 | | 505 | HTTP Version Not Supported | Section 6.6.6 |
+-------+-------------------------------+----------------+ +-------+-------------------------------+----------------+
8.3. Header Field Registry 8.3. Header Field Registry
HTTP header fields are registered within the Message Header Field HTTP header fields are registered within the "Message Headers"
Registry located at <http://www.iana.org/assignments/message-headers/ registry located at
message-header-index.html>, as defined by [BCP90]. <http://www.iana.org/assignments/message-headers>, 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 [RFC7230] 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 not to 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; see [BCP178] for further information) 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
as necessary, and are usually constrained to the range of ASCII [RFC7230] as necessary, and are usually constrained to the range of
characters. Header fields needing a greater range of characters can US-ASCII characters. Header fields needing a greater range of
use an encoding such as the one defined in [RFC5987]. characters can 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 [RFC7230]). 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
use a container syntax such as quoted-string (Section 3.2.6 of use a container syntax such as quoted-string (Section 3.2.6 of
[Part1]). [RFC7230]).
Because commas (",") are used as a generic delimiter between field- Because commas (",") are used as a generic delimiter between field-
values, they need to be treated with care if they are allowed in the values, they need to be treated with care if they are allowed in the
field-value. Typically, components that might contain a comma are field-value. Typically, components that might contain a comma are
protected with double-quotes using the quoted-string ABNF production. protected with double-quotes using the quoted-string ABNF production.
For example, a textual date and a URI (either of which might contain For example, a textual date and a URI (either of which might contain
a comma) could be safely carried in field-values like these: a comma) could be safely carried in field-values like these:
Example-URI-Field: "http://example.com/a.html,foo", Example-URI-Field: "http://example.com/a.html,foo",
skipping to change at page 78, line 15 skipping to change at page 79, line 15
Allowing both unquoted (token) and quoted (quoted-string) syntax for Allowing both unquoted (token) and quoted (quoted-string) syntax for
the parameter value enables recipients to use existing parser the parameter value enables recipients to use existing parser
components. When allowing both forms, the meaning of a parameter components. When allowing both forms, the meaning of a parameter
value ought to be independent of the syntax used for it (for an value ought to be independent of the syntax used for it (for an
example, see the notes on parameter handling for media types in example, see the notes on parameter handling for media types in
Section 3.1.1.1). Section 3.1.1.1).
Authors of specifications defining new header fields are advised to Authors of specifications defining new header fields are advised to
consider documenting: consider documenting:
o Whether the field is a single value, or whether it can be a list o Whether the field is a single value or whether it can be a list
(delimited by commas; see Section 3.2 of [Part1]). (delimited by commas; see Section 3.2 of [RFC7230]).
If it does not use the list syntax, document how to treat messages If it does not use the list syntax, document how to treat messages
where the field occurs multiple times (a sensible default would be where the field occurs multiple times (a sensible default would be
to ignore the field, but this might not always be the right to ignore the field, but this might not always be the right
choice). choice).
Note that intermediaries and software libraries might combine Note that intermediaries and software libraries might combine
multiple header field instances into a single one, despite the multiple header field instances into a single one, despite the
field's definition not allowing the list syntax. A robust format field's definition not allowing the list syntax. A robust format
enables recipients to discover these situations (good example: enables recipients to discover these situations (good example:
skipping to change at page 78, line 43 skipping to change at page 79, line 43
particular request method, etc. particular request method, etc.
o Whether the field should be stored by origin servers that o Whether the field should be stored by origin servers that
understand it upon a PUT request. understand it upon a PUT request.
o Whether the field semantics are further refined by the context, o Whether the field semantics are further refined by the context,
such as by existing request methods or status codes. such as by existing request methods or status codes.
o Whether it is appropriate to list the field-name in the Connection o Whether it is appropriate to list the field-name in the Connection
header field (i.e., if the header field is to be hop-by-hop; see header field (i.e., if the header field is to be hop-by-hop; see
Section 6.1 of [Part1]). Section 6.1 of [RFC7230]).
o Under what conditions intermediaries are allowed to insert, o Under what conditions intermediaries are allowed to insert,
delete, or modify the field's value. delete, or modify the field's value.
o Whether it is appropriate to list the field-name in a Vary o Whether it is appropriate to list the field-name in a Vary
response header field (e.g., when the request header field is used response header field (e.g., when the request header field is used
by an origin server's content selection algorithm; see by an origin server's content selection algorithm; see
Section 7.1.4). Section 7.1.4).
o Whether the header field is useful or allowable in trailers (see o Whether the header field is useful or allowable in trailers (see
Section 4.1 of [Part1]). Section 4.1 of [RFC7230]).
o Whether the header field ought to be preserved across redirects. o Whether the header field ought to be preserved across redirects.
o Whether it introduces any additional security considerations, such o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data. as disclosure of privacy-related data.
8.3.2. Registrations 8.3.2. Registrations
The Message Header Field Registry shall be updated with the following The "Message Headers" registry has been updated with the following
permanent registrations: permanent registrations:
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+-----------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+-----------------+
| Accept | http | standard | Section 5.3.2 | | Accept | http | standard | Section 5.3.2 |
| Accept-Charset | http | standard | Section 5.3.3 | | Accept-Charset | http | standard | Section 5.3.3 |
| Accept-Encoding | http | standard | Section 5.3.4 | | Accept-Encoding | http | standard | Section 5.3.4 |
| Accept-Language | http | standard | Section 5.3.5 | | Accept-Language | http | standard | Section 5.3.5 |
| Allow | http | standard | Section 7.4.1 | | Allow | http | standard | Section 7.4.1 |
| Content-Encoding | http | standard | Section 3.1.2.2 | | Content-Encoding | http | standard | Section 3.1.2.2 |
| Content-Language | http | standard | Section 3.1.3.2 | | Content-Language | http | standard | Section 3.1.3.2 |
| Content-Location | http | standard | Section 3.1.4.2 | | Content-Location | http | standard | Section 3.1.4.2 |
| Content-Type | http | standard | Section 3.1.1.5 | | Content-Type | http | standard | Section 3.1.1.5 |
| Date | http | standard | Section 7.1.1.2 | | Date | http | standard | Section 7.1.1.2 |
| Expect | http | standard | Section 5.1.1 | | Expect | http | standard | Section 5.1.1 |
| From | http | standard | Section 5.5.1 | | From | http | standard | Section 5.5.1 |
| Location | http | standard | Section 7.1.2 | | Location | http | standard | Section 7.1.2 |
| MIME-Version | http | standard | Appendix A.1 |
| Max-Forwards | http | standard | Section 5.1.2 | | Max-Forwards | http | standard | Section 5.1.2 |
| MIME-Version | http | standard | Appendix A.1 |
| Referer | http | standard | Section 5.5.2 | | Referer | http | standard | Section 5.5.2 |
| Retry-After | http | standard | Section 7.1.3 | | Retry-After | http | standard | Section 7.1.3 |
| Server | http | standard | Section 7.4.2 | | Server | http | standard | Section 7.4.2 |
| User-Agent | http | standard | Section 5.5.3 | | User-Agent | http | standard | Section 5.5.3 |
| Vary | http | standard | Section 7.1.4 | | Vary | http | standard | Section 7.1.4 |
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+-----------------+
The change controller for the above registrations is: "IETF The change controller for the above registrations is: "IETF
(iesg@ietf.org) - Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
8.4. Content Coding Registry 8.4. Content Coding Registry
The HTTP Content Coding Registry defines the name space for content The "HTTP Content Coding Registry" defines the namespace for content
coding names (Section 4.2 of [Part1]). The content coding registry coding names (Section 4.2 of [RFC7230]). The content coding registry
is maintained at <http://www.iana.org/assignments/http-parameters>. is maintained at <http://www.iana.org/assignments/http-parameters>.
8.4.1. Procedure 8.4.1. Procedure
Content Coding registrations MUST include the following fields: Content coding registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of content codings MUST NOT overlap with names of transfer Names of content codings MUST NOT overlap with names of transfer
codings (Section 4 of [Part1]), unless the encoding transformation is codings (Section 4 of [RFC7230]), unless the encoding transformation
identical (as is the case for the compression codings defined in is identical (as is the case for the compression codings defined in
Section 4.2 of [Part1]). Section 4.2 of [RFC7230]).
Values to be added to this name space require IETF Review (see Values to be added to this namespace require IETF Review (see Section
Section 4.1 of [RFC5226]), and MUST conform to the purpose of content 4.1 of [RFC5226]) and MUST conform to the purpose of content coding
coding defined in this section. 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 Coding Registry" has been updated with the
registrations below: registrations below:
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| Name | Description | Reference | | Name | Description | Reference |
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
| identity | Reserved (synonym for "no encoding" in | Section 5.3.4 | | identity | Reserved (synonym for "no encoding" in | Section 5.3.4 |
| | Accept-Encoding) | | | | Accept-Encoding) | |
+----------+----------------------------------------+---------------+ +----------+----------------------------------------+---------------+
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 semantics and and users of known security concerns relevant to HTTP semantics and
its use for transferring information over the Internet. its use for transferring information over the Internet.
Considerations related to message syntax, parsing, and routing are Considerations related to message syntax, parsing, and routing are
discussed in Section 9 of [Part1]. discussed in Section 9 of [RFC7230].
The list of considerations below is not exhaustive. Most security The list of considerations below is not exhaustive. Most security
concerns related to HTTP semantics are about securing server-side concerns related to HTTP semantics are about securing server-side
applications (code behind the HTTP interface), securing user agent applications (code behind the HTTP interface), securing user agent
processing of payloads received via HTTP, or secure use of the processing of payloads received via HTTP, or secure use of the
Internet in general, rather than security of the protocol. Various Internet in general, rather than security of the protocol. Various
organizations maintain topical information and links to current organizations maintain topical information and links to current
research on Web application security (e.g., [OWASP]). research on Web application security (e.g., [OWASP]).
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
manage the mapping from effective request URI to resource manage the mapping from effective request URI to resource
representations. Implementers need to be aware that most file representations. Most file systems are not designed to protect
systems are not designed to protect against malicious file or path against malicious file or path names. Therefore, an origin server
names, and thus depend on the origin server to avoid mapping to file needs to avoid accessing names that have a special significance to
names, folders, or directories that have special significance to the the system when mapping the request target to files, folders, or
system. directories.
For example, UNIX, Microsoft Windows, and other operating systems use For example, UNIX, Microsoft Windows, and other operating systems use
".." as a path component to indicate a directory level above the ".." as a path component to indicate a directory level above the
current one, and use specially named paths or file names to send data current one, and they use specially named paths or file names to send
to system devices. Similar naming conventions might exist within data to system devices. Similar naming conventions might exist
other types of storage systems. Likewise, local storage systems have within other types of storage systems. Likewise, local storage
an annoying tendency to prefer user-friendliness over security when systems have an annoying tendency to prefer user-friendliness over
handling invalid or unexpected characters, recomposition of security when handling invalid or unexpected characters,
decomposed characters, and case-normalization of case-insensitive recomposition of decomposed characters, and case-normalization of
names. case-insensitive names.
Attacks based on such special names tend to focus on either denial of Attacks based on such special names tend to focus on either denial-
service (e.g., telling the server to read from a COM port) or of-service (e.g., telling the server to read from a COM port) or
disclosure of configuration and source files that are not meant to be disclosure of configuration and source files that are not meant to be
served. served.
9.2. Attacks Based On Command, Code, or Query Injection 9.2. Attacks Based on Command, Code, or Query Injection
Origin servers often use parameters within the URI as a means of Origin servers often use parameters within the URI as a means of
identifying system services, selecting database entries, or choosing identifying system services, selecting database entries, or choosing
a data source. However, data received in a request cannot be a data source. However, data received in a request cannot be
trusted. An attacker could construct any of the request data trusted. An attacker could construct any of the request data
elements (method, request-target, header fields, or body) to contain elements (method, request-target, header fields, or body) to contain
data that might be misinterpreted as a command, code, or query when data that might be misinterpreted as a command, code, or query when
passed through a command invocation, language interpreter, or passed through a command invocation, language interpreter, or
database interface. database interface.
skipping to change at page 82, line 41 skipping to change at page 83, line 41
of sensitive data because that data will be placed in the request- of sensitive data because that data will be placed in the request-
target. Many existing servers, proxies, and user agents log or target. Many existing servers, proxies, and user agents log or
display the request-target in places where it might be visible to display the request-target in places where it might be visible to
third parties. Such services ought to use POST-based form submission third parties. Such services ought to use POST-based form submission
instead. instead.
Since the Referer header field tells a target site about the context Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any information about the user's immediate browsing history and any
personal information that might be found in the referring resource's personal information that might be found in the referring resource's
URI. Limitations on Referer are described in Section 5.5.2 to URI. Limitations on the Referer header field are described in
address some of its security considerations. Section 5.5.2 to address some of its security considerations.
9.5. Disclosure of Fragment after Redirects 9.5. Disclosure of Fragment after Redirects
Although fragment identifiers used within URI references are not sent Although fragment identifiers used within URI references are not sent
in requests, implementers ought to be aware that they will be visible in requests, implementers ought to be aware that they will be visible
to the user agent and any extensions or scripts running as a result to the user agent and any extensions or scripts running as a result
of the response. In particular, when a redirect occurs and the of the response. In particular, when a redirect occurs and the
original request's fragment identifier is inherited by the new original request's fragment identifier is inherited by the new
reference in Location (Section 7.1.2), this might have the effect of reference in Location (Section 7.1.2), this might have the effect of
disclosing one site's fragment to another site. If the first site disclosing one site's fragment to another site. If the first site
uses personal information in fragments, it ought to ensure that uses personal information in fragments, it ought to ensure that
redirects to other sites include a (possibly empty) fragment redirects to other sites include a (possibly empty) fragment
component in order to block that inheritance. component in order to block that inheritance.
9.6. Disclosure of Product Information 9.6. Disclosure of Product Information
The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [Part1]), and The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [RFC7230]), and
Server (Section 7.4.2) header fields often reveal information about Server (Section 7.4.2) header fields often reveal information about
the respective sender's software systems. In theory, this can make the respective sender's software systems. In theory, this can make
it easier for an attacker to exploit known security holes; in it easier for an attacker to exploit known security holes; in
practice, attackers tend to try all potential holes regardless of the practice, attackers tend to try all potential holes regardless of the
apparent software versions being used. apparent software versions being used.
Proxies that serve as a portal through a network firewall ought to Proxies that serve as a portal through a network firewall ought to
take special precautions regarding the transfer of header information take special precautions regarding the transfer of header information
that might identify hosts behind the firewall. The Via header field that might identify hosts behind the firewall. The Via header field
allows intermediaries to replace sensitive machine names with allows intermediaries to replace sensitive machine names with
skipping to change at page 84, line 27 skipping to change at page 85, line 27
In environments where proxies are used to enhance privacy, user In environments where proxies are used to enhance privacy, user
agents ought to be conservative in sending proactive negotiation agents ought to be conservative in sending proactive negotiation
header fields. General-purpose user agents that provide a high header fields. General-purpose user agents that provide a high
degree of header field configurability ought to inform users about degree of header field configurability ought to inform users about
the loss of privacy that might result if too much detail is provided. the loss of privacy that might result if too much detail is provided.
As an extreme privacy measure, proxies could filter the proactive As an extreme privacy measure, proxies could filter the proactive
negotiation header fields in relayed requests. negotiation header fields in relayed requests.
10. Acknowledgments 10. Acknowledgments
See Section 10 of [Part1]. See Section 10 of [RFC7230].
11. References 11. References
11.1. Normative References 11.1. Normative References
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Transfer Protocol (HTTP/1.1): Message Syntax and Extensions (MIME) Part One: Format of Internet Message
Routing", draft-ietf-httpbis-p1-messaging-26 (work in Bodies", RFC 2045, November 1996.
progress), February 2014.
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Transfer Protocol (HTTP/1.1): Conditional Requests", Extensions (MIME) Part Two: Media Types", RFC 2046,
draft-ietf-httpbis-p4-conditional-26 (work in November 1996.
progress), February 2014.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
"Hypertext Transfer Protocol (HTTP/1.1): Range Requirement Levels", BCP 14, RFC 2119, March 1997.
Requests", draft-ietf-httpbis-p5-range-26 (work in
progress), February 2014.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Resource Identifier (URI): Generic Syntax", STD 66,
draft-ietf-httpbis-p6-cache-26 (work in progress), RFC 3986, January 2005.
February 2014.
[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
Transfer Protocol (HTTP/1.1): Authentication", Tags", BCP 47, RFC 4647, September 2006.
draft-ietf-httpbis-p7-auth-26 (work in progress),
February 2014.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Mail Extensions (MIME) Part One: Format of Internet Specifications: ABNF", STD 68, RFC 5234, January 2008.
Message Bodies", RFC 2045, November 1996.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Mail Extensions (MIME) Part Two: Media Types", Languages", BCP 47, RFC 5646, September 2009.
RFC 2046, November 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Requirement Levels", BCP 14, RFC 2119, March 1997. Internationalization in the IETF", BCP 166, RFC 6365,
September 2011.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"Uniform Resource Identifier (URI): Generic Syntax", Protocol (HTTP/1.1): Message Syntax and Routing",
STD 66, RFC 3986, January 2005. draft-ietf-httpbis-p1-messaging-latest (work in progress),
June 2014.
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Language Tags", BCP 47, RFC 4647, September 2006. Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-latest (work in
progress), June 2014.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
Syntax Specifications: ABNF", STD 68, RFC 5234, "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
January 2008. draft-ietf-httpbis-p5-range-latest (work in progress),
June 2014.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Identifying Languages", BCP 47, RFC 5646, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
September 2009. draft-ietf-httpbis-p6-cache-latest (work in progress),
June 2014.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Internationalization in the IETF", BCP 166, RFC 6365, Protocol (HTTP/1.1): Authentication",
September 2011. draft-ietf-httpbis-p7-auth-latest (work in progress),
June 2014.
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, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012. 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,
RFC 3864, September 2004. September 2004.
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
Applications and Web Services", The Open Web Applications and Web Services", The Open Web Application
Application Security Project (OWASP) 2.0.1, July 2005, Security Project (OWASP) 2.0.1, July 2005,
<https://www.owasp.org/>. <https://www.owasp.org/>.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Network-based Software Architectures",
Doctoral Dissertation, University of California, Doctoral Dissertation, University of California, Irvine,
Irvine, September 2000, September 2000,
<http://roy.gbiv.com/pubs/dissertation/top.htm>. <http://roy.gbiv.com/pubs/dissertation/top.htm>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
"Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, 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
Mail Extensions (MIME) Part Five: Conformance Criteria Extensions (MIME) Part Five: Conformance Criteria and
and Examples", RFC 2049, November 1996. 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.
T. Berners-Lee, "Hypertext Transfer Protocol -- Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
HTTP/1.1", RFC 2068, January 1997. RFC 2068, January 1997.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
Negotiation in HTTP", RFC 2295, March 1998. in HTTP", RFC 2295, March 1998.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, August 1998. form-data", RFC 2388, August 1998.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as "MIME Encapsulation of Aggregate Documents, such as HTML
HTML (MHTML)", RFC 2557, March 1999. (MHTML)", RFC 2557, March 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP [RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP
Extension Framework", RFC 2774, February 2000. Extension Framework", RFC 2774, February 2000.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, May 2000.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000. Procedures", BCP 19, RFC 2978, October 2000.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
an IANA Considerations Section in RFCs", BCP 26, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
RFC 5226, May 2008. May 2008.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
Security (TLS) Protocol Version 1.2", RFC 5246, (TLS) Protocol Version 1.2", RFC 5246, August 2008.
August 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, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and "Network Time Protocol Version 4: Protocol and Algorithms
Algorithms Specification", RFC 5905, June 2010. 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 Field
Field in the Hypertext Transfer Protocol (HTTP)", in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
RFC 6266, June 2011. June 2011.
[status-308] Reschke, J., "The Hypertext Transfer Protocol (HTTP) [RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Status Code 308 (Permanent Redirect)", Status Code 308 (Permanent Redirect)",
draft-reschke-http-status-308-07 (work in progress), draft-reschke-http-status-308-07 (work in progress),
March 2012. March 2012.
Appendix A. Differences between HTTP and MIME Appendix A. Differences between HTTP and MIME
HTTP/1.1 uses many of the constructs defined for the Internet Message HTTP/1.1 uses many of the constructs defined for the Internet Message
Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
[RFC2045] to allow a message body to be transmitted in an open [RFC2045] to allow a message body to be transmitted in an open
variety of representations and with extensible header fields. variety of representations and with extensible header fields.
However, RFC 2045 is focused only on email; applications of HTTP have However, RFC 2045 is focused only on email; applications of HTTP have
many characteristics that differ from email, and hence HTTP has many characteristics that differ from email; hence, HTTP has features
features that differ from MIME. These differences were carefully that differ from MIME. These differences were carefully chosen to
chosen to optimize performance over binary connections, to allow optimize performance over binary connections, to allow greater
greater freedom in the use of new media types, to make date freedom in the use of new media types, to make date comparisons
comparisons easier, and to acknowledge the practice of some early easier, and to acknowledge the practice of some early HTTP servers
HTTP servers and clients. and clients.
This appendix describes specific areas where HTTP differs from MIME. This appendix describes specific areas where HTTP differs from MIME.
Proxies and gateways to and from strict MIME environments need to be Proxies and gateways to and from strict MIME environments need to be
aware of these differences and provide the appropriate conversions aware of these differences and provide the appropriate conversions
where necessary. where necessary.
A.1. MIME-Version A.1. MIME-Version
HTTP is not a MIME-compliant protocol. However, messages can include HTTP is not a MIME-compliant protocol. However, messages can include
a single MIME-Version header field to indicate what version of the a single MIME-Version header field to indicate what version of the
skipping to change at page 89, line 41 skipping to change at page 90, line 36
A.6. MHTML and Line Length Limitations A.6. MHTML and Line Length Limitations
HTTP implementations that share code with MHTML [RFC2557] HTTP implementations that share code with MHTML [RFC2557]
implementations need to be aware of MIME line length limitations. implementations need to be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line length limitations and folding, conventions of MHTML, including line length limitations and folding,
canonicalization, etc., since HTTP transfers message-bodies as canonicalization, etc., since HTTP transfers message-bodies as
payload and, aside from the "multipart/byteranges" type (Appendix A payload and, aside from the "multipart/byteranges" type (Appendix A
of [Part5]), does not interpret the content or any MIME header lines of [RFC7233]), does not interpret the content or any MIME header
that might be contained therein. lines that might be contained therein.
Appendix B. Changes from RFC 2616 Appendix B. Changes from RFC 2616
The primary changes in this revision have been editorial in nature: The primary changes in this revision have been editorial in nature:
extracting the messaging syntax and partitioning HTTP semantics into extracting the messaging syntax and partitioning HTTP semantics into
separate documents for the core features, conditional requests, separate documents for the core features, conditional requests,
partial requests, caching, and authentication. The conformance partial requests, caching, and authentication. The conformance
language has been revised to clearly target requirements and the language has been revised to clearly target requirements and the
terminology has been improved to distinguish payload from terminology has been improved to distinguish payload from
representations and representations from resources. representations and representations from resources.
A new requirement has been added that semantics embedded in a URI A new requirement has been added that semantics embedded in a URI be
should be disabled when those semantics are inconsistent with the disabled when those semantics are inconsistent with the request
request method, since this is a common cause of interoperability method, since this is a common cause of interoperability failure.
failure. (Section 2)
(Section 2)
An algorithm has been added for determining if a payload is An algorithm has been added for determining if a payload is
associated with a specific identifier. (Section 3.1.4.1) associated with a specific identifier. (Section 3.1.4.1)
The default charset of ISO-8859-1 for text media types has been The default charset of ISO-8859-1 for text media types has been
removed; the default is now whatever the media type definition says. removed; the default is now whatever the media type definition says.
Likewise, special treatment of ISO-8859-1 has been removed from the Likewise, special treatment of ISO-8859-1 has been removed from the
Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3) Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3)
The definition of Content-Location has been changed to no longer The definition of Content-Location has been changed to no longer
affect the base URI for resolving relative URI references, due to affect the base URI for resolving relative URI references, due to
poor implementation support and the undesirable effect of potentially poor implementation support and the undesirable effect of potentially
breaking relative links in content-negotiated resources. breaking relative links in content-negotiated resources.
(Section 3.1.4.2) (Section 3.1.4.2)
To be consistent with the method-neutral parsing algorithm of To be consistent with the method-neutral parsing algorithm of
[Part1], the definition of GET has been relaxed so that requests can [RFC7230], the definition of GET has been relaxed so that requests
have a body, even though a body has no meaning for GET. can have a body, even though a body has no meaning for GET.
(Section 4.3.1) (Section 4.3.1)
Servers are no longer required to handle all Content-* header fields Servers are no longer required to handle all Content-* header fields
and use of Content-Range has been explicitly banned in PUT requests. and use of Content-Range has been explicitly banned in PUT requests.
(Section 4.3.4) (Section 4.3.4)
Definition of the CONNECT method has been moved from [RFC2817] to Definition of the CONNECT method has been moved from [RFC2817] to
this specification. (Section 4.3.6) this specification. (Section 4.3.6)
The OPTIONS and TRACE request methods have been defined as being The OPTIONS and TRACE request methods have been defined as being
skipping to change at page 91, line 23 skipping to change at page 92, line 20
The set of request methods that are safe to automatically redirect is The set of request methods that are safe to automatically redirect is
no longer closed; user agents are able to make that determination no longer closed; user agents are able to make that determination
based upon the request method semantics. The redirect status codes based upon the request method semantics. The redirect status codes
301, 302, and 307 no longer have normative requirements on response 301, 302, and 307 no longer have normative requirements on response
payloads and user interaction. (Section 6.4) payloads and user interaction. (Section 6.4)
The status codes 301 and 302 have been changed to allow user agents The status codes 301 and 302 have been changed to allow user agents
to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3) to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3)
The description of 303 (See Other) status code has been changed to The description of the 303 (See Other) status code has been changed
allow it to be cached if explicit freshness information is given, and to allow it to be cached if explicit freshness information is given,
a specific definition has been added for a 303 response to GET. and a specific definition has been added for a 303 response to GET.
(Section 6.4.4) (Section 6.4.4)
The 305 (Use Proxy) status code has been deprecated due to security The 305 (Use Proxy) status code has been deprecated due to security
concerns regarding in-band configuration of a proxy. (Section 6.4.5) concerns regarding in-band configuration of a proxy. (Section 6.4.5)
The 400 (Bad Request) status code has been relaxed so that it isn't The 400 (Bad Request) status code has been relaxed so that it isn't
limited to syntax errors. (Section 6.5.1) limited to syntax errors. (Section 6.5.1)
The 426 (Upgrade Required) status code has been incorporated from The 426 (Upgrade Required) status code has been incorporated from
[RFC2817]. (Section 6.5.15) [RFC2817]. (Section 6.5.15)
skipping to change at page 92, line 4 skipping to change at page 92, line 49
URI references, including relative references and fragments, along URI references, including relative references and fragments, along
with some clarifications as to when use of fragments would not be with some clarifications as to when use of fragments would not be
appropriate. (Section 7.1.2) appropriate. (Section 7.1.2)
Allow has been reclassified as a response header field, removing the Allow has been reclassified as a response header field, removing the
option to specify it in a PUT request. Requirements relating to the option to specify it in a PUT request. Requirements relating to the
content of Allow have been relaxed; correspondingly, clients are not content of Allow have been relaxed; correspondingly, clients are not
required to always trust its value. (Section 7.4.1) required to always trust its value. (Section 7.4.1)
A Method Registry has been defined. (Section 8.1) A Method Registry has been defined. (Section 8.1)
The Status Code Registry has been redefined by this specification; The Status Code Registry has been redefined by this specification;
previously, it was defined in Section 7.1 of [RFC2817]. previously, it was defined in Section 7.1 of [RFC2817].
(Section 8.2) (Section 8.2)
Registration of Content Codings has been changed to require IETF Registration of content codings has been changed to require IETF
Review. (Section 8.4) Review. (Section 8.4)
The Content-Disposition header field has been removed since it is now The Content-Disposition header field has been removed since it is now
defined by [RFC6266]. defined by [RFC6266].
The Content-MD5 header field has been removed because it was The Content-MD5 header field has been removed because it was
inconsistently implemented with respect to partial responses. inconsistently implemented with respect to partial responses.
Appendix C. Imported ABNF Appendix C. Imported ABNF
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
(line feed), OCTET (any 8-bit sequence of data), SP (space), and (line feed), OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). VCHAR (any visible US-ASCII character).
The rules below are defined in [Part1]: The rules below are defined in [RFC7230]:
BWS = <BWS, defined in [Part1], Section 3.2.3> BWS = <BWS, see [RFC7230], Section 3.2.3>
OWS = <OWS, defined in [Part1], Section 3.2.3> OWS = <OWS, see [RFC7230], Section 3.2.3>
RWS = <RWS, defined in [Part1], Section 3.2.3> RWS = <RWS, see [RFC7230], Section 3.2.3>
URI-reference = <URI-reference, defined in [Part1], Section 2.7> URI-reference = <URI-reference, see [RFC7230], Section 2.7>
absolute-URI = <absolute-URI, defined in [Part1], Section 2.7> absolute-URI = <absolute-URI, see [RFC7230], Section 2.7>
comment = <comment, defined in [Part1], Section 3.2.6> comment = <comment, see [RFC7230], Section 3.2.6>
field-name = <comment, defined in [Part1], Section 3.2> field-name = <comment, see [RFC7230], Section 3.2>
partial-URI = <partial-URI, defined in [Part1], Section 2.7> partial-URI = <partial-URI, see [RFC7230], Section 2.7>
quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
token = <token, defined in [Part1], Section 3.2.6> token = <token, see [RFC7230], Section 3.2.6>
Appendix D. Collected ABNF Appendix D. Collected ABNF
In the collected ABNF below, list rules are expanded as per Section In the collected ABNF below, list rules are expanded as per Section
1.2 of [Part1]. 1.2 of [RFC7230].
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ] OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ] ( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] ) "," [ OWS ( language-range [ weight ] ) ] )
Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
BWS = <BWS, see [RFC7230], Section 3.2.3>
BWS = <BWS, defined in [Part1], Section 3.2.3>
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
content-coding ] ) content-coding ] )
Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
language-tag ] ) language-tag ] )
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
Content-Type = media-type Content-Type = media-type
Date = HTTP-date Date = HTTP-date
skipping to change at page 93, line 32 skipping to change at page 94, line 29
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, see [RFC7230], Section 3.2.3>
RWS = <RWS, defined in [Part1], Section 3.2.3> RWS = <RWS, see [RFC7230], Section 3.2.3>
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-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, see [RFC7230], 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, see [RFC7230], Section 2.7>
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
accept-params = weight *accept-ext accept-params = weight *accept-ext
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
charset = token charset = token
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
comment = <comment, defined in [Part1], Section 3.2.6> comment = <comment, see [RFC7230], Section 3.2.6>
content-coding = token content-coding = token
date1 = day SP month SP year date1 = day SP month SP year
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
day = 2DIGIT day = 2DIGIT
day-name = %x4D.6F.6E ; Mon day-name = %x4D.6F.6E ; Mon
/ %x54.75.65 ; Tue / %x54.75.65 ; Tue
/ %x57.65.64 ; Wed / %x57.65.64 ; Wed
/ %x54.68.75 ; Thu / %x54.68.75 ; Thu
/ %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
delay-seconds = 1*DIGIT delay-seconds = 1*DIGIT
field-name = <comment, defined in [Part1], Section 3.2> field-name = <comment, see [RFC7230], Section 3.2>
hour = 2DIGIT hour = 2DIGIT
language-range = <language-range, defined in [RFC4647], Section 2.1> language-range = <language-range, see [RFC4647], Section 2.1>
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> language-tag = <Language-Tag, see [RFC5646], Section 2.1>
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" OWS parameter ) ";" OWS parameter )
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
method = token method = token
minute = 2DIGIT minute = 2DIGIT
month = %x4A.61.6E ; Jan month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb / %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar / %x4D.61.72 ; Mar
/ %x41.70.72 ; Apr / %x41.70.72 ; Apr
/ %x4D.61.79 ; May / %x4D.61.79 ; May
skipping to change at page 95, line 6 skipping to change at page 96, line 4
/ %x4D.61.79 ; May / %x4D.61.79 ; May
/ %x4A.75.6E ; Jun / %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul / %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug / %x41.75.67 ; Aug
/ %x53.65.70 ; Sep / %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct / %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov / %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec / %x44.65.63 ; Dec
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
parameter = token "=" ( token / quoted-string ) parameter = token "=" ( token / quoted-string )
partial-URI = <partial-URI, defined in [Part1], Section 2.7> partial-URI = <partial-URI, see [RFC7230], Section 2.7>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
quoted-string = <quoted-string, defined in [Part1], Section 3.2.6> quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
second = 2DIGIT second = 2DIGIT
subtype = token subtype = token
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
token = <token, defined in [Part1], Section 3.2.6> token = <token, see [RFC7230], Section 3.2.6>
type = token type = token
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT year = 4DIGIT
Appendix E. Change Log (to be removed by RFC Editor before publication)
E.1. Since RFC 2616
Changes up to the IETF Last Call draft are summarized in <http://
trac.tools.ietf.org/html/
draft-ietf-httpbis-p2-semantics-24#appendix-E>.
E.2. Since draft-ietf-httpbis-p2-semantics-24
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/432>: "Review
Cachability of Status Codes WRT 'Negative Caching'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/499>: "RFC 1305 ref
needs to be updated to 5905"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/501>: "idempotency:
clarify 'effect'"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/503>: "APPSDIR
review of draft-ietf-httpbis-p2-semantics-24"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/517>: "move IANA
registrations to correct draft"
E.3. Since draft-ietf-httpbis-p2-semantics-25
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/520>: "Gen-Art
review of draft-ietf-httpbis-p2-semantics-24 with security
considerations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/532>: "IESG ballot
on draft-ietf-httpbis-p2-semantics-25"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
'stateless' to Abstract"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
introduction of list rule"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/545>: "requirement
on implementing methods according to their semantics"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/546>:
"considerations for new headers: privacy"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
security considerations with pointers to current research"
Index Index
1 1
1xx Informational (status code class) 49 1xx Informational (status code class) 50
2 2
2xx Successful (status code class) 50 2xx Successful (status code class) 51
3 3
3xx Redirection (status code class) 53 3xx Redirection (status code class) 54
4 4
4xx Client Error (status code class) 57 4xx Client Error (status code class) 58
5 5
5xx Server Error (status code class) 61 5xx Server Error (status code class) 62
1 1
100 Continue (status code) 49 100 Continue (status code) 50
100-continue (expect value) 33 100-continue (expect value) 34
101 Switching Protocols (status code) 49 101 Switching Protocols (status code) 50
2 2
200 OK (status code) 50 200 OK (status code) 51
201 Created (status code) 51 201 Created (status code) 51
202 Accepted (status code) 51 202 Accepted (status code) 52
203 Non-Authoritative Information (status code) 51 203 Non-Authoritative Information (status code) 52
204 No Content (status code) 52 204 No Content (status code) 53
205 Reset Content (status code) 52 205 Reset Content (status code) 53
3 3
300 Multiple Choices (status code) 54 300 Multiple Choices (status code) 55
301 Moved Permanently (status code) 55 301 Moved Permanently (status code) 56
302 Found (status code) 55 302 Found (status code) 56
303 See Other (status code) 56 303 See Other (status code) 57
305 Use Proxy (status code) 56 305 Use Proxy (status code) 57
306 (Unused) (status code) 56 306 (Unused) (status code) 57
307 Temporary Redirect (status code) 57 307 Temporary Redirect (status code) 58
4 4
400 Bad Request (status code) 57 400 Bad Request (status code) 58
402 Payment Required (status code) 57 402 Payment Required (status code) 58
403 Forbidden (status code) 57 403 Forbidden (status code) 58
404 Not Found (status code) 58 404 Not Found (status code) 59
405 Method Not Allowed (status code) 58 405 Method Not Allowed (status code) 59
406 Not Acceptable (status code) 58 406 Not Acceptable (status code) 59
408 Request Timeout (status code) 59 408 Request Timeout (status code) 60
409 Conflict (status code) 59 409 Conflict (status code) 60
410 Gone (status code) 59 410 Gone (status code) 60
411 Length Required (status code) 60 411 Length Required (status code) 61
413 Payload Too Large (status code) 60 413 Payload Too Large (status code) 61
414 URI Too Long (status code) 60 414 URI Too Long (status code) 61
415 Unsupported Media Type (status code) 60 415 Unsupported Media Type (status code) 61
417 Expectation Failed (status code) 61 417 Expectation Failed (status code) 62
426 Upgrade Required (status code) 61 426 Upgrade Required (status code) 62
5 5
500 Internal Server Error (status code) 61 500 Internal Server Error (status code) 62
501 Not Implemented (status code) 62 501 Not Implemented (status code) 63
502 Bad Gateway (status code) 62 502 Bad Gateway (status code) 63
503 Service Unavailable (status code) 62 503 Service Unavailable (status code) 63
504 Gateway Timeout (status code) 62 504 Gateway Timeout (status code) 63
505 HTTP Version Not Supported (status code) 62 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
Allow header field 71 Allow header field 72
C C
cacheable 24 cacheable 24
compress (content coding) 11 compress (content coding) 11
conditional request 36 conditional request 36
CONNECT method 30 CONNECT method 30
content coding 11 content coding 11
content negotiation 6 content negotiation 6
Content-Encoding header field 12 Content-Encoding header field 12
Content-Language header field 13 Content-Language header field 13
Content-Location header field 15 Content-Location header field 15
Content-Transfer-Encoding header field 89 Content-Transfer-Encoding header field 90
Content-Type header field 10 Content-Type header field 10
D D
Date header field 66 Date header field 67
deflate (content coding) 11 deflate (content coding) 11
DELETE method 29 DELETE method 29
E E
Expect header field 33 Expect header field 34
F F
From header field 44 From header field 44
G G
GET method 24 GET method 24
Grammar Grammar
Accept 38 Accept 38
Accept-Charset 40 Accept-Charset 40
Accept-Encoding 41 Accept-Encoding 41
accept-ext 38 accept-ext 38
Accept-Language 42 Accept-Language 42
accept-params 38 accept-params 38
Allow 71 Allow 72
asctime-date 66 asctime-date 67
charset 9 charset 9
codings 41 codings 41
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 66 Date 67
date1 65 date1 66
day 65 day 66
day-name 65 day-name 66
day-name-l 65 day-name-l 66
delay-seconds 69 delay-seconds 70
Expect 34 Expect 34
From 44 From 44
GMT 65 GMT 66
hour 65 hour 66
HTTP-date 63 HTTP-date 64
IMF-fixdate 65 IMF-fixdate 66
language-range 42 language-range 42
language-tag 13 language-tag 13
Location 67 Location 68
Max-Forwards 36 Max-Forwards 36
media-range 38 media-range 38
media-type 8 media-type 8
method 21 method 21
minute 65 minute 66
month 65 month 66
obs-date 65 obs-date 66
parameter 8 parameter 8
product 46 product 46
product-version 46 product-version 46
qvalue 38 qvalue 38
Referer 45 Referer 45
Retry-After 69 Retry-After 70
rfc850-date 66 rfc850-date 67
second 65 second 66
Server 72 Server 73
subtype 8 subtype 8
time-of-day 65 time-of-day 66
type 8 type 8
User-Agent 46 User-Agent 46
Vary 69 Vary 70
weight 38 weight 38
year 65 year 66
gzip (content coding) 11 gzip (content coding) 11
H H
HEAD method 25 HEAD method 25
I I
idempotent 23 idempotent 23
L L
Location header field 67 Location header field 68
M M
Max-Forwards header field 36 Max-Forwards header field 36
MIME-Version header field 88 MIME-Version header field 89
O O
OPTIONS method 31 OPTIONS method 31
P P
payload 17 payload 17
POST method 25 POST method 25
PUT method 26 PUT method 26
R R
Referer header field 44 Referer header field 45
representation 7 representation 7
Retry-After header field 68 Retry-After header field 69
S S
safe 22 safe 22
selected representation 7, 70 selected representation 7, 71
Server header field 72 Server header field 73
Status Codes Classes Status Codes Classes
1xx Informational 49 1xx Informational 50
2xx Successful 50 2xx Successful 51
3xx Redirection 53 3xx Redirection 54
4xx Client Error 57 4xx Client Error 58
5xx Server Error 61 5xx Server Error 62
T T
TRACE method 32 TRACE method 32
U U
User-Agent header field 46 User-Agent header field 46
V V
Vary header field 69 Vary header field 70
X X
x-compress (content coding) 11 x-compress (content coding) 11
x-gzip (content coding) 11 x-gzip (content coding) 11
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe Systems Incorporated
345 Park Ave 345 Park Ave
 End of changes. 261 change blocks. 
768 lines changed or deleted 715 lines changed or added

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