draft-ietf-httpbis-p2-semantics-23.txt   draft-ietf-httpbis-p2-semantics-24.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 July 15, 2013 Intended status: Standards Track September 25, 2013
Expires: January 16, 2014 Expires: March 29, 2014
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
draft-ietf-httpbis-p2-semantics-23 draft-ietf-httpbis-p2-semantics-24
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is an application-level The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypertext information protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP/1.1 messages, systems. This document defines the semantics of HTTP/1.1 messages,
as expressed by request methods, request header fields, response as expressed by request methods, request header fields, response
status codes, and response header fields, along with the payload of status codes, and response header fields, along with the payload of
messages (metadata and body content) and mechanisms for content messages (metadata and body content) and mechanisms for content
negotiation. negotiation.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>. <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>. <http://tools.ietf.org/wg/httpbis/>.
The changes in this draft are summarized in Appendix E.3. The changes in this draft are summarized in Appendix E.4.
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 January 16, 2014. This Internet-Draft will expire on March 29, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7 3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8
3.1.1. Processing the 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 . . . . . . . . . . . . . . . . 18 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19
3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 19 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20
4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 20 4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 20 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 . . . . . . . . . . . . . . . . . . 23 4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24
4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 23 4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24
4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 24 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 . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 29 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 . . . . . . . . . . . . . . . . . . . . 32 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33
5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 32 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 . . . . . . . . . . . . . . . . . . . . . . 45 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 . . . . . . . . . . . . . . . . . 47
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 . . . . . . . . . . . . . . . 50 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 . . . . . . . . . . . . . . . . . . . . . 52
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 . . . . . . . . . . . . . . . . . 61 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 62
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 . . . . . . . . . . . . . . . . . . . . 62 7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 63
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 . . . . . . . . . . . . . . . . . . . . . . . 66 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68
7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 68 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69
7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70
7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 69 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71
7.3. Authentication Challenges . . . . . . . . . . . . . . . . 70 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72
7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 70 7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72
7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 71 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 71 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73
8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 72 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74
8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 72 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74
8.1.2. Considerations for New Methods . . . . . . . . . . . . 72 8.1.2. Considerations for New Methods . . . . . . . . . . . . 74
8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 73 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75
8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 73 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75
8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 73 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75
8.2.2. Considerations for New Status Codes . . . . . . . . . 74 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 . . . . . . . . . . . . . . . . . . . . . . 79 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 80
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 . . . . . . . . . . . 80 9.1. Attacks Based On File and Path Names . . . . . . . . . . . 81
9.2. Personal Information . . . . . . . . . . . . . . . . . . . 81 9.2. Personal Information . . . . . . . . . . . . . . . . . . . 82
9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 81 9.3. Sensitive Information in URIs . . . . . . . . . . . . . . 82
9.4. Product Information . . . . . . . . . . . . . . . . . . . 82 9.4. Product Information . . . . . . . . . . . . . . . . . . . 83
9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 82 9.5. Fragment after Redirects . . . . . . . . . . . . . . . . . 83
9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 82 9.6. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 83
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 83 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 84
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 84
11.1. Normative References . . . . . . . . . . . . . . . . . . . 83 11.1. Normative References . . . . . . . . . . . . . . . . . . . 84
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 . . . . . . . . . . . . . . . . . . . . . . . 87 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 88
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 87 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 88
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 88 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89
A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 88 A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89
A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 88 A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 89
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 88 A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 89
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 89 Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 91 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 92
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93
Appendix E. Change Log (to be removed by RFC Editor before Appendix E. Change Log (to be removed by RFC Editor before
publication) . . . . . . . . . . . . . . . . . . . . 95 publication) . . . . . . . . . . . . . . . . . . . . 96
E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 95 E.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 96
E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 95 E.2. Since draft-ietf-httpbis-p2-semantics-21 . . . . . . . . . 96
E.3. Since draft-ietf-httpbis-p2-semantics-22 . . . . . . . . . 96 E.3. Since draft-ietf-httpbis-p2-semantics-22 . . . . . . . . . 97
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 E.4. Since draft-ietf-httpbis-p2-semantics-23 . . . . . . . . . 97
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
1. Introduction 1. Introduction
Each Hypertext Transfer Protocol (HTTP) message is either a request Each Hypertext Transfer Protocol (HTTP) message is either a request
or a response. A server listens on a connection for a request, or a response. A server listens on a connection for a request,
parses each message received, interprets the message semantics in parses each message received, interprets the message semantics in
relation to the identified request target, and responds to that relation to the identified request target, and responds to that
request with one or more response messages. A client constructs request with one or more response messages. A client constructs
request messages to communicate specific intentions, and examines request messages to communicate specific intentions, and examines
received responses to see if the intentions were carried out and received responses to see if the intentions were carried out and
skipping to change at page 6, line 48 skipping to change at page 6, line 48
"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 [Part1].
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 the list rule extension defined in Section notation of [RFC5234] with the list rule extension defined in Section
1.2 of [Part1]. Appendix C describes rules imported from other 7 of [Part1]. Appendix C describes rules imported from other
documents. Appendix D shows the collected ABNF with the list rule documents. Appendix D shows the collected ABNF with the list rule
expanded. expanded.
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 each HTTP request is called a resource. HTTP does not The target of an HTTP request is called a resource. HTTP does not
limit the nature of a resource; it merely defines an interface that limit the nature of a resource; it merely defines an interface that
might be used to interact with resources. Each resource is 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 [Part1].
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 [Part1]). 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]). [Part1]).
skipping to change at page 8, line 18 skipping to change at page 8, line 18
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
representation data that would have been enclosed in the payload body representation data that would have been enclosed in the payload body
if the same request had been a GET. if the same request had been a GET.
The following header fields are defined to convey representation The following header fields convey representation metadata:
metadata:
+-------------------+-----------------+ +-------------------+-----------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+-----------------+ +-------------------+-----------------+
| 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 the 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.
skipping to change at page 10, line 9 skipping to change at page 10, line 8
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
common to HTTP and the Web (server-based information services). common to HTTP and the Web (server-based information services).
Furthermore, MIME's constraints for the sake of compatibility with Furthermore, MIME's constraints for the sake of compatibility with
older mail transfer protocols do not apply to HTTP (see Appendix A). older mail transfer protocols do not apply to HTTP (see Appendix A).
MIME's canonical form requires that media subtypes of the "text" type MIME's canonical form requires that media subtypes of the "text" type
use CRLF as the text line break. HTTP allows the transfer of text use CRLF as the text line break. HTTP allows the transfer of text
media with plain CR or LF alone representing a line break, when such media with plain CR or LF alone representing a line break, when such
line breaks are consistent for an entire representation. HTTP line breaks are consistent for an entire representation. An HTTP
senders MAY generate, and recipients MUST be able to parse, line sender MAY generate, and a recipient MUST be able to parse, line
breaks in text media that consist of CRLF, bare CR, or bare LF. In breaks in text media that consist of CRLF, bare CR, or bare LF. In
addition, text media in HTTP is not limited to charsets that use addition, text media in HTTP is not limited to charsets that use
octets 13 and 10 for CR and LF, respectively. This flexibility octets 13 and 10 for CR and LF, respectively. This flexibility
regarding line breaks applies only to text within a representation regarding line breaks applies only to text within a representation
that has been assigned a "text" media type; it does not apply to that has been assigned a "text" media type; it does not apply to
"multipart" types or HTTP elements outside the payload body (e.g., "multipart" types or HTTP elements outside the payload body (e.g.,
header fields). header fields).
If a representation is encoded with a content-coding, the underlying If a representation is encoded with a content-coding, the underlying
data ought to be in a form defined above prior to being encoded. data ought to be in a form defined above prior to being encoded.
skipping to change at page 11, line 5 skipping to change at page 11, line 4
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.
Content-Type = media-type Content-Type = media-type
Media types are defined in Section 3.1.1.1. An example of the field Media types are defined in Section 3.1.1.1. An example of the field
is is
Content-Type: text/html; charset=ISO-8859-4 Content-Type: text/html; charset=ISO-8859-4
A sender that generates a message containing a payload body SHOULD A sender that generates a message containing a payload body SHOULD
generate a Content-Type header field in that message unless the generate a Content-Type header field in that message unless the
intended media type of the enclosed representation is unknown to the intended media type of the enclosed representation is unknown to the
sender. If a Content-Type header field is not present, recipients sender. If a Content-Type header field is not present, the recipient
MAY either assume a media type of "application/octet-stream" MAY either assume a media type of "application/octet-stream"
([RFC2046], Section 4.5.1) or examine the data to determine its type. ([RFC2046], Section 4.5.1) or examine the data to determine its type.
In practice, resource owners do not always properly configure their In practice, resource owners do not always properly configure their
origin server to provide the correct Content-Type for a given origin server to provide the correct Content-Type for a given
representation, with the result that some clients will examine a representation, with the result that some clients will examine a
payload's content and override the specified type. Clients that do payload's content and override the specified type. Clients that do
so risk drawing incorrect conclusions, which might expose additional so risk drawing incorrect conclusions, which might expose additional
security risks (e.g., "privilege escalation"). Furthermore, it is security risks (e.g., "privilege escalation"). Furthermore, it is
impossible to determine the sender's intent by examining the data impossible to determine the sender's intent by examining the data
skipping to change at page 11, line 36 skipping to change at page 11, line 34
3.1.2. Encoding for Compression or Integrity 3.1.2. Encoding for Compression or Integrity
3.1.2.1. Content Codings 3.1.2.1. Content Codings
Content coding values indicate an encoding transformation that has Content coding values indicate an encoding transformation that has
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 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:
skipping to change at page 12, line 23 skipping to change at page 12, line 21
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.
Content-Encoding = 1#content-coding Content-Encoding = 1#content-coding
An example of its use is An example of its use is
Content-Encoding: gzip Content-Encoding: gzip
If multiple encodings have been applied to a representation, the If one or more encodings have been applied to a representation, the
content codings MUST be listed in the order in which they were sender that applied the encodings MUST generate a Content-Encoding
applied. Additional information about the encoding parameters MAY be header field that lists the content codings in the order in which
provided by other header fields not defined by this specification. they were applied. Additional information about the encoding
parameters MAY be provided by other header fields not defined by this
specification.
Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), the codings Unlike Transfer-Encoding (Section 3.3.1 of [Part1]), 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
skipping to change at page 13, line 12 skipping to change at page 13, line 12
Media Type) if a representation in the request message has a content Media Type) if a representation in the request message has a content
coding that is not acceptable. coding that is not acceptable.
3.1.3. Audience Language 3.1.3. Audience Language
3.1.3.1. Language Tags 3.1.3.1. Language Tags
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. HTTP uses language tags within languages are explicitly excluded.
the Accept-Language and Content-Language header fields.
Accept-Language uses the looser language-range production defined in HTTP uses language tags within the Accept-Language and Content-
Section 5.3.5, whereas Content-Language uses the stricter language- Language header fields. Accept-Language uses the broader language-
tag production defined below. range production defined in Section 5.3.5, whereas Content-Language
uses the language-tag production defined below.
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
A language tag is composed of one or more parts: a primary language A language tag is a sequence of one or more case-insensitive subtags,
subtag followed by a possibly empty series of subtags. White space each separated by a hyphen character ("-", %x2D). In most cases, a
is not allowed within the tag and all tags are case-insensitive. language tag consists of a primary language subtag that identifies a
Example tags include: broad family of related languages (e.g., "en" = English) which is
optionally followed by a series of subtags that refine or narrow that
language's range (e.g., "en-CA" = the variety of English as
communicated in Canada). Whitespace is not allowed within a language
tag. Example tags include:
en, 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
The "Content-Language" header field describes the natural language(s) The "Content-Language" header field describes the natural language(s)
of the intended audience for the representation. Note that this of the intended audience for the representation. Note that this
might not be equivalent to all the languages used within the might not be equivalent to all the languages used within the
representation. representation.
skipping to change at page 14, line 35 skipping to change at page 14, line 39
payload, it is often desirable for the sender to supply, or the payload, it is often desirable for the sender to supply, or the
recipient to determine, an identifier for a resource corresponding to recipient to determine, an identifier for a resource corresponding to
that representation. that representation.
For a request message: For a request message:
o If the request has a Content-Location header field, then the o If the request has a Content-Location header field, then the
sender asserts that the payload is a representation of the sender asserts that the payload is a representation of the
resource identified by the Content-Location field-value. However, resource identified by the Content-Location field-value. However,
such an assertion cannot be trusted unless it can be verified by such an assertion cannot be trusted unless it can be verified by
other means (not defined by HTTP). The information might still be other means (not defined by this specification). The information
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 is GET or HEAD and the response status code is 200 1. If the request is GET or HEAD and the response status code is 200
(OK), 204 (No Content), 206 (Partial Content), or 304 (Not (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 [Part1]).
skipping to change at page 15, line 15 skipping to change at page 15, line 20
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.
4. If the response has a Content-Location header field and its 4. If the response has a Content-Location header field and its
field-value is a reference to a URI different from the effective field-value is a reference to a URI different from the effective
request URI, then the sender asserts that the payload is a request URI, then the sender asserts that the payload is a
representation of the resource identified by the Content-Location representation of the resource identified by the Content-Location
field-value. However, such an assertion cannot be trusted unless field-value. However, such an assertion cannot be trusted unless
it can be verified by other means (not defined by HTTP). it can be verified by other means (not defined by this
specification).
5. Otherwise, the payload is unidentified. 5. Otherwise, the payload is unidentified.
3.1.4.2. Content-Location 3.1.4.2. Content-Location
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
skipping to change at page 18, line 39 skipping to change at page 18, line 45
patterns of content negotiation include "conditional content", where patterns of content negotiation include "conditional content", where
the representation consists of multiple parts that are selectively the representation consists of multiple parts that are selectively
rendered based on user agent parameters, "active content", where the rendered based on user agent parameters, "active content", where the
representation contains a script that makes additional (more representation contains a script that makes additional (more
specific) requests based on the user agent characteristics, and specific) requests based on the user agent characteristics, and
"Transparent Content Negotiation" ([RFC2295]), where content "Transparent Content Negotiation" ([RFC2295]), where content
selection is performed by an intermediary. These patterns are not selection is performed by an intermediary. These patterns are not
mutually exclusive, and each has trade-offs in applicability and mutually exclusive, and each has trade-offs in applicability and
practicality. practicality.
Note that, in all cases, the supplier of representations to the Note that, in all cases, HTTP is not aware of the resource semantics.
origin server determines which representations might be considered to The consistency with which an origin server responds to requests,
be the "same information". over time and over the varying dimensions of content negotiation, and
thus the "sameness" of a resource's observed representations over
time, is determined entirely by whatever entity or algorithm selects
or generates those responses. HTTP pays no attention to the man
behind the curtain.
3.4.1. Proactive Negotiation 3.4.1. Proactive Negotiation
When content negotiation preferences are sent by the user agent in a When content negotiation preferences are sent by the user agent in a
request in order to encourage an algorithm located at the server to request to encourage an algorithm located at the server to select the
select the preferred representation, it is called proactive preferred representation, it is called proactive negotiation (a.k.a.,
negotiation (a.k.a., server-driven negotiation). Selection is based server-driven negotiation). Selection is based on the available
on the available representations for a response (the dimensions over representations for a response (the dimensions over which it might
which it might vary, such as language, content-coding, etc.) compared vary, such as language, content-coding, etc.) compared to various
to various information supplied in the request, including both the information supplied in the request, including both the explicit
explicit negotiation fields of Section 5.3 and implicit negotiation fields of Section 5.3 and implicit characteristics, such
characteristics, such as the client's network address or parts of the 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.
skipping to change at page 19, line 50 skipping to change at page 20, line 11
An origin server MAY generate a Vary header field (Section 7.1.4) in An origin server MAY generate a Vary header field (Section 7.1.4) in
responses that are subject to proactive negotiation to indicate what responses that are subject to proactive negotiation to indicate what
parameters of request information might be used in its selection parameters of request information might be used in its selection
algorithm, thereby providing a means for recipients to determine the algorithm, thereby providing a means for recipients to determine the
reusability of that same response for user agents with differing reusability of that same response for user agents with differing
request information. request information.
3.4.2. Reactive Negotiation 3.4.2. Reactive Negotiation
With reactive negotiation (a.k.a., agent-driven negotiation), With reactive negotiation (a.k.a., agent-driven negotiation),
selection of the best representation for a response is performed by selection of the best response representation (regardless of the
the user agent after receiving an initial response from the origin status code) is performed by the user agent after receiving an
server with a list of alternative resources. If the user agent is initial response from the origin server that contains a list of
not satisfied by the initial response, it can perform a GET request resources for alternative representations. If the user agent is not
on one or more of the alternative resources, selected based on satisfied by the initial response representation, it can perform a
metadata included in the list, to obtain a different form of GET request on one or more of the alternative resources, selected
representation. Selection of alternatives might be performed based on metadata included in the list, to obtain a different form of
automatically by the user agent or manually by the user selecting representation for that response. Selection of alternatives might be
from a generated (possibly hypertext) menu. performed automatically by the user agent or manually by the user
selecting from a generated (possibly hypertext) menu.
A server can send a 300 (Multiple Choices) response to indicate that Note that the above refers to representations of the response, in
reactive negotiation by the user agent is desired, or a 406 (Not general, not representations of the resource. The alternative
Acceptable) status code to indicate that proactive negotiation has representations are only considered representations of the target
failed. In both cases, the response ought to include information resource if the response in which those alternatives are provided has
about the available representations so that the user or user agent the semantics of being a representation of the target resource (e.g.,
can react by making a selection. a 200 (OK) response to a GET request) or has the semantics of
providing links to alternative representations for the target
resource (e.g., a 300 (Multiple Choices) response to a GET request).
A server might choose not to send an initial representation, other
than the list of alternatives, and thereby indicate that reactive
negotiation by the user agent is preferred. For example, the
alternatives listed in responses with the 300 (Multiple Choices) and
406 (Not Acceptable) status codes include information about the
available representations so that the user or user agent can react by
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
skipping to change at page 20, line 39 skipping to change at page 21, line 11
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
developed as an extension. developed as an extension.
4. Request Methods 4. Request Methods
4.1. Overview 4.1. Overview
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. The and what is expected by the client as a successful result.
request semantics might be further specialized by the semantics of
some header fields when present in a request (Section 5) if those The request method's semantics might be further specialized by the
additional semantics do not conflict with the method. semantics of some header fields when present in a request (Section 5)
if those additional semantics do not conflict with the method. For
example, a client can send conditional request header fields
(Section 5.2) to make the requested action conditional on the current
state of the target resource ([Part4]).
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.
skipping to change at page 21, line 24 skipping to change at page 22, line 11
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 ASCII
letters. 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 block. | | | | 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. | |
| PUT | Replace all current representations of the | 4.3.4 | | PUT | Replace all current representations of the | 4.3.4 |
| | target resource with the request payload. | | | | target resource with the request payload. | |
| DELETE | Remove all current representations of the | 4.3.5 | | DELETE | Remove all current representations of the | 4.3.5 |
| | target resource. | | | | target resource. | |
| CONNECT | Establish a tunnel to the server identified by | 4.3.6 | | CONNECT | Establish a tunnel to the server identified by | 4.3.6 |
| | the target resource. | | | | the target resource. | |
| OPTIONS | Describe the communication options for the | 4.3.7 | | OPTIONS | Describe the communication options for the | 4.3.7 |
| | target resource. | | | | target resource. | |
skipping to change at page 22, line 10 skipping to change at page 22, line 45
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.
A client can send conditional request header fields (Section 5.2) to
make the requested action conditional on the current state of the
target resource ([Part4]).
4.2. Common Method Properties 4.2. Common Method Properties
4.2.1. Safe Methods 4.2.1. Safe Methods
Request methods are considered "safe" if their defined semantics are Request methods are considered "safe" if their defined semantics are
essentially read-only; i.e., the client does not request, and does 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 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.
skipping to change at page 23, line 9 skipping to change at page 23, line 39
A user agent SHOULD distinguish between safe and unsafe methods when A user agent SHOULD distinguish between safe and unsafe methods when
presenting potential actions to a user, such that the user can be presenting potential actions to a user, such that the user can be
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 MUST resource is to perform an unsafe action, then the resource owner MUST
disable or disallow that action when it is accessed using a safe disable or disallow that action when it is accessed using a safe
request method. Failure to do so will result in unfortunate side- request method. Failure to do so will result in unfortunate side-
effects when automated processes perform a GET on every URI reference effects when automated processes perform a GET on every URI reference
for the sake of link maintenance, pre-fetching, building a search for the sake of link maintenance, pre-fetching, building a search
index, etc. index, etc.
4.2.2. Idempotent Methods 4.2.2. Idempotent Methods
Request methods are considered "idempotent" if the intended effect of Request methods are considered "idempotent" if the intended effect of
multiple identical requests is the same as for a single request. Of multiple identical requests is the same as for a single request. Of
skipping to change at page 23, line 40 skipping to change at page 24, line 22
client is able to read the server's response. For example, if a client is able to read the server's response. For example, if a
client sends a PUT request and the underlying connection is closed client sends a PUT request and the underlying connection is closed
before any response is received, then it can establish a new before any response is received, then it can establish a new
connection and retry the idempotent request because it knows that connection and retry the idempotent request because it knows that
repeating the request will have the same effect even if the original repeating the request will have the same effect even if the original
request succeeded. Note, however, that repeated failures would request succeeded. Note, however, that repeated failures would
indicate a problem within the server. indicate a problem within the server.
4.2.3. Cacheable Methods 4.2.3. Cacheable Methods
Request methods are considered "cacheable" if it is possible and Request methods can be defined as "cacheable" to indicate that
useful to answer a current client request with a stored response from responses to them are allowed to be stored for future reuse; for
a prior request. GET and HEAD are defined to be cacheable. In specific requirements see [Part6]. In general, safe methods that do
general, safe methods that do not depend on a current or not depend on a current or authoritative response are defined as
authoritative response are cacheable, though the overwhelming cacheable; this specification defines GET, HEAD and POST as
majority of caches only support GET and HEAD. HTTP requirements for cacheable, although the overwhelming majority of cache
cache behavior and cacheable responses are defined in [Part6]. 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 filesystem It is tempting to think of resource identifiers as remote filesystem
pathnames, and of representations as being a copy of the contents of pathnames, and of representations as being a copy of the contents of
skipping to change at page 24, line 39 skipping to change at page 25, line 18
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]). ([Part5]).
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 7.2 of [Part6]). by the Cache-Control header field (Section 5.2 of [Part6]).
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 block). Aside from the payload header fields the end of the header section). The server SHOULD send the same
(Section 3.3), the server SHOULD send the same header fields in header fields in response to a HEAD request as it would have sent if
response to a HEAD request as it would have sent if the request had the request had been a GET, except that the payload header fields
been a GET. This method can be used for obtaining metadata about the (Section 3.3) MAY be omitted. This method can be used for obtaining
selected representation without transferring the representation data. metadata about the selected representation without transferring the
This method is often used for testing hypertext links for validity, representation data and is often used for testing hypertext links for
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 7.2 of [Part6]). A HEAD response Cache-Control header field (Section 5.2 of [Part6]). A HEAD response
might also have an effect on previously cached responses to GET; see might also have an effect on previously cached responses to GET; see
Section 5 of [Part6]. Section 4.3.5 of [Part6].
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 25, line 47 skipping to change at page 26, line 27
being 206, 304, and 416). being 206, 304, and 416).
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.1.1 of [Part6]). explicit freshness information (see Section 4.2.1 of [Part6]).
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 26, line 35 skipping to change at page 27, line 15
subject to dynamic processing by the origin server, before any subject to dynamic processing by the origin server, before any
subsequent GET is received. A successful response only implies that subsequent GET is received. A successful response only implies that
the user agent's intent was achieved at the time of its processing by the user agent's intent was achieved at the time of its processing by
the origin server. the origin server.
If the target resource does not have a current representation and the If the target resource does not have a current representation and the
PUT successfully creates one, then the origin server MUST inform the PUT successfully creates one, then the origin server MUST inform the
user agent by sending a 201 (Created) response. If the target user agent by sending a 201 (Created) response. If the target
resource does have a current representation and that representation resource does have a current representation and that representation
is successfully modified in accordance with the state of the enclosed is successfully modified in accordance with the state of the enclosed
representation, then either a 200 (OK) or 204 (No Content) response representation, then the origin server MUST send either a 200 (OK) or
SHOULD be sent to indicate successful completion of the request. a 204 (No Content) response to indicate successful completion of the
request.
An origin server SHOULD ignore unrecognized header fields received in An origin server SHOULD ignore unrecognized header fields received in
a PUT request (i.e., do not save them as part of the resource state). a PUT request (i.e., do not save them as part of the resource state).
An origin server SHOULD verify that the PUT representation is An origin server SHOULD verify that the PUT representation is
consistent with any constraints the server has for the target consistent with any constraints the server has for the target
resource that cannot or will not be changed by the PUT. This is resource that cannot or will not be changed by the PUT. This is
particularly important when the origin server uses internal particularly important when the origin server uses internal
configuration information related to the URI in order to set the configuration information related to the URI in order to set the
values for representation metadata on GET responses. When a PUT values for representation metadata on GET responses. When a PUT
representation is inconsistent with the target resource, the origin representation is inconsistent with the target resource, the origin
server SHOULD either make them consistent, by transforming the server SHOULD either make them consistent, by transforming the
representation or changing the resource configuration, or respond representation or changing the resource configuration, or respond
with an appropriate error message containing sufficient information with an appropriate error message containing sufficient information
to explain why the representation is unsuitable. The 409 (Conflict) to explain why the representation is unsuitable. The 409 (Conflict)
or 415 (Unsupported Media Type) status codes are suggested, with the or 415 (Unsupported Media Type) status codes are suggested, with the
latter being specific to constraints on Content-Type values. latter being specific to constraints on Content-Type values.
For example, if the target resource is configured to always have a For example, if the target resource is configured to always have a
Content-Type of "text/html" and the representation being PUT has a Content-Type of "text/html" and the representation being PUT has a
Content-Type of "image/jpeg", then the origin server SHOULD do one Content-Type of "image/jpeg", the origin server ought to do one of:
of:
a. reconfigure the target resource to reflect the new media type; a. reconfigure the target resource to reflect the new media type;
b. transform the PUT representation to a format consistent with that b. transform the PUT representation to a format consistent with that
of the resource before saving it as the new resource state; or, of the resource before saving it as the new resource state; or,
c. reject the request with a 415 (Unsupported Media Type) response c. reject the request with a 415 (Unsupported Media Type) response
indicating that the target resource is limited to "text/html", indicating that the target resource is limited to "text/html",
perhaps including a link to a different resource that would be a perhaps including a link to a different resource that would be a
suitable target for the new representation. suitable target for the new representation.
skipping to change at page 28, line 18 skipping to change at page 28, line 46
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 MAY 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 SHOULD reject any PUT request that contains a An origin server that allows PUT on a given target resource MUST send
Content-Range header field (Section 4.2 of [Part5]), since it might a 400 (Bad Request) response to a PUT request that contains a
be misinterpreted as partial content (or might be partial content Content-Range header field (Section 4.2 of [Part5]), since the
that is being mistakenly PUT as a full representation). Partial payload is likely to be partial content that has been mistakenly PUT
content updates are possible by targeting a separately identified as a full representation. Partial content updates are possible by
resource with state that overlaps a portion of the larger resource, targeting a separately identified resource with state that overlaps a
or by using a different method that has been specifically defined for portion of the larger resource, or by using a different method that
partial updates (for example, the PATCH method defined in [RFC5789]). has been specifically defined for partial updates (for example, the
PATCH method defined in [RFC5789]).
Responses to the PUT method are not cacheable. If a PUT request Responses to the PUT method are not cacheable. If a successful PUT
passes through a cache that has one or more stored responses for the request passes through a cache that has one or more stored responses
effective request URI, those stored responses will be invalidated for the effective request URI, those stored responses will be
(see Section 6 of [Part6]). invalidated (see Section 4.4 of [Part6]).
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.
skipping to change at page 29, line 27 skipping to change at page 30, line 8
previously created using a PUT request, or identified via the previously created using a PUT request, or identified via the
Location header field after a 201 (Created) response to a POST Location header field after a 201 (Created) response to a POST
request, might allow a corresponding DELETE request to undo those request, might allow a corresponding DELETE request to undo those
actions. Similarly, custom user agent implementations that implement actions. Similarly, custom user agent implementations that implement
an authoring function, such as revision control clients using HTTP an authoring function, such as revision control clients using HTTP
for remote operations, might use DELETE based on an assumption that for remote operations, might use DELETE based on an assumption that
the server's URI space has been crafted to correspond to a version the server's URI space has been crafted to correspond to a version
repository. repository.
If a DELETE method is successfully applied, the origin server SHOULD If a DELETE method is successfully applied, the origin server SHOULD
send a 202 (Accepted) status code if the action seems okay but has send a 202 (Accepted) status code if the action will likely succeed
not yet been enacted, a 204 (No Content) status code if the action but has not yet been enacted, a 204 (No Content) status code if the
has been enacted and no further information is to be supplied, or a action has been enacted and no further information is to be supplied,
200 (OK) status code if the action has been enacted and the response or a 200 (OK) status code if the action has been enacted and the
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 6 of [Part6]). invalidated (see Section 4.4 of [Part6]).
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 connection is closed. of packets, in both directions, until the tunnel is closed.
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 status code to indicate that a connection is established.
However, most origin servers do not implement CONNECT. 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 [Part1]); 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
skipping to change at page 30, line 20 skipping to change at page 30, line 48
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
inbound proxies) will switch to tunnel mode immediately after the inbound proxies) will switch to tunnel mode immediately after the
blank line that concludes the successful response's header block; blank line that concludes the successful response's header section;
data received after that blank line is from the server identified by data received after that blank line is from the server identified by
the request-target. Any response other than a successful response the request-target. Any response other than a successful response
indicates that the tunnel has not yet been formed and that the indicates that the tunnel has not yet been formed and that the
connection remains governed by HTTP. connection remains governed by HTTP.
A server SHOULD NOT send any Transfer-Encoding or Content-Length A tunnel is closed when a tunnel intermediary detects that either
header fields in a successful response. A client MUST ignore any side has closed its connection: the intermediary MUST attempt to send
Content-Length or Transfer-Encoding header fields received in a any outstanding data that came from the closed side to the other
successful response. side, close both connections, and then discard any remaining data
left undelivered.
Proxy authentication might be used to establish the authority to
create a tunnel. For example,
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
There are significant risks in establishing a tunnel to arbitrary There are significant risks in establishing a tunnel to arbitrary
servers, particularly when the destination is a well-known or servers, particularly when the destination is a well-known or
reserved TCP port that is not intended for Web traffic. For example, reserved TCP port that is not intended for Web traffic. For example,
a CONNECT to a request-target of "example.com:25" would suggest that a CONNECT to a request-target of "example.com:25" would suggest that
the proxy connect to the reserved port for SMTP traffic; if allowed, the proxy connect to the reserved port for SMTP traffic; if allowed,
that could trick the proxy into relaying spam email. Proxies that that could trick the proxy into relaying spam email. Proxies that
support CONNECT SHOULD restrict its use to a limited set of known support CONNECT SHOULD restrict its use to a limited set of known
ports or a configurable whitelist of safe request targets. ports or a configurable whitelist of safe request targets.
Proxy authentication might be used to establish the authority to A server MUST NOT send any Transfer-Encoding or Content-Length header
create a tunnel. For example, fields in a 2xx (Successful) response to CONNECT. A client MUST
ignore any Content-Length or Transfer-Encoding header fields received
CONNECT server.example.com:80 HTTP/1.1 in a successful response to CONNECT.
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
When a tunnel intermediary detects that either side has closed its
connection, any outstanding data that came from that side will first
be sent to the other side and then the intermediary will close both
connections. If there is outstanding data left undelivered, that
data will be discarded.
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 on the request/response chain identified by the options available for the target resource, either at the origin
effective request URI. This method allows a client to determine the server or an intervening intermediary. This method allows a client
options and/or requirements associated with a resource, or the to determine the options and/or requirements associated with a
capabilities of a server, without implying a resource action. resource, or the capabilities of a server, without implying a
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 [Part1]) applies to the server in general rather than
to a specific resource. Since a server's communication options 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
skipping to change at page 32, line 16 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 7.3.1 of [Part1]). The final Content-Type of "message/http" (Section 8.3.1 of [Part1]). The final
recipient is either the origin server or the first server to receive recipient is either the origin server or the first server to receive
a Max-Forwards value of zero (0) in the request (Section 5.1.2). a Max-Forwards value of zero (0) in the request (Section 5.1.2).
A client MUST NOT send header fields in a TRACE request containing A client MUST NOT generate header fields in a TRACE request
sensitive data that might be disclosed by the response. For example, containing sensitive data that might be disclosed by the response.
it would be foolish for a user agent to send stored user credentials
[Part7] or cookies [RFC6265] in a TRACE request. The final recipient For example, it would be foolish for a user agent to send stored user
SHOULD exclude any request header fields from the response body that credentials [Part7] or cookies [RFC6265] in a TRACE request. The
are likely to contain sensitive data. final recipient of the request SHOULD exclude any request header
fields that are likely to contain sensitive data when that recipient
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 [Part1]) 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.
skipping to change at page 33, line 8 skipping to change at page 33, line 40
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 7.2 of [Part6] | | Cache-Control | Section 5.2 of [Part6] |
| Expect | Section 5.1.1 | | Expect | Section 5.1.1 |
| Host | Section 5.4 of [Part1] | | Host | Section 5.4 of [Part1] |
| Max-Forwards | Section 5.1.2 | | Max-Forwards | Section 5.1.2 |
| Pragma | Section 7.4 of [Part6] | | Pragma | Section 5.4 of [Part6] |
| Range | Section 3.1 of [Part5] | | Range | Section 3.1 of [Part5] |
| TE | Section 4.3 of [Part1] | | TE | Section 4.3 of [Part1] |
+-------------------+------------------------+ +-------------------+------------------------+
5.1.1. Expect 5.1.1. Expect
The "Expect" header field is used to indicate that particular server The "Expect" header field in a request indicates a certain set of
behaviors are required by the client. behaviors (expectations) that need to be supported by the server in
order to properly handle this request. The only such expectation
Expect = 1#expectation defined by this specification is 100-continue.
expectation = expect-name [ BWS "=" BWS expect-value ]
*( OWS ";" [ OWS expect-param ] )
expect-param = expect-name [ BWS "=" BWS expect-value ]
expect-name = token
expect-value = token / quoted-string
If all received Expect header field(s) are syntactically valid but
contain an expectation that the recipient does not understand or
cannot comply with, the recipient MUST respond with a 417
(Expectation Failed) status code. A recipient of a syntactically
invalid Expectation header field MUST respond with a 4xx status code
other than 417.
Comparison is case-insensitive for names (expect-name), and case-
sensitive for values (expect-value).
The Expect header field MUST be forwarded if the request is
forwarded.
Many older HTTP/1.0 and HTTP/1.1 servers do not understand the Expect
header field.
5.1.1.1. Use of the 100 (Continue) Status Expect = "100-continue"
The only expectation defined by this specification is: The Expect field-value is case-insensitive.
100-continue A server that receives an Expect field-value other than 100-continue
MAY respond with a 417 (Expectation Failed) status code to indicate
that the unexpected expectation cannot be met.
The request includes a payload body and the client will wait for a A 100-continue expectation informs recipients that the client is
100 (Continue) response after sending the request header section about to send a (presumably large) message body in this request and
but before sending the payload body. The 100-continue expectation wishes to receive a 100 (Continue) interim response if the request-
does not use any expect-params. line and header fields are not sufficient to cause an immediate
success, redirect, or error response. This allows the client to wait
for an indication that it is worthwhile to send the message body
before actually doing so, which can improve efficiency when the
message body is huge or when the client anticipates that an error is
likely (e.g., when sending a state-changing method, for the first
time, without previously verified authentication credentials).
The primary purpose of the 100 (Continue) status code (Section 6.2.1) For example, a request that begins with
is to allow a client that is sending a request message with a payload
to determine if the origin server is willing to accept the request
(based on the request header fields) before the client sends the
payload body. In some cases, it might either be inappropriate or
highly inefficient for the client to send the payload body if the
server will reject the message without looking at the body.
Requirements for HTTP/1.1 clients: PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue
o If a client will wait for a 100 (Continue) response before sending allows the origin server to immediately respond with an error
the payload body, it MUST send an Expect header field with the message, such as 401 (Unauthorized) or 405 (Method Not Allowed),
"100-continue" expectation. before the client starts filling the pipes with an unnecessary data
transfer.
o A client MUST NOT send an Expect header field with the "100- Requirements for clients:
continue" expectation if it does not intend to send a payload
body.
Because of the presence of older implementations, the protocol allows o A client MUST NOT generate a 100-continue expectation in a request
ambiguous situations in which a client might send "Expect: 100- that does not include a message body.
continue" without receiving either a 417 (Expectation Failed) or a
100 (Continue) status code. Therefore, when a client sends this
header field to an origin server (possibly via a proxy) from which it
has never seen a 100 (Continue) status code, the client SHOULD NOT
wait for an indefinite period before sending the payload body.
Requirements for HTTP/1.1 origin servers: o A client that will wait for a 100 (Continue) response before
sending the request message body MUST send an Expect header field
containing a 100-continue expectation.
o Upon receiving a request that includes an Expect header field with o A client that sends a 100-continue expectation is not required to
the "100-continue" expectation, an origin server MUST either wait for any specific length of time; such a client MAY proceed to
respond with 100 (Continue) status code and continue to read from send the message body even if it has not yet received a response.
the input stream, or respond with a final status code. The origin Furthermore, since 100 (Continue) responses cannot be sent through
server MUST NOT wait for the payload body before sending the 100 an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an
(Continue) response. If the origin server responds with a final indefinite period before sending the message body.
status code, it MUST NOT have performed the request method and MAY
either close the connection or continue to read and discard the
rest of the request.
o An origin server SHOULD NOT send a 100 (Continue) response if the o A client that receives a 417 (Expectation Failed) status code in
request message does not include an Expect header field with the response to a request containing a 100-continue expectation SHOULD
"100-continue" expectation, and MUST NOT send a 100 (Continue) repeat that request without a 100-continue expectation, since the
response if such a request comes from an HTTP/1.0 (or earlier) 417 response merely indicates that the response chain does not
client. There is an exception to this rule: for compatibility support expectations (e.g., it passes through an HTTP/1.0 server).
with [RFC2068], a server MAY send a 100 (Continue) status code in
response to an HTTP/1.1 PUT or POST request that does not include
an Expect header field with the "100-continue" expectation. This
exception, the purpose of which is to minimize any client
processing delays associated with an undeclared wait for 100
(Continue) status code, applies only to HTTP/1.1 requests, and not
to requests with any other HTTP-version value.
o An origin server MAY omit a 100 (Continue) response if it has Requirements for servers:
already received some or all of the payload body for the
corresponding request.
o An origin server that sends a 100 (Continue) response MUST o A server that receives a 100-continue expectation in an HTTP/1.0
ultimately send a final status code, once the payload body is request MUST ignore that expectation.
received and processed, unless it terminates the transport
connection prematurely.
o If an origin server receives a request that does not include an o A server MAY omit sending a 100 (Continue) response if it has
Expect header field with the "100-continue" expectation, the already received some or all of the message body for the
request includes a payload body, and the server responds with a corresponding request, or if the framing indicates that there is
final status code before reading the entire payload body from the no message body.
transport connection, then the server SHOULD NOT close the
transport connection until it has read the entire request, or
until the client closes the connection. Otherwise, the client
might not reliably receive the response message. However, this
requirement ought not be construed as preventing a server from
defending itself against denial-of-service attacks, or from badly
broken client implementations.
Requirements for HTTP/1.1 proxies: o A server that sends a 100 (Continue) response MUST ultimately send
a final status code, once the message body is received and
processed, unless the connection is closed prematurely.
o If a proxy receives a request that includes an Expect header field o A server that responds with a final status code before reading the
with the "100-continue" expectation, and the proxy either knows entire message body SHOULD indicate in that response whether it
that the next-hop server complies with HTTP/1.1 or higher, or does intends to close the connection or continue reading and discarding
not know the HTTP version of the next-hop server, it MUST forward the request message (see Section 6.6 of [Part1]).
the request, including the Expect header field.
o If the proxy knows that the version of the next-hop server is An origin server MUST, upon receiving an HTTP/1.1 (or later) request-
HTTP/1.0 or lower, it MUST NOT forward the request, and it MUST line and a complete header section that contains a 100-continue
respond with a 417 (Expectation Failed) status code. expectation and indicates a request message body will follow, either
send an immediate response with a final status code, if that status
can be determined by examining just the request-line and header
fields, or send an immediate 100 (Continue) response to encourage the
client to send the request's message body. The origin server MUST
NOT wait for the message body before sending the 100 (Continue)
response.
o Proxies SHOULD maintain a record of the HTTP version numbers A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and
received from recently-referenced next-hop servers. a complete header section that contains a 100-continue expectation
and indicates a request message body will follow, either send an
immediate response with a final status code, if that status can be
determined by examining just the request-line and header fields, or
begin forwarding the request toward the origin server by sending a
corresponding request-line and header section to the next inbound
server. If the proxy believes (from configuration or past
interaction) that the next inbound server only supports HTTP/1.0, the
proxy MAY generate an immediate 100 (Continue) response to encourage
the client to begin sending the message body.
o A proxy MUST NOT forward a 100 (Continue) response if the request Note: The Expect header field was added after the original
message was received from an HTTP/1.0 (or earlier) client and did publication of HTTP/1.1 [RFC2068] as both the means to request an
not include an Expect header field with the "100-continue" interim 100 response and the general mechanism for indicating
expectation. This requirement overrides the general rule for must-understand extensions. However, the extension mechanism has
forwarding of 1xx responses (see Section 6.2.1). not been used by clients and the must-understand requirements have
not been implemented by many servers, rendering the extension
mechanism useless. This specification has removed the extension
mechanism in order to simplify the definition and 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) methods to limit the (Section 4.3.8) and OPTIONS (Section 4.3.7) request methods to limit
number of times that the request is forwarded by proxies. This can the number of times that the request is forwarded by proxies. This
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
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 recipient of a TRACE or OPTIONS request containing a Max- Each intermediary that receives a TRACE or OPTIONS request containing
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
recipient MUST NOT forward the request; instead, it MUST respond as intermediary MUST NOT forward the request; instead, the intermediary
the final recipient. If the received Max-Forwards value is greater MUST respond as the final recipient. If the received Max-Forwards
than zero, then the forwarded message MUST contain an updated Max- value is greater than zero, the intermediary MUST generate an updated
Forwards field with a value decremented by one (1). 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)
the recipient's maximum supported value for Max-Forwards.
The Max-Forwards header field MAY be ignored for all other request A recipient MAY ignore a Max-Forwards header field received with any
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 [Part4] allow a client to
place a precondition on the state of the target resource, so that the place a precondition on the state of the target resource, so that the
action corresponding to the method semantics will not be applied if action corresponding to the method semantics will not be applied if
the precondition evaluates to false. Each precondition defined by 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
skipping to change at page 38, line 51 skipping to change at page 39, line 11
"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
SHOULD be interpreted as "I prefer audio/basic, but send me any audio is interpreted as "I prefer audio/basic, but send me any audio type
type if it is the best available after an 80% mark-down in quality". if it is the best available after an 80% mark-down 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 44, line 39 skipping to change at page 44, line 46
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.
Robotic user agents SHOULD send a valid From header field so that the A robotic user agent SHOULD send a valid From header field so that
person responsible for running the robot can be contacted if problems the person responsible for running the robot can be contacted if
occur on servers, such as if the robot is sending excessive, problems occur on servers, such as if the robot is sending excessive,
unwanted, or invalid requests. unwanted, or invalid requests.
Servers SHOULD NOT use the From header field for access control or A server SHOULD NOT use the From header field for access control or
authentication, since most recipients will assume that the field authentication, since most recipients will assume that the field
value is public information. value is public information.
5.5.2. Referer 5.5.2. Referer
The "Referer" [sic] header field allows the user agent to specify a The "Referer" [sic] header field allows the user agent to specify a
URI reference for the resource from which the target URI was obtained URI reference for the resource from which the target URI was obtained
(i.e., the "referrer", though the field name is misspelled). A user (i.e., the "referrer", though the field name is misspelled). A user
agent MUST exclude any fragment or userinfo components [RFC3986] when agent MUST NOT include the fragment and userinfo components of the
generating the Referer field value. URI reference [RFC3986], if any, when generating the Referer field
value.
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
Referer allows servers to generate back-links to other resources for Referer allows servers to generate back-links to other resources for
simple analytics, logging, optimized caching, etc. It also allows simple analytics, logging, optimized caching, etc. It also allows
obsolete or mistyped links to be found for maintenance. Some servers obsolete or mistyped links to be found for maintenance. Some servers
use Referer as a means of denying links from other sites (so-called use Referer as a means of denying links from other sites (so-called
"deep linking") or restricting cross-site request forgery (CSRF), but "deep linking") or restricting cross-site request forgery (CSRF), but
not all requests contain a Referer header field. not all requests contain a Referer header field.
skipping to change at page 45, line 32 skipping to change at page 45, line 40
user's bookmarks/favorites), the user agent MUST either exclude user's bookmarks/favorites), the user agent MUST either exclude
Referer or send it with a value of "about:blank". Referer or send it with a value of "about:blank".
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 SHOULD NOT send a Referer header field in "data" URI. A user agent MUST NOT send a Referer header field in an
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.3 for additional security secure protocol. See Section 9.3 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. pseudonyms or truncating the query and/or path components. An
Intermediaries SHOULD NOT modify or delete the Referer field when the intermediary SHOULD NOT modify or delete the Referer header field
field value shares the same scheme and host as the request target. when the field value shares the same scheme and host as the request
target.
5.5.3. User-Agent 5.5.3. User-Agent
The "User-Agent" header field contains information about the user The "User-Agent" header field contains information about the user
agent originating the request, which is often used by servers to help agent originating the request, which is often used by servers to help
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.
skipping to change at page 46, line 23 skipping to change at page 46, line 32
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 [Part1]), 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
Senders SHOULD limit generated product identifiers to what is A sender SHOULD limit generated product identifiers to what is
necessary to identify the product; senders 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 non-essential information within the product
identifier. Senders 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 only differ 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
skipping to change at page 47, line 12 skipping to change at page 47, line 17
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 3-digit integer code giving the result
of the attempt to understand and satisfy the request. 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, clients 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 response the x00 status code of that class, with the exception that a
with an unrecognized status code MUST NOT be cached. 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 status
code. The response message will usually contain a representation code. The response message will usually contain a representation
that explains the status. 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 5
values for the first digit: values for the first digit:
skipping to change at page 48, line 5 skipping to change at page 48, line 6
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 [Part4], Section 4 of [Part5], and Section 3 of [Part7].
The reason phrases listed here are only recommendations -- they can The reason phrases listed here are only recommendations -- they can
be replaced by local equivalents without affecting the protocol. be replaced by local equivalents without affecting the protocol.
Responses with status codes that are defined as cacheable by default
(e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be
reused by a cache with heuristic expiration unless otherwise
indicated by the method definition or explicit cache controls
[Part6]; all other status codes are not cacheable by default.
+------+-------------------------------+------------------------+ +------+-------------------------------+------------------------+
| code | reason-phrase | Defined in... | | code | reason-phrase | Defined in... |
+------+-------------------------------+------------------------+ +------+-------------------------------+------------------------+
| 100 | Continue | Section 6.2.1 | | 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 | | 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 | | 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 | | 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 | | 202 | Accepted | Section 6.3.3 |
| 203 | Non-Authoritative Information | Section 6.3.4 | | 203 | Non-Authoritative Information | Section 6.3.4 |
| 204 | No Content | Section 6.3.5 | | 204 | No Content | Section 6.3.5 |
skipping to change at page 48, line 52 skipping to change at page 49, line 52
| 426 | Upgrade Required | Section 6.5.15 | | 426 | Upgrade Required | Section 6.5.15 |
| 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 Time-out | Section 6.6.5 | | 504 | Gateway Time-out | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 | | 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. extension status codes defined in other specifications. The complete
list of status codes is maintained by IANA. See Section 8.2 for
Responses with status codes that are defined as cacheable by default details.
(e.g., 200, 203, 206, 300, 301, and 410 in this specification) can be
reused by a cache with heuristic expiration unless otherwise
indicated by the method definition or explicit cache controls
[Part6]; all other status codes are not cacheable by default.
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. All 1xx responses consist of only the status-line and
optional header fields, and thus are terminated by the empty line at optional header fields, and thus are terminated by the empty line at
the end of the header block. Since HTTP/1.0 did not define any 1xx the end of the header section. Since HTTP/1.0 did not define any 1xx
status codes, servers MUST NOT send a 1xx response to an HTTP/1.0 status codes, a server MUST NOT send a 1xx response to an HTTP/1.0
client except under experimental conditions. client.
A client MUST be prepared to accept one or more 1xx status responses 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 status responses. user agent MAY ignore unexpected 1xx responses.
Proxies MUST forward 1xx responses, unless the connection between the A proxy MUST forward 1xx responses unless the proxy itself requested
proxy and its client has been closed, or unless the proxy itself the generation of the 1xx response. For example, if a proxy adds an
requested the generation of the 1xx response. For example, if a "Expect: 100-continue" field when it forwards a request, then it need
proxy adds an "Expect: 100-continue" field when it forwards a not forward the corresponding 100 (Continue) response(s).
request, then it need not forward the corresponding 100 (Continue)
response(s).
6.2.1. 100 Continue 6.2.1. 100 Continue
The 100 (Continue) status code indicates that the initial part of a The 100 (Continue) status code indicates that the initial part of a
request has been received and has not yet been rejected by the request has been received and has not yet been rejected by the
server. The server intends to send a final response after the server. The server intends to send a final response after the
request has been fully received and acted upon. request has been fully received and acted upon.
When the request contains an Expect header field that includes a 100- When the request contains an Expect header field that includes a 100-
continue expectation, the 100 response indicates that the server continue expectation, the 100 response indicates that the server
wishes to receive the request payload body, as described in wishes to receive the request payload body, as described in
Section 5.1.1.1. The client ought to continue sending the request Section 5.1.1. The client ought to continue sending the request and
and 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 [Part1]), for a change in
skipping to change at page 51, line 5 skipping to change at page 51, line 45
OPTIONS a representation of the communications options; OPTIONS a representation of the communications options;
TRACE a representation of the request message as received by the end TRACE a representation of the request message as received by the end
server. server.
Aside from responses to CONNECT, a 200 response always has a payload, Aside from responses to CONNECT, a 200 response always has a payload,
though an origin server MAY generate a payload body of zero length. though an origin server MAY generate a payload body of zero length.
If no payload is desired, an origin server ought to send 204 (No If no payload is desired, an origin server ought to send 204 (No
Content) instead. For CONNECT, no payload is allowed because the Content) instead. For CONNECT, no payload is allowed because the
successful result is a tunnel, which begins immediately after the 200 successful result is a tunnel, which begins immediately after the 200
response header block. response header section.
A 200 response is cacheable unless otherwise indicated by the method A 200 response is cacheable unless otherwise indicated by the method
definition or explicit cache controls (see Section 4.1.2 of [Part6]). definition or explicit cache controls (see Section 4.2.2 of [Part6]).
6.3.2. 201 Created 6.3.2. 201 Created
The 201 (Created) status code indicates that the request has been The 201 (Created) status code indicates that the request has been
fulfilled and has resulted in one or more new resources being fulfilled and has resulted in one or more new resources being
created. The primary resource created by the request is identified created. The primary resource created by the request is identified
by either a Location header field in the response or, if no Location by either a Location header field in the response or, if no Location
field is received, by the effective request URI. field is received, by the effective request URI.
The 201 response payload typically describes and links to the The 201 response payload typically describes and links to the
skipping to change at page 52, line 6 skipping to change at page 52, line 49
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 [Part1]). This status code allows the proxy
to notify recipients when a transformation has been applied, since to notify recipients when a transformation has been applied, since
that knowledge might impact later decisions regarding the content. that knowledge might impact later decisions regarding the content.
For example, future cache validation requests for the content might For example, future cache validation requests for the content might
only be applicable along the same request path (through the same only be applicable along the same request path (through the same
proxies). proxies).
The 203 response is similar to the Warning code of 214 Transformation The 203 response is similar to the Warning code of 214 Transformation
Applied (Section 7.5 of [Part6]), which has the advantage of being Applied (Section 5.5 of [Part6]), which has the advantage of being
applicable to responses with any status code. applicable to responses with any status code.
A 203 response is cacheable unless otherwise indicated by the method A 203 response is cacheable unless otherwise indicated by the method
definition or explicit cache controls (see Section 4.1.2 of [Part6]). definition or explicit cache controls (see Section 4.2.2 of [Part6]).
6.3.5. 204 No Content 6.3.5. 204 No Content
The 204 (No Content) status code indicates that the server has The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional successfully fulfilled the request and that there is no additional
content to send in the response payload body. Metadata in the content to send in the response payload body. Metadata in the
response header fields refer to the target resource and its selected response header fields refer to the target resource and its selected
representation after the requested action was applied. representation after the requested action was applied.
For example, if a 204 status code is received in response to a PUT For example, if a 204 status code is received in response to a PUT
skipping to change at page 52, line 43 skipping to change at page 53, line 37
For example, a 204 status code is commonly used with document editing For example, a 204 status code is commonly used with document editing
interfaces corresponding to a "save" action, such that the document interfaces corresponding to a "save" action, such that the document
being saved remains available to the user for editing. It is also being saved remains available to the user for editing. It is also
frequently used with interfaces that expect automated data transfers frequently used with interfaces that expect automated data transfers
to be prevalent, such as within distributed version control systems. to be prevalent, such as within distributed version control systems.
A 204 response is terminated by the first empty line after the header A 204 response is terminated by the first empty line after the header
fields because it cannot contain a message body. fields because it cannot contain a message body.
A 204 response is cacheable unless otherwise indicated by the method A 204 response is cacheable unless otherwise indicated by the method
definition or explicit cache controls (see Section 4.1.2 of [Part6]). definition or explicit cache controls (see Section 4.2.2 of [Part6]).
6.3.6. 205 Reset Content 6.3.6. 205 Reset Content
The 205 (Reset Content) status code indicates that the server has The 205 (Reset Content) status code indicates that the server has
fulfilled the request and desires that the user agent reset the fulfilled the request and desires that the user agent reset the
"document view", which caused the request to be sent, to its original "document view", which caused the request to be sent, to its original
state as received from the origin server. state as received from the origin server.
This response is intended to support a common data entry use case This response is intended to support a common data entry use case
where the user receives content that supports data entry (a form, where the user receives content that supports data entry (a form,
notepad, canvas, etc.), enters or manipulates data in that space, notepad, canvas, etc.), enters or manipulates data in that space,
causes the entered data to be submitted in a request, and then the causes the entered data to be submitted in a request, and then the
data entry mechanism is reset for the next entry so that the user can data entry mechanism is reset for the next entry so that the user can
easily initiate another input action. easily initiate another input action.
Since the 205 status code implies that no additional content will be Since the 205 status code implies that no additional content will be
provided in the payload, the server MUST send a message body of zero provided, a server MUST NOT generate a payload in a 205 response. In
length. In other words, the server MUST send a "Content-Length: 0" other words, a server MUST do one of the following for a 205
field in a 205 response or close the connection immediately after response: a) indicate a zero-length body for the response by
sending the blank line terminating the header section. including a Content-Length header field with a value of 0; b)
indicate a zero-length payload for the response by including a
Transfer-Encoding header field with a value of chunked and a message
body consisting of a single chunk of zero-length; or, c) close the
connection immediately after sending the blank line terminating the
header section.
6.4. Redirection 3xx 6.4. Redirection 3xx
The 3xx (Redirection) class of status code indicates that further The 3xx (Redirection) class of status code indicates that further
action needs to be taken by the user agent in order to fulfill the action needs to be taken by the user agent in order to fulfill the
request. If a Location header field (Section 7.1.2) is provided, the request. If a Location header field (Section 7.1.2) is provided, the
user agent MAY automatically redirect its request to the URI user agent MAY automatically redirect its request to the URI
referenced by the Location field value, even if the specific status referenced by the Location field value, even if the specific status
code is not understood. Automatic redirection needs to done with code is not understood. Automatic redirection needs to done with
care for methods not known to be safe, as defined in Section 4.2.1, care for methods not known to be safe, as defined in Section 4.2.1,
skipping to change at page 54, line 12 skipping to change at page 55, line 11
originally defined the former semantics for 301 and 302 (to match originally defined the former semantics for 301 and 302 (to match
its original implementation at CERN), and defined 303 (See Other) its original implementation at CERN), and defined 303 (See Other)
to match the latter semantics, prevailing practice gradually to match the latter semantics, prevailing practice gradually
converged on the latter semantics for 301 and 302 as well. The converged on the latter semantics for 301 and 302 as well. The
first revision of HTTP/1.1 added 307 (Temporary Redirect) to first revision of HTTP/1.1 added 307 (Temporary Redirect) to
indicate the former semantics without being impacted by divergent indicate the former semantics without being impacted by divergent
practice. Over 10 years later, most user agents still do method practice. Over 10 years later, most user agents still do method
rewriting for 301 and 302; therefore, this specification makes rewriting for 301 and 302; therefore, this specification makes
that behavior conformant when the original request is POST. that behavior conformant when the original request is POST.
Clients SHOULD detect and intervene in cyclical redirections (i.e., A client SHOULD detect and intervene in cyclical redirections (i.e.,
"infinite" redirection loops). "infinite" redirection loops).
Note: An earlier version of this specification recommended a Note: An earlier version of this specification recommended a
maximum of five redirections ([RFC2068], Section 10.3). Content maximum of five redirections ([RFC2068], Section 10.3). Content
developers need to be aware that some clients might implement such developers need to be aware that some clients might implement such
a fixed limitation. a fixed limitation.
6.4.1. 300 Multiple Choices 6.4.1. 300 Multiple Choices
The 300 (Multiple Choices) status code indicates that the target The 300 (Multiple Choices) status code indicates that the target
skipping to change at page 54, line 45 skipping to change at page 55, line 44
For request methods other than HEAD, the server SHOULD generate a For request methods other than HEAD, the server SHOULD generate a
payload in the 300 response containing a list of representation payload in the 300 response containing a list of representation
metadata and URI reference(s) from which the user or user agent can metadata and URI reference(s) from which the user or user agent can
choose the one most preferred. The user agent MAY make a selection choose the one most preferred. The user agent MAY make a selection
from that list automatically, depending upon the list format, but from that list automatically, depending upon the list format, but
this specification does not define a standard for such automatic this specification does not define a standard for such automatic
selection. selection.
A 300 response is cacheable unless otherwise indicated by the method A 300 response is cacheable unless otherwise indicated by the method
definition or explicit cache controls (see Section 4.1.2 of [Part6]). definition or explicit cache controls (see Section 4.2.2 of [Part6]).
Note: The original proposal for 300 defined the URI header field Note: The original proposal for 300 defined the URI header field
as providing a list of alternative representations, such that it as providing a list of alternative representations, such that it
would be usable for 200, 300, and 406 responses and be transferred would be usable for 200, 300, and 406 responses and be transferred
in responses to the HEAD method. However, lack of deployment and in responses to the HEAD method. However, lack of deployment and
disagreement over syntax led to both URI and Alternates (a disagreement over syntax led to both URI and Alternates (a
subsequent proposal) being dropped from this specification. It is subsequent proposal) being dropped from this specification. It is
possible to communicate the list using a set of Link header fields possible to communicate the list using a set of Link header fields
[RFC5988], each with a relationship of "alternate", though [RFC5988], each with a relationship of "alternate", though
deployment is a chicken-and-egg problem. deployment is a chicken-and-egg problem.
skipping to change at page 55, line 24 skipping to change at page 56, line 23
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 historic reasons, user agents MAY change the request Note: For historic reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this method from POST to GET for the subsequent request. If this
behavior is undesired, status code 307 (Temporary Redirect) can be behavior is undesired, the 307 (Temporary Redirect) status code
used instead. can be used instead.
A 301 response is cacheable unless otherwise indicated by the method A 301 response is cacheable unless otherwise indicated by the method
definition or explicit cache controls (see Section 4.1.2 of [Part6]). definition or explicit cache controls (see Section 4.2.2 of [Part6]).
6.4.3. 302 Found 6.4.3. 302 Found
The 302 (Found) status code indicates that the target resource The 302 (Found) status code indicates that the target resource
resides temporarily under a different URI. Since the redirection resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the might be altered on occasion, the client ought to continue to use the
effective request URI for future requests. effective request URI for future requests.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
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: For historic reasons, user agents MAY change the request Note: For historic reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this method from POST to GET for the subsequent request. If this
behavior is undesired, status code 307 (Temporary Redirect) can be behavior is undesired, the 307 (Temporary Redirect) status code
used instead. can be used instead.
6.4.4. 303 See Other 6.4.4. 303 See Other
The 303 (See Other) status code indicates that the server is The 303 (See Other) status code indicates that the server is
redirecting the user agent to a different resource, as indicated by a redirecting the user agent to a different resource, as indicated by a
URI in the Location header field, that is intended to provide an URI in the Location header field, that is intended to provide an
indirect response to the original request. In order to satisfy the indirect response to the original request. In order to satisfy the
original request, a user agent ought to perform a retrieval request original request, a user agent ought to perform a retrieval request
using the Location URI (a GET or HEAD request if using HTTP), which using the Location URI (a GET or HEAD request if using HTTP), which
can itself be redirected further, and present the eventual result as can itself be redirected further, and present the eventual result as
skipping to change at page 57, line 38 skipping to change at page 58, line 38
The 4xx (Client Error) class of status code indicates that the client The 4xx (Client Error) class of status code indicates that the client
seems to have erred. Except when responding to a HEAD request, the seems to have erred. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent error situation, and whether it is a temporary or permanent
condition. These status codes are applicable to any request method. condition. These status codes are applicable to any request method.
User agents SHOULD display any included representation to the user. User agents SHOULD display any included 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 or The 400 (Bad Request) status code indicates that the server cannot or
will not process the request because the received syntax is invalid, will not process the request due to something which is perceived to
nonsensical, or exceeds some limitation on what the server is willing be a client error (e.g., malformed request syntax, invalid request
to process. 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 understood The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to the request but refuses to authorize it. A server that wishes to
make public why the request has been forbidden can describe that make public why the request has been forbidden can describe that
reason in the response payload (if any). reason in the response payload (if any).
If authentication credentials were provided in the request, the If authentication credentials were provided in the request, the
server considers them insufficient to grant access. The client server considers them insufficient to grant access. The client
SHOULD NOT repeat the request with the same credentials. The client SHOULD NOT automatically repeat the request with the same
MAY repeat the request with new or different credentials. However, a credentials. The client MAY repeat the request with new or different
request might be forbidden for reasons unrelated to the credentials. credentials. However, a request might be forbidden for reasons
unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a An origin server that wishes to "hide" the current existence of a
forbidden target resource MAY instead respond with a status code of forbidden target resource MAY instead respond with a status code of
404 (Not Found). 404 (Not Found).
6.5.4. 404 Not Found 6.5.4. 404 Not Found
The 404 (Not Found) status code indicates that the origin server did The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not not find a current representation for the target resource or is not
willing to disclose that one exists. A 404 status does not indicate willing to disclose that one exists. A 404 status code does not
whether this lack of representation is temporary or permanent; the indicate whether this lack of representation is temporary or
410 (Gone) status code is preferred over 404 if the origin server permanent; the 410 (Gone) status code is preferred over 404 if the
knows, presumably through some configurable means, that the condition origin server knows, presumably through some configurable means, that
is likely to be permanent. the condition is likely to be permanent.
A 404 response is cacheable unless otherwise indicated by the method A 404 response is cacheable unless otherwise indicated by the method
definition or explicit cache controls (see Section 4.1.2 of [Part6]). definition or explicit cache controls (see Section 4.2.2 of [Part6]).
6.5.5. 405 Method Not Allowed 6.5.5. 405 Method Not Allowed
The 405 (Method Not Allowed) status code indicates that the method The 405 (Method Not Allowed) status code indicates that the method
specified in the request-line is known by the origin server but not received in the request-line is known by the origin server but not
supported by the target resource. The origin server MUST generate an supported by the target resource. The origin server MUST generate an
Allow header field in a 405 response containing a list of the target Allow header field in a 405 response containing a list of the target
resource's currently supported methods. resource's currently supported methods.
A 405 response is cacheable unless otherwise indicated by the method A 405 response is cacheable unless otherwise indicated by the method
definition or explicit cache controls (see Section 4.1.2 of [Part6]). definition or explicit cache controls (see Section 4.2.2 of [Part6]).
6.5.6. 406 Not Acceptable 6.5.6. 406 Not Acceptable
The 406 (Not Acceptable) status code indicates that the target The 406 (Not Acceptable) status code indicates that the target
resource does not have a current representation that would be resource does not have a current representation that would be
acceptable to the user agent, according to the proactive negotiation acceptable to the user agent, according to the proactive negotiation
header fields received in the request (Section 5.3), and the server header fields received in the request (Section 5.3), and the server
is unwilling to supply a default representation. is unwilling to supply a default representation.
The server SHOULD generate a payload containing a list of available The server SHOULD generate a payload containing a list of available
skipping to change at page 59, line 19 skipping to change at page 60, line 20
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 [Part1]) in the response, since 408 implies that the
server has decided to close the connection rather than continue 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 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
to recognize the source of the conflict. to recognize the source of the conflict.
Conflicts are most likely to occur in response to a PUT request. For Conflicts are most likely to occur in response to a PUT request. For
example, if versioning were being used and the representation being example, if versioning were being used and the representation being
PUT included changes to a resource that conflict with those made by PUT included changes to a resource that conflict with those made by
an earlier (third-party) request, the origin server might use a 409 an earlier (third-party) request, the origin server might use a 409
response to indicate that it can't complete the request. In this response to indicate that it can't complete the request. In this
skipping to change at page 60, line 6 skipping to change at page 61, line 6
maintenance by notifying the recipient that the resource is maintenance by notifying the recipient that the resource is
intentionally unavailable and that the server owners desire that intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common remote links to that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging to for limited-time, promotional services and for resources belonging to
individuals no longer associated with the origin server's site. It individuals no longer associated with the origin server's site. It
is not necessary to mark all permanently unavailable resources as is not necessary to mark all permanently unavailable resources as
"gone" or to keep the mark for any length of time -- that is left to "gone" or to keep the mark for any length of time -- that is left to
the discretion of the server owner. the discretion of the server owner.
A 410 response is cacheable unless otherwise indicated by the method A 410 response is cacheable unless otherwise indicated by the method
definition or explicit cache controls (see Section 4.1.2 of [Part6]). definition or explicit cache controls (see Section 4.2.2 of [Part6]).
6.5.10. 411 Length Required 6.5.10. 411 Length Required
The 411 (Length Required) status code indicates that the server The 411 (Length Required) status code indicates that the server
refuses to accept the request without a defined Content-Length refuses to accept the request without a defined Content-Length
(Section 3.3.2 of [Part1]). The client MAY repeat the request if it (Section 3.3.2 of [Part1]). The client MAY repeat the request if it
adds a valid Content-Length header field containing the length of the adds a valid Content-Length header field containing the length of the
message body in the request message. message body in the request message.
6.5.11. 413 Payload Too Large 6.5.11. 413 Payload Too Large
skipping to change at page 60, line 40 skipping to change at page 61, line 40
refusing to service the request because the request-target (Section refusing to service the request because the request-target (Section
5.3 of [Part1]) is longer than the server is willing to interpret. 5.3 of [Part1]) is longer than the server is willing to interpret.
This rare condition is only likely to occur when a client has This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query improperly converted a POST request to a GET request with long query
information, when the client has descended into a "black hole" of information, when the client has descended into a "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of redirection (e.g., a redirected URI prefix that points to a suffix of
itself), or when the server is under attack by a client attempting to itself), or when the server is under attack by a client attempting to
exploit potential security holes. exploit potential security holes.
A 414 response is cacheable unless otherwise indicated by the method A 414 response is cacheable unless otherwise indicated by the method
definition or explicit cache controls (see Section 4.1.2 of [Part6]). definition or explicit cache controls (see Section 4.2.2 of [Part6]).
6.5.13. 415 Unsupported Media Type 6.5.13. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload origin server is refusing to service the request because the payload
is in a format not supported by the target resource for this method. 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.
6.5.14. 417 Expectation Failed 6.5.14. 417 Expectation Failed
The 417 (Expectation Failed) status code indicates that the The 417 (Expectation Failed) status code indicates that the
expectation given in the request's Expect header field expectation given in the request's Expect header field
(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.
skipping to change at page 61, line 38 skipping to change at page 62, line 38
This service requires use of the HTTP/3.0 protocol. This service requires use of the HTTP/3.0 protocol.
6.6. Server Error 5xx 6.6. Server Error 5xx
The 5xx (Server Error) class of status code indicates that the server The 5xx (Server Error) class of status code indicates that the server
is aware that it has erred or is incapable of performing the is aware that it has erred or is incapable of performing the
requested method. Except when responding to a HEAD request, the requested method. Except when responding to a HEAD request, the
server SHOULD send a representation containing an explanation of the server SHOULD send a representation containing an explanation of the
error situation, and whether it is a temporary or permanent error situation, and whether it is a temporary or permanent
condition. User agents SHOULD display any included representation to condition. A user agent SHOULD display any included representation
the user. These response codes are applicable to any request method. to the user. These response codes are applicable to any request
method.
6.6.1. 500 Internal Server Error 6.6.1. 500 Internal Server Error
The 500 (Internal Server Error) status code indicates that the server The 500 (Internal Server Error) status code indicates that the server
encountered an unexpected condition that prevented it from fulfilling encountered an unexpected condition that prevented it from fulfilling
the request. the request.
6.6.2. 501 Not Implemented 6.6.2. 501 Not Implemented
The 501 (Not Implemented) status code indicates that the server does The 501 (Not Implemented) status code indicates that the server does
not support the functionality required to fulfill the request. This not support the functionality required to fulfill the request. This
is the appropriate response when the server does not recognize the is the appropriate response when the server does not recognize the
request method and is not capable of supporting it for any resource. request method and is not capable of supporting it for any resource.
A 501 response is cacheable unless otherwise indicated by the method A 501 response is cacheable unless otherwise indicated by the method
definition or explicit cache controls (see Section 4.1.2 of [Part6]). definition or explicit cache controls (see Section 4.2.2 of [Part6]).
6.6.3. 502 Bad Gateway 6.6.3. 502 Bad Gateway
The 502 (Bad Gateway) status code indicates that the server, while The 502 (Bad Gateway) status code indicates that the server, while
acting as a gateway or proxy, received an invalid response from an acting as a gateway or proxy, received an invalid response from an
inbound server it accessed while attempting to fulfill the request. inbound server it accessed while attempting to fulfill the request.
6.6.4. 503 Service Unavailable 6.6.4. 503 Service Unavailable
The 503 (Service Unavailable) status code indicates that the server The 503 (Service Unavailable) status code indicates that the server
skipping to change at page 63, line 18 skipping to change at page 64, line 19
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 7.1 of [Part6] | | Age | Section 5.1 of [Part6] |
| Cache-Control | Section 7.2 of [Part6] | | Cache-Control | Section 5.2 of [Part6] |
| Expires | Section 7.3 of [Part6] | | Expires | Section 5.3 of [Part6] |
| 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 7.5 of [Part6] | | Warning | Section 5.5 of [Part6] |
+-------------------+------------------------+ +-------------------+------------------------+
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
skipping to change at page 63, line 50 skipping to change at page 64, line 51
An example of the preferred format is An example of the preferred format is
Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate
Examples of the two obsolete formats are Examples of the two obsolete formats are
Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
A recipient that parses a timestamp value in an HTTP header field A recipient that parses a timestamp value in an HTTP header field
MUST accept all three formats. A sender MUST generate the IMF- MUST accept all three HTTP-date formats. When a sender generates a
fixdate format when sending an HTTP-date value in a header field. header field that contains one or more timestamps defined as HTTP-
date, the sender MUST generate those timestamps in the IMF-fixdate
format.
An HTTP-date value represents time as an instance of Coordinated An HTTP-date value represents time as an instance of Coordinated
Universal Time (UTC). The first two formats indicate UTC by the Universal Time (UTC). The first two formats indicate UTC by the
three-letter abbreviation for Greenwich Mean Time, "GMT", a three-letter abbreviation for Greenwich Mean Time, "GMT", a
predecessor of the UTC name; values in the asctime format are assumed predecessor of the UTC name; values in the asctime format are assumed
to be in UTC. A sender that generates HTTP-date values from a local to be in UTC. A sender that generates HTTP-date values from a local
clock ought to use NTP ([RFC1305]) or some similar protocol to clock ought to use NTP ([RFC1305]) or some similar protocol to
synchronize its clock to UTC. synchronize its clock to UTC.
Preferred format: Preferred format:
skipping to change at page 65, line 32 skipping to change at page 67, line 27
date3 = month SP ( 2DIGIT / ( SP 1DIGIT )) date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; e.g., Jun 2 ; e.g., Jun 2
HTTP-date is case sensitive. A sender MUST NOT generate additional HTTP-date is case sensitive. A sender MUST NOT generate additional
whitespace in an HTTP-date beyond that specifically included as SP in whitespace in an HTTP-date beyond that specifically included as SP in
the grammar. The semantics of day-name, day, month, year, and time- the grammar. The semantics of day-name, day, month, year, and time-
of-day are the same as those defined for the Internet Message Format of-day are the same as those defined for the Internet Message Format
constructs with the corresponding name ([RFC5322], Section 3.3). constructs with the corresponding name ([RFC5322], Section 3.3).
Recipients of a timestamp value in rfc850-date format, which uses a Recipients of a timestamp value in rfc850-date format, which uses a
two-digit year, SHOULD interpret a timestamp that appears to be more two-digit year, MUST interpret a timestamp that appears to be more
than 50 years in the future as representing the most recent year in than 50 years in the future as representing the most recent year in
the past that had the same last two digits. the past that had the same last two digits.
Recipients of timestamp values are encouraged to be robust in parsing Recipients of timestamp values are encouraged to be robust in parsing
timestamps unless otherwise restricted by the field definition. For timestamps unless otherwise restricted by the field definition. For
example, messages are occasionally forwarded over HTTP from a non- example, messages are occasionally forwarded over HTTP from a non-
HTTP source that might generate any of the date and time HTTP source that might generate any of the date and time
specifications defined by the Internet Message Format. specifications defined by the Internet Message Format.
Note: HTTP requirements for the date/time stamp format apply only Note: HTTP requirements for the date/time stamp format apply only
skipping to change at page 66, line 33 skipping to change at page 68, line 24
An origin server MUST NOT send a Date header field if it does not An origin server MUST NOT send a Date header field if it does not
have a clock capable of providing a reasonable approximation of the have a clock capable of providing a reasonable approximation of the
current instance in Coordinated Universal Time. An origin server MAY current instance in Coordinated Universal Time. An origin server MAY
send a Date header field if the response is in the 1xx send a Date header field if the response is in the 1xx
(Informational) or 5xx (Server Error) class of status codes. An (Informational) or 5xx (Server Error) class of status codes. An
origin server MUST send a Date header field in all other cases. origin server MUST send a Date header field in all other cases.
A recipient with a clock that receives a response message without a A recipient with a clock that receives a response message without a
Date header field MUST record the time it was received and append a Date header field MUST record the time it was received and append a
corresponding Date header field to the message's header block if it corresponding Date header field to the message's header section if it
is cached or forwarded downstream. is cached or forwarded downstream.
A user agent MAY send a Date header field in a request, though A user agent MAY send a Date header field in a request, though
generally will not do so unless it is believed to convey useful generally will not do so unless it is believed to convey useful
information to the server. For example, custom applications of HTTP information to the server. For example, custom applications of HTTP
might convey a Date if the server is expected to adjust its might convey a Date if the server is expected to adjust its
interpretation of the user's request based on differences between the interpretation of the user's request based on differences between the
user agent and server clocks. user agent and server clocks.
7.1.2. Location 7.1.2. Location
skipping to change at page 67, line 13 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.
When Location is provided in a 3xx (Redirection) response and the URI If the Location value provided in a 3xx (Redirection) does not have a
reference that the user agent used to generate the request target fragment component, a user agent MUST process the redirection as if
contains a fragment identifier, the user agent SHOULD process the the value inherits the fragment component of the URI reference used
redirection as if the Location field value inherits the original to generate the request target (i.e., the redirection inherits the
fragment. In other words, if the Location does not have a fragment original reference's fragment, if any).
component, the user agent SHOULD interpret the Location reference as
if it had the original reference's fragment.
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 68, line 40 skipping to change at page 70, line 26
Two examples of its use are Two examples of its use are
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120 Retry-After: 120
In the latter example, the delay is 2 minutes. In the latter example, the delay is 2 minutes.
7.1.4. Vary 7.1.4. Vary
The "Vary" header field describes what parts of a request message, The "Vary" header field in a response describes what parts of a
aside from the method, the Host header field and the request target, request message, aside from the method, Host header field, and
might influence the origin server's process for selecting and request target, might influence the origin server's process for
representing the response. The value consists of either a single selecting and representing this response. The value consists of
asterisk ("*") or a list of header field names (case-insensitive). either a single asterisk ("*") or a list of header field names (case-
insensitive).
Vary = "*" / 1#field-name Vary = "*" / 1#field-name
A Vary field value of "*" signals that anything about the request A Vary field value of "*" signals that anything about the request
might play a role in selecting the response representation, possibly might play a role in selecting the response representation, possibly
including elements outside the message syntax (e.g., the client's including elements outside the message syntax (e.g., the client's
network address), and thus a recipient will not be able to determine network address), and thus a recipient will not be able to determine
whether this response is appropriate for a later request without whether this response is appropriate for a later request without
forwarding the request to the origin server. A proxy MUST NOT forwarding the request to the origin server. A proxy MUST NOT
generate a Vary field with a "*" value. generate a Vary field with a "*" value.
skipping to change at page 69, line 26 skipping to change at page 71, line 18
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.3 values for the listed fields as the original request (Section 4.1
of [Part6]). In other words, Vary expands the cache key required of [Part6]). In other words, Vary expands the cache key required
to match a new request to the stored cache entry. 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.1 of across users is constrained by the field definition (Section 4.1 of
[Part7]). Likewise, an origin server might use Cache-Control [Part7]). Likewise, an origin server might use Cache-Control
directives (Section 7.2 of [Part6]) to supplant Vary if it considers directives (Section 5.2 of [Part6]) to supplant Vary if it considers
the variance less significant than the performance cost of Vary's the variance less significant than the performance cost of Vary's
impact on caching. 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
skipping to change at page 77, line 23 skipping to change at page 78, line 23
Authors of specifications defining new fields are advised to keep the Authors of specifications defining new fields are advised to keep the
name as short as practical and to not prefix the name with "X-" name as short as practical and to not prefix the name with "X-"
unless the header field will never be used on the Internet. (The unless the header field will never be used on the Internet. (The
"x-" prefix idiom has been extensively misused in practice; it was "x-" prefix idiom has been extensively misused in practice; it was
intended to only be used as a mechanism for avoiding name collisions intended to only be used as a mechanism for avoiding name collisions
inside proprietary software or intranet processing, since the prefix inside proprietary software or intranet processing, since the prefix
would ensure that private names never collide with a newly registered would ensure that private names never collide with a newly registered
Internet name.) Internet name.)
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 Appendix B of ABNF ([RFC5234]), using the extension defined in Section 7 of [Part1]
[Part1] as necessary, and are usually constrained to the range of as necessary, and are usually constrained to the range of ASCII
ASCII characters. Header fields needing a greater range of characters. Header fields needing a greater range of characters can
characters can use an encoding such as the one defined in [RFC5987]. use an encoding such as the one defined in [RFC5987].
Leading and trailing whitespace in raw field values is removed upon Leading and trailing whitespace in raw field values is removed upon
field parsing (Section 3.2.4 of [Part1]). Field definitions where field parsing (Section 3.2.4 of [Part1]). Field definitions where
leading or trailing whitespace in values is significant will have to leading or trailing whitespace in values is significant will have to
use a container syntax such as quoted-string. use a container syntax such as quoted-string.
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
skipping to change at page 83, line 10 skipping to change at page 84, line 10
cookies). Many general-purpose user agents (i.e., Web browsers) have cookies). Many general-purpose user agents (i.e., Web browsers) have
taken steps to reduce their fingerprints. taken steps to reduce their fingerprints.
There are a number of request header fields that might reveal There are a number of request header fields that might reveal
information to servers that is sufficiently unique to enable information to servers that is sufficiently unique to enable
fingerprinting. The From header field is the most obvious, though it fingerprinting. The From header field is the most obvious, though it
is expected that From will only be sent when self-identification is is expected that From will only be sent when self-identification is
desired by the user. Likewise, Cookie header fields are deliberately desired by the user. Likewise, Cookie header fields are deliberately
designed to enable re-identification, so we can assume that designed to enable re-identification, so we can assume that
fingerprinting concerns only apply to situations where cookies are fingerprinting concerns only apply to situations where cookies are
disabled or restricted by browser configuration. disabled or restricted by the user agent's configuration.
The User-Agent header field might contain enough information to The User-Agent header field might contain enough information to
uniquely identify a specific device, usually when combined with other uniquely identify a specific device, usually when combined with other
characteristics, particularly if the user agent sends excessive characteristics, particularly if the user agent sends excessive
details about the user's system or extensions. However, the source details about the user's system or extensions. However, the source
of unique information that is least expected by users is proactive of unique information that is least expected by users is proactive
negotiation (Section 5.3), including the Accept, Accept-Charset, negotiation (Section 5.3), including the Accept, Accept-Charset,
Accept-Encoding, and Accept-Language header fields. Accept-Encoding, and Accept-Language header fields.
In addition to the fingerprinting concern, detailed use of the In addition to the fingerprinting concern, detailed use of the
skipping to change at page 83, line 40 skipping to change at page 84, line 40
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 9 of [Part1]. See Section 10 of [Part1].
11. References 11. References
11.1. Normative References 11.1. Normative References
[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Message Syntax and Transfer Protocol (HTTP/1.1): Message Syntax and
Routing", draft-ietf-httpbis-p1-messaging-23 (work in Routing", draft-ietf-httpbis-p1-messaging-24 (work in
progress), July 2013. progress), September 2013.
[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Conditional Requests", Transfer Protocol (HTTP/1.1): Conditional Requests",
draft-ietf-httpbis-p4-conditional-23 (work in draft-ietf-httpbis-p4-conditional-24 (work in
progress), July 2013. progress), September 2013.
[Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [Part5] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range "Hypertext Transfer Protocol (HTTP/1.1): Range
Requests", draft-ietf-httpbis-p5-range-23 (work in Requests", draft-ietf-httpbis-p5-range-24 (work in
progress), July 2013. progress), September 2013.
[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-23 (work in progress), draft-ietf-httpbis-p6-cache-24 (work in progress),
July 2013. September 2013.
[Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext [Part7] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
Transfer Protocol (HTTP/1.1): Authentication", Transfer Protocol (HTTP/1.1): Authentication",
draft-ietf-httpbis-p7-auth-23 (work in progress), draft-ietf-httpbis-p7-auth-24 (work in progress),
July 2013. September 2013.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
Format Specification version 3.3", RFC 1950, May 1996. Format Specification version 3.3", RFC 1950, May 1996.
[RFC1951] Deutsch, P., "DEFLATE Compressed Data Format [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC 1951, May 1996. Specification version 1.3", RFC 1951, May 1996.
[RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and [RFC1952] Deutsch, P., Gailly, J-L., Adler, M., Deutsch, L., and
G. Randers-Pehrson, "GZIP file format specification G. Randers-Pehrson, "GZIP file format specification
version 4.3", RFC 1952, May 1996. version 4.3", RFC 1952, May 1996.
skipping to change at page 89, line 16 skipping to change at page 90, line 16
that might be contained therein. 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. An algorithm has representations and representations from resources.
been added for determining if a payload is associated with a specific
identifier (Section 3.1.4.1).
A new requirement has been added that semantics embedded in a URI A new requirement has been added that semantics embedded in a URI
should be disabled when those semantics are inconsistent with the should be disabled when those semantics are inconsistent with the
request method, since this is a common cause of interoperability request method, since this is a common cause of interoperability
failure. failure. (Section 2)
The default charset of ISO-8859-1 for text media types has been An algorithm has been added for determining if a payload is
removed; the default is now whatever the media type definition says associated with a specific identifier. (Section 3.1.4.1)
(Section 3.1.1.3). Likewise, special treatment of ISO-8859-1 has
been removed from the Accept-Charset header field (Section 5.3.3).
The Content-Disposition header field has been removed since it is now The default charset of ISO-8859-1 for text media types has been
defined by [RFC6266]. removed; the default is now whatever the media type definition says.
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)
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)
The Content-MD5 header field has been removed because it was
inconsistently implemented with respect to partial responses.
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 [Part1], the definition of GET has been relaxed so that requests can
have a body, even though a body has no meaning for GET 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 (Section 4.3.7) and TRACE (Section 4.3.8) request methods
have been defined as being safe.
The definition of Expect has been both fixed to allow parameters for The OPTIONS and TRACE request methods have been defined as being
value-less expectations and simplified to allow trailing semicolons safe. (Section 4.3.7 and Section 4.3.8)
after "100-continue" (Section 5.1.1). The Expect header field's extension mechanism has been removed due to
widely-deployed broken implementations. (Section 5.1.1)
The Max-Forwards header field (Section 5.1.2) has been restricted to The Max-Forwards header field has been restricted to the OPTIONS and
the OPTIONS and TRACE methods; previously, extension methods could TRACE methods; previously, extension methods could have used it as
have used it as well. well. (Section 5.1.2)
The "about:blank" URI has been suggested as a value for the Referer The "about:blank" URI has been suggested as a value for the Referer
header field when no referring URI is applicable, which distinguishes header field when no referring URI is applicable, which distinguishes
that case from others where the Referer field is not sent or has been that case from others where the Referer field is not sent or has been
removed (Section 5.5.2). removed. (Section 5.5.2)
The following status codes are now cacheable (that is, they can be
stored and reused by a cache without explicit freshness information
present): 204, 404, 405, 414, 501. (Section 6)
The 201 (Created) status description has been changed to allow for The 201 (Created) status description has been changed to allow for
the possibility that more than one resource has been created the possibility that more than one resource has been created.
(Section 6.3.2). (Section 6.3.2)
The definition of 203 (Non-Authoritative Information) has been The definition of 203 (Non-Authoritative Information) has been
broadened to include cases of payload transformations as well broadened to include cases of payload transformations as well.
(Section 6.3.4). (Section 6.3.4)
The redirect status codes 301, 302, and 307 no longer have normative The set of request methods that are safe to automatically redirect is
requirements on response payloads and user interaction (Section 6.4). no longer closed; user agents are able to make that determination
based upon the request method semantics. The redirect status codes
301, 302, and 307 no longer have normative requirements on response
payloads and user interaction. (Section 6.4)
The request methods that are safe to automatically redirect is no The status codes 301 and 302 have been changed to allow user agents
longer a closed set; user agents are able to make that determination to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3)
based upon the request method semantics (Section 6.4).
The description of 303 (See Other) status code has been changed to The description of 303 (See Other) status code has been changed to
allow it to be cached if explicit freshness information is given, and allow it to be cached if explicit freshness information is given, and
a specific definition has been added for a 303 response to GET a specific definition has been added for a 303 response to GET.
(Section 6.4.4). (Section 6.4.4)
The status codes 301 and 302 (sections 6.4.2 and 6.4.3) have been
changed to allow user agents to rewrite the method from POST to GET.
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).
The following status codes are now cacheable (that is, they can be
stored and reused by a cache without explicit freshness information
present): 204, 404, 405, 414, 501.
Allow has been reclassified as a response header field, removing the
option to specify it in a PUT request. Requirements relating to the
content of Allow have been relaxed; correspondingly, clients are not
required to always trust its value (Section 7.4.1).
The target of requirements on HTTP-date and the Date header field The target of requirements on HTTP-date and the Date header field
have been reduced to those systems generating the date, rather than have been reduced to those systems generating the date, rather than
all systems sending a date (Section 7.1.1). all systems sending a date. (Section 7.1.1)
The syntax of the Location header field has been changed to allow all The syntax of the Location header field has been changed to allow all
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)
A Method Registry has been defined (Section 8.1). Allow has been reclassified as a response header field, removing the
option to specify it in a PUT request. Requirements relating to the
content of Allow have been relaxed; correspondingly, clients are not
required to always trust its value. (Section 7.4.1)
The Status Code Registry (Section 8.2) has been redefined by this A Method Registry has been defined. (Section 8.1)
specification; previously, it was defined in Section 7.1 of
[RFC2817]. The Status Code Registry has been redefined by this specification;
previously, it was defined in Section 7.1 of [RFC2817].
(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
defined by [RFC6266].
The Content-MD5 header field has been removed because it was
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).
skipping to change at page 92, line 43 skipping to change at page 93, line 43
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
Expect = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] ) Expect = "100-continue"
From = mailbox From = mailbox
GMT = %x47.4D.54 ; GMT GMT = %x47.4D.54 ; GMT
HTTP-date = IMF-fixdate / obs-date HTTP-date = IMF-fixdate / obs-date
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
Location = URI-reference Location = URI-reference
skipping to change at page 94, line 4 skipping to change at page 95, line 4
/ %x53.61.74 ; Sat / %x53.61.74 ; Sat
/ %x53.75.6E ; Sun / %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday / %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday / %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday / %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday / %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday / %x53.75.6E.64.61.79 ; Sunday
delta-seconds = 1*DIGIT delta-seconds = 1*DIGIT
expect-name = token
expect-param = expect-name [ BWS "=" BWS expect-value ]
expect-value = token / quoted-string
expectation = expect-name [ BWS "=" BWS expect-value ] *( OWS ";" [
OWS expect-param ] )
field-name = <comment, defined in [Part1], Section 3.2> field-name = <comment, defined in [Part1], Section 3.2>
hour = 2DIGIT hour = 2DIGIT
language-range = <language-range, defined in [RFC4647], Section 2.1> language-range = <language-range, defined in [RFC4647], Section 2.1>
language-tag = <Language-Tag, defined in [RFC5646], Section 2.1> language-tag = <Language-Tag, defined in [RFC5646], Section 2.1>
mailbox = <mailbox, defined in [RFC5322], Section 3.4> mailbox = <mailbox, defined in [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" OWS parameter ) ";" OWS parameter )
skipping to change at page 96, line 24 skipping to change at page 97, line 18
o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in o <http://tools.ietf.org/wg/httpbis/trac/ticket/434>: "mention in
header field considerations that leading/trailing WS is lossy" header field considerations that leading/trailing WS is lossy"
E.3. Since draft-ietf-httpbis-p2-semantics-22 E.3. Since draft-ietf-httpbis-p2-semantics-22
Closed issues: Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list
expansion in ABNF appendices" expansion in ABNF appendices"
o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/448>: "Fallback o <http://tools.ietf.org/wg/httpbis/trac/ticket/448>: "Fallback for
for Accept-Language" Accept-Language"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a o <http://tools.ietf.org/wg/httpbis/trac/ticket/449>: "Receiving a
higher minor HTTP version number" higher minor HTTP version number"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/456>: "Language-tag o <http://tools.ietf.org/wg/httpbis/trac/ticket/456>: "Language-tag
vs. language-range" vs. language-range"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering o <http://tools.ietf.org/wg/httpbis/trac/ticket/457>: "Registering
x-gzip and x-deflate" x-gzip and x-deflate"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/459>: "RFC2774 and o <http://tools.ietf.org/wg/httpbis/trac/ticket/459>: "RFC2774 and
method registrations" method registrations"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/488>: "Selection o <http://tools.ietf.org/wg/httpbis/trac/ticket/488>: "Selection
based upon request target" based upon request target"
E.4. Since draft-ietf-httpbis-p2-semantics-23
Closed issues:
o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response
isn't generic"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/450>: "p2 Editorial
feedback"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/452>: "Content-
Length in HEAD responses"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/458>: "Requirements
upon proxies for Expect"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/468>: "Expectation
Extensions"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/470>: "What is
'Cacheable'?"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/478>: "MUSTs and
other feedback"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/487>: "Resubmission
of 403"
o <http://tools.ietf.org/wg/httpbis/trac/ticket/491>: "does 205
allow chunked encoding?"
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) 50 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) 52
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) 61 501 Not Implemented (status code) 62
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 23 cacheable 24
compress (content coding) 11 compress (content coding) 11
conditional request 36 conditional request 36
CONNECT method 29 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 88 Content-Transfer-Encoding header field 89
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 28 DELETE method 29
E E
Expect header field 33 Expect header field 34
Expect Values
100-continue 33
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 65 asctime-date 67
attribute 8 attribute 8
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 64 date1 66
day 64 day 66
day-name 64 day-name 66
day-name-l 64 day-name-l 66
delta-seconds 68 delta-seconds 70
Expect 33 Expect 34
expect-name 33
expect-param 33
expect-value 33
expectation 33
From 44 From 44
GMT 64 GMT 66
hour 64 hour 66
HTTP-date 63 HTTP-date 64
IMF-fixdate 64 IMF-fixdate 66
language-range 42 language-range 42
language-tag 13 language-tag 13
Location 66 Location 68
Max-Forwards 36 Max-Forwards 36
media-range 38 media-range 38
media-type 8 media-type 8
method 20 method 21
minute 64 minute 66
month 64 month 66
obs-date 65 obs-date 66
parameter 8 parameter 8
product 46 product 46
product-version 46 product-version 46
qvalue 37 qvalue 38
Referer 45 Referer 45
Retry-After 68 Retry-After 70
rfc850-date 65 rfc850-date 67
second 64 second 66
Server 71 Server 73
subtype 8 subtype 8
time-of-day 64 time-of-day 66
type 8 type 8
User-Agent 46 User-Agent 46
value 8 value 8
Vary 68 Vary 70
weight 37 weight 38
year 64 year 66
gzip (content coding) 11 gzip (content coding) 11
H H
HEAD method 24 HEAD method 25
I I
idempotent 23 idempotent 23
L L
Location header field 66 Location header field 68
M M
Max-Forwards header field 36 Max-Forwards header field 36
MIME-Version header field 87 MIME-Version header field 88
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, 69 selected representation 7, 71
Server header field 71 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 45 User-Agent header field 46
V V
Vary header field 68 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. 208 change blocks. 
655 lines changed or deleted 685 lines changed or added

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