rfc7231.txt   draft-ietf-httpbis-semantics-00.txt 
Internet Engineering Task Force (IETF) R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Request for Comments: 7231 Adobe Internet-Draft Adobe
Obsoletes: 2616 J. Reschke, Ed. Obsoletes: 7231 (if approved) M. Nottingham, Ed.
Updates: 2817 greenbytes Intended status: Standards Track Fastly
Category: Standards Track June 2014 Expires: October 5, 2018 J. Reschke, Ed.
ISSN: 2070-1721 greenbytes
April 3, 2018
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Hypertext Transfer Protocol (HTTP): Semantics and Content
draft-ietf-httpbis-semantics-00
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP/1.1 messages, systems. This document defines the semantics of HTTP/1.1 messages,
as expressed by request methods, request header fields, response as expressed by request methods, request header fields, response
status codes, and response header fields, along with the payload of status codes, and response header fields, along with the payload of
messages (metadata and body content) and mechanisms for content messages (metadata and body content) and mechanisms for content
negotiation. negotiation.
This document obsoletes RFC 7231.
Editorial Note
This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <http://httpwg.github.io/>;
source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix E.1.
Status of This Memo Status of This Memo
This is an Internet Standards Track document. This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
This document is a product of the Internet Engineering Task Force Internet-Drafts are working documents of the Internet Engineering
(IETF). It represents the consensus of the IETF community. It has Task Force (IETF). Note that other groups may also distribute
received public review and has been approved for publication by the working documents as Internet-Drafts. The list of current Internet-
Internet Engineering Steering Group (IESG). Further information on Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet Standards is available in Section 2 of RFC 5741.
Information about the current status of this document, any errata, Internet-Drafts are draft documents valid for a maximum of six months
and how to provide feedback on it may be obtained at and may be updated, replaced, or obsoleted by other documents at any
http://www.rfc-editor.org/info/rfc7231. time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 5, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2018 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 (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 3, line 7 skipping to change at page 2, line 41
modifications of such material outside the IETF Standards Process. modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction ....................................................6 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Representations .................................................7 3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Representation Metadata ....................................8 3.1. Representation Metadata . . . . . . . . . . . . . . . . . 7
3.1.1. Processing Representation Data ......................8 3.1.1. Processing Representation Data . . . . . . . . . . . 8
3.1.2. Encoding for Compression or Integrity ..............11 3.1.2. Encoding for Compression or Integrity . . . . . . . . 11
3.1.3. Audience Language ..................................13 3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 12
3.1.4. Identification .....................................14 3.1.4. Identification . . . . . . . . . . . . . . . . . . . 14
3.2. Representation Data .......................................17 3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17
3.3. Payload Semantics .........................................17 3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17
3.4. Content Negotiation .......................................18 3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18
3.4.1. Proactive Negotiation ..............................19 3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 18
3.4.2. Reactive Negotiation ...............................20 3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 20
4. Request Methods ................................................21 4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21
4.1. Overview ..................................................21 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2. Common Method Properties ..................................22 4.2. Common Method Properties . . . . . . . . . . . . . . . . 22
4.2.1. Safe Methods .......................................22 4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 22
4.2.2. Idempotent Methods .................................23 4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 23
4.2.3. Cacheable Methods ..................................24 4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24
4.3. Method Definitions ........................................24 4.3. Method Definitions . . . . . . . . . . . . . . . . . . . 24
4.3.1. GET ................................................24 4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.2. HEAD ...............................................25 4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.3. POST ...............................................25 4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3.4. PUT ................................................26 4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.5. DELETE .............................................29 4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 29
4.3.6. CONNECT ............................................30 4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30
4.3.7. OPTIONS ............................................31 4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31
4.3.8. TRACE ..............................................32 4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32
5. Request Header Fields ..........................................33 5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33
5.1. Controls ..................................................33 5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 33
5.1.1. Expect .............................................34 5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 34
5.1.2. Max-Forwards .......................................36 5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 36
5.2. Conditionals ..............................................36 5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . 37
5.3. Content Negotiation .......................................37 5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37
5.3.1. Quality Values .....................................37 5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . 38
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 . . . . . . . . . . . . . . . . . . . 43
5.4. Authentication Credentials ................................44 5.4. Authentication Credentials . . . . . . . . . . . . . . . 44
5.5. Request Context ...........................................44 5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44
5.5.1. From ...............................................44 5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . 44
5.5.2. Referer ............................................45 5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45
5.5.3. User-Agent .........................................46 5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . 46
6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47
6. Response Status Codes ..........................................47 6.1. Overview of Status Codes . . . . . . . . . . . . . . . . 48
6.1. Overview of Status Codes ..................................48 6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50
6.2. Informational 1xx .........................................50 6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . 50
6.2.1. 100 Continue .......................................50 6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50
6.2.2. 101 Switching Protocols ............................50 6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . 51
6.3. Successful 2xx ............................................51 6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . 51
6.3.1. 200 OK .............................................51 6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 52
6.3.2. 201 Created ........................................52 6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . 52
6.3.3. 202 Accepted .......................................52 6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52
6.3.4. 203 Non-Authoritative Information ..................52 6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . 53
6.3.5. 204 No Content .....................................53 6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53
6.3.6. 205 Reset Content ..................................53 6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54
6.4. Redirection 3xx ...........................................54 6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . 55
6.4.1. 300 Multiple Choices ...............................55 6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56
6.4.2. 301 Moved Permanently ..............................56 6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 57
6.4.3. 302 Found ..........................................56 6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57
6.4.4. 303 See Other ......................................57 6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 58
6.4.5. 305 Use Proxy ......................................58 6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . 58
6.4.6. 306 (Unused) .......................................58 6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . 58
6.4.7. 307 Temporary Redirect .............................58 6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . 58
6.5. Client Error 4xx ..........................................58 6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 59
6.5.1. 400 Bad Request ....................................58 6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . 59
6.5.2. 402 Payment Required ...............................59 6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 59
6.5.3. 403 Forbidden ......................................59 6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59
6.5.4. 404 Not Found ......................................59 6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . 59
6.5.5. 405 Method Not Allowed .............................59 6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . 60
6.5.6. 406 Not Acceptable .................................60 6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60
6.5.7. 408 Request Timeout ................................60 6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . 60
6.5.8. 409 Conflict .......................................60 6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . 61
6.5.9. 410 Gone ...........................................60 6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61
6.5.10. 411 Length Required ...............................61 6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61
6.5.11. 413 Payload Too Large .............................61 6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . 62
6.5.12. 414 URI Too Long ..................................61 6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . 62
6.5.13. 415 Unsupported Media Type ........................62 6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . 62
6.5.14. 417 Expectation Failed ............................62 6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . 62
6.5.15. 426 Upgrade Required ..............................62 6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . 63
6.6. Server Error 5xx ..........................................62 6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 63
6.6.1. 500 Internal Server Error ..........................63 6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63
6.6.2. 501 Not Implemented ................................63 6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63
6.6.3. 502 Bad Gateway ....................................63 6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 64
6.6.4. 503 Service Unavailable ............................63 6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 64
6.6.5. 504 Gateway Timeout ................................63 6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . 64
6.6.6. 505 HTTP Version Not Supported .....................64 7. Response Header Fields . . . . . . . . . . . . . . . . . . . 64
7. Response Header Fields .........................................64 7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . 64
7.1. Control Data ..............................................64 7.1.1. Origination Date . . . . . . . . . . . . . . . . . . 65
ed 7.1.1. Origination Date ...................................65 7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . 68
7.1.2. Location ...........................................68 7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69
7.1.3. Retry-After ........................................69 7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . 70
7.1.4. Vary ...............................................70 7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71
7.2. Validator Header Fields ...................................71 7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72
7.3. Authentication Challenges .................................72 7.4. Response Context . . . . . . . . . . . . . . . . . . . . 72
7.4. Response Context ..........................................72 7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72
7.4.1. Allow ..............................................72 7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . 73
7.4.2. Server .............................................73 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
8. IANA Considerations ............................................73 8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74
8.1. Method Registry ...........................................73 8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74
8.1.1. Procedure ..........................................74 8.1.2. Considerations for New Methods . . . . . . . . . . . 74
8.1.2. Considerations for New Methods .....................74 8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75
8.1.3. Registrations ......................................75 8.2. Status Code Registry . . . . . . . . . . . . . . . . . . 75
8.2. Status Code Registry ......................................75 8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75
8.2.1. Procedure ..........................................75 8.2.2. Considerations for New Status Codes . . . . . . . . . 76
8.2.2. Considerations for New Status Codes ................76 8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 77
8.2.3. Registrations ......................................76 8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 78
8.3. Header Field Registry .....................................77 8.3.1. Considerations for New Header Fields . . . . . . . . 78
8.3.1. Considerations for New Header Fields ...............78 8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80
8.3.2. Registrations ......................................80 8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 81
8.4. Content Coding Registry ...................................81 8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 81
8.4.1. Procedure ..........................................81 8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81
8.4.2. Registrations ......................................81 9. Security Considerations . . . . . . . . . . . . . . . . . . . 81
9. Security Considerations ........................................81 9.1. Attacks Based on File and Path Names . . . . . . . . . . 82
9.1. Attacks Based on File and Path Names ......................82 9.2. Attacks Based on Command, Code, or Query Injection . . . 82
9.2. Attacks Based on Command, Code, or Query Injection ........82 9.3. Disclosure of Personal Information . . . . . . . . . . . 83
9.3. Disclosure of Personal Information ........................83 9.4. Disclosure of Sensitive Information in URIs . . . . . . . 83
9.4. Disclosure of Sensitive Information in URIs ...............83 9.5. Disclosure of Fragment after Redirects . . . . . . . . . 84
9.5. Disclosure of Fragment after Redirects ....................84 9.6. Disclosure of Product Information . . . . . . . . . . . . 84
9.6. Disclosure of Product Information .........................84 9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . 84
9.7. Browser Fingerprinting ....................................84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 85
10. Acknowledgments ...............................................85 10.1. Normative References . . . . . . . . . . . . . . . . . . 85
11. References ....................................................85 10.2. Informative References . . . . . . . . . . . . . . . . . 87
11.1. Normative References .....................................85 Appendix A. Differences between HTTP and MIME . . . . . . . . . 90
11.2. Informative References ...................................86 A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . 90
Appendix A. Differences between HTTP and MIME .....................89 A.2. Conversion to Canonical Form . . . . . . . . . . . . . . 90
A.1. MIME-Version ..............................................89 A.3. Conversion of Date Formats . . . . . . . . . . . . . . . 91
A.2. Conversion to Canonical Form ..............................89 A.4. Conversion of Content-Encoding . . . . . . . . . . . . . 91
A.3. Conversion of Date Formats ................................90 A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 91
A.4. Conversion of Content-Encoding ............................90 A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 91
A.5. Conversion of Content-Transfer-Encoding ...................90 Appendix B. Changes from RFC 7231 . . . . . . . . . . . . . . . 92
A.6. MHTML and Line Length Limitations .........................90 Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . 92
Appendix B. Changes from RFC 2616 .................................91 Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 92
Appendix C. Imported ABNF .........................................93 Appendix E. Change Log . . . . . . . . . . . . . . . . . . . . . 95
Appendix D. Collected ABNF ........................................94 E.1. Since RFC 7231 . . . . . . . . . . . . . . . . . . . . . 95
Index .............................................................97 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 100
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 100
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, examines request messages to communicate specific intentions, examines
received responses to see if the intentions were carried out, and received responses to see if the intentions were carried out, and
determines how to interpret the results. This document defines determines how to interpret the results. This document defines
HTTP/1.1 request and response semantics in terms of the architecture HTTP/1.1 request and response semantics in terms of the architecture
defined in [RFC7230]. defined in [MESSGNG].
HTTP provides a uniform interface for interacting with a resource HTTP provides a uniform interface for interacting with a resource
(Section 2), regardless of its type, nature, or implementation, via (Section 2), regardless of its type, nature, or implementation, via
the manipulation and transfer of representations (Section 3). the manipulation and transfer of representations (Section 3).
HTTP semantics include the intentions defined by each request method HTTP semantics include the intentions defined by each request method
(Section 4), extensions to those semantics that might be described in (Section 4), extensions to those semantics that might be described in
request header fields (Section 5), the meaning of status codes to request header fields (Section 5), the meaning of status codes to
indicate a machine-readable response (Section 6), and the meaning of indicate a machine-readable response (Section 6), and the meaning of
other control data and resource metadata that might be given in other control data and resource metadata that might be given in
response header fields (Section 7). response header fields (Section 7).
This document also defines representation metadata that describe how This document also defines representation metadata that describe how
a payload is intended to be interpreted by a recipient, the request a payload is intended to be interpreted by a recipient, the request
header fields that might influence content selection, and the various header fields that might influence content selection, and the various
selection algorithms that are collectively referred to as "content selection algorithms that are collectively referred to as "content
negotiation" (Section 3.4). negotiation" (Section 3.4).
This specification obsoletes RFC 7231, with the changes being
summarized in Appendix B.
1.1. Conformance and Error Handling 1.1. Conformance and Error Handling
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Conformance criteria and considerations regarding error handling are Conformance criteria and considerations regarding error handling are
defined in Section 2.5 of [RFC7230]. defined in Section 2.5 of [MESSGNG].
1.2. Syntax Notation 1.2. Syntax Notation
This specification uses the Augmented Backus-Naur Form (ABNF) This specification uses the Augmented Backus-Naur Form (ABNF)
notation of [RFC5234] with a list extension, defined in Section 7 of notation of [RFC5234] with a list extension, defined in Section 7 of
[RFC7230], that allows for compact definition of comma-separated [MESSGNG], that allows for compact definition of comma-separated
lists using a '#' operator (similar to how the '*' operator indicates lists using a '#' operator (similar to how the '*' operator indicates
repetition). Appendix C describes rules imported from other repetition). Appendix C describes rules imported from other
documents. Appendix D shows the collected grammar with all list documents. Appendix D shows the collected grammar with all list
operators expanded to standard ABNF notation. operators expanded to standard ABNF notation.
This specification uses the terms "character", "character encoding This specification uses the terms "character", "character encoding
scheme", "charset", and "protocol element" as they are defined in scheme", "charset", and "protocol element" as they are defined in
[RFC6365]. [RFC6365].
2. Resources 2. Resources
The target of an HTTP request is called a "resource". HTTP does not The target of an HTTP request is called a "resource". HTTP does 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 [RFC7230]. Section 2.7 of [MESSGNG].
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
[RFC7230]). When a request is received, the server reconstructs an [MESSGNG]). 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
[RFC7230]). [MESSGNG]).
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
semantics in the request method (Section 4) and a few semantics in the request method (Section 4) and a few request-
request-modifying header fields (Section 5). If there is a conflict modifying header fields (Section 5). If there is a conflict between
between the method semantics and any semantic implied by the URI the method semantics and any semantic implied by the URI itself, as
itself, as described in Section 4.2.1, the method semantics take described in Section 4.2.1, the method semantics take precedence.
precedence.
3. Representations 3. Representations
Considering that a resource could be anything, and that the uniform Considering that a resource could be anything, and that the uniform
interface provided by HTTP is similar to a window through which one interface provided by HTTP is similar to a window through which one
can observe and act upon such a thing only through the communication can observe and act upon such a thing only through the communication
of messages to some independent actor on the other side, an of messages to some independent actor on the other side, an
abstraction is needed to represent ("take the place of") the current abstraction is needed to represent ("take the place of") the current
or desired state of that thing in our communications. That or desired state of that thing in our communications. That
abstraction is called a representation [REST]. abstraction is called a representation [REST].
skipping to change at page 8, line 4 skipping to change at page 7, line 42
resource, in a format that can be readily communicated via the resource, in a format that can be readily communicated via the
protocol, and that consists of a set of representation metadata and a protocol, and that consists of a set of representation metadata and a
potentially unbounded stream of representation data. potentially unbounded stream of representation data.
An origin server might be provided with, or be capable of generating, An origin server might be provided with, or be capable of generating,
multiple representations that are each intended to reflect the multiple representations that are each intended to reflect the
current state of a target resource. In such cases, some algorithm is current state of a target resource. In such cases, some algorithm is
used by the origin server to select one of those representations as used by the origin server to select one of those representations as
most applicable to a given request, usually based on content most applicable to a given request, usually based on content
negotiation. This "selected representation" is used to provide the negotiation. This "selected representation" is used to provide the
data and metadata for evaluating conditional requests [RFC7232] and data and metadata for evaluating conditional requests [CONDTNL] and
constructing the payload for 200 (OK) and 304 (Not Modified) constructing the payload for 200 (OK) and 304 (Not Modified)
responses to GET (Section 4.3.1). responses to GET (Section 4.3.1).
3.1. Representation Metadata 3.1. Representation Metadata
Representation header fields provide metadata about the Representation header fields provide metadata about the
representation. When a message includes a payload body, the representation. When a message includes a payload body, the
representation header fields describe how to interpret the representation header fields describe how to interpret the
representation data enclosed in the payload body. In a response to a representation data enclosed in the payload body. In a response to a
HEAD request, the representation header fields describe the HEAD request, the representation header fields describe the
skipping to change at page 10, line 36 skipping to change at page 10, line 25
[RFC2046], and include a boundary parameter as part of the media type [RFC2046], and include a boundary parameter as part of the media type
value. The message body is itself a protocol element; a sender MUST value. The message body is itself a protocol element; a sender MUST
generate only CRLF to represent line breaks between body parts. generate only CRLF to represent line breaks between body parts.
HTTP message framing does not use the multipart boundary as an HTTP message framing does not use the multipart boundary as an
indicator of message body length, though it might be used by indicator of message body length, though it might be used by
implementations that generate or process the payload. For example, implementations that generate or process the payload. For example,
the "multipart/form-data" type is often used for carrying form data the "multipart/form-data" type is often used for carrying form data
in a request, as described in [RFC2388], and the "multipart/ in a request, as described in [RFC2388], and the "multipart/
byteranges" type is defined by this specification for use in some 206 byteranges" type is defined by this specification for use in some 206
(Partial Content) responses [RFC7233]. (Partial Content) responses [RANGERQ].
3.1.1.5. Content-Type 3.1.1.5. Content-Type
The "Content-Type" header field indicates the media type of the The "Content-Type" header field indicates the media type of the
associated representation: either the representation enclosed in the associated representation: either the representation enclosed in the
message payload or the selected representation, as determined by the message payload or the selected representation, as determined by the
message semantics. The indicated media type defines both the data message semantics. The indicated media type defines both the data
format and how that data is intended to be processed by a recipient, format and how that data is intended to be processed by a recipient,
within the scope of the received message semantics, after any content within the scope of the received message semantics, after any content
codings indicated by Content-Encoding are decoded. codings indicated by Content-Encoding are decoded.
skipping to change at page 12, line 8 skipping to change at page 11, line 38
content-coding = token content-coding = token
All content-coding values are case-insensitive and ought to be All content-coding values are case-insensitive and ought to be
registered within the "HTTP Content Coding Registry", as defined in registered within the "HTTP Content Coding Registry", as defined in
Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) Section 8.4. They are used in the Accept-Encoding (Section 5.3.4)
and Content-Encoding (Section 3.1.2.2) header fields. and Content-Encoding (Section 3.1.2.2) header fields.
The following content-coding values are defined by this The following content-coding values are defined by this
specification: specification:
compress (and x-compress): See Section 4.2.1 of [RFC7230]. compress (and x-compress): See Section 4.2.1 of [MESSGNG].
deflate: See Section 4.2.2 of [RFC7230]. deflate: See Section 4.2.2 of [MESSGNG].
gzip (and x-gzip): See Section 4.2.3 of [RFC7230]. gzip (and x-gzip): See Section 4.2.3 of [MESSGNG].
3.1.2.2. Content-Encoding 3.1.2.2. Content-Encoding
The "Content-Encoding" header field indicates what content codings The "Content-Encoding" header field indicates what content codings
have been applied to the representation, beyond those inherent in the have been applied to the representation, beyond those inherent in the
media type, and thus what decoding mechanisms have to be applied in media type, and thus what decoding mechanisms have to be applied in
order to obtain data in the media type referenced by the Content-Type order to obtain data in the media type referenced by the Content-Type
header field. Content-Encoding is primarily used to allow a header field. Content-Encoding is primarily used to allow a
representation's data to be compressed without losing the identity of representation's data to be compressed without losing the identity of
its underlying media type. its underlying media type.
skipping to change at page 12, line 37 skipping to change at page 12, line 18
Content-Encoding: gzip Content-Encoding: gzip
If one or more encodings have been applied to a representation, the If one or more encodings have been applied to a representation, the
sender that applied the encodings MUST generate a Content-Encoding sender that applied the encodings MUST generate a Content-Encoding
header field that lists the content codings in the order in which header field that lists the content codings in the order in which
they were applied. Additional information about the encoding they were applied. Additional information about the encoding
parameters can be provided by other header fields not defined by this parameters can be provided by other header fields not defined by this
specification. specification.
Unlike Transfer-Encoding (Section 3.3.1 of [RFC7230]), the codings Unlike Transfer-Encoding (Section 3.3.1 of [MESSGNG]), the codings
listed in Content-Encoding are a characteristic of the listed in Content-Encoding are a characteristic of the
representation; the representation is defined in terms of the coded representation; the representation is defined in terms of the coded
form, and all other metadata about the representation is about the form, and all other metadata about the representation is about the
coded form unless otherwise noted in the metadata definition. coded form unless otherwise noted in the metadata definition.
Typically, the representation is only decoded just prior to rendering Typically, the representation is only decoded just prior to rendering
or analogous usage. or analogous usage.
If the media type includes an inherent encoding, such as a data If the media type includes an inherent encoding, such as a data
format that is always compressed, then that encoding would not be format that is always compressed, then that encoding would not be
restated in Content-Encoding even if it happens to be the same restated in Content-Encoding even if it happens to be the same
skipping to change at page 13, line 21 skipping to change at page 12, line 51
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. languages are explicitly excluded.
HTTP uses language tags within the Accept-Language and HTTP uses language tags within the Accept-Language and Content-
Content-Language header fields. Accept-Language uses the broader Language header fields. Accept-Language uses the broader language-
language-range production defined in Section 5.3.5, whereas range production defined in Section 5.3.5, whereas Content-Language
Content-Language uses the language-tag production defined below. uses the language-tag production defined below.
language-tag = <Language-Tag, see [RFC5646], Section 2.1> language-tag = <Language-Tag, see [RFC5646], Section 2.1>
A language tag is a sequence of one or more case-insensitive subtags, A language tag is a sequence of one or more case-insensitive subtags,
each separated by a hyphen character ("-", %x2D). In most cases, a each separated by a hyphen character ("-", %x2D). In most cases, a
language tag consists of a primary language subtag that identifies a language tag consists of a primary language subtag that identifies a
broad family of related languages (e.g., "en" = English), which is broad family of related languages (e.g., "en" = English), which is
optionally followed by a series of subtags that refine or narrow that optionally followed by a series of subtags that refine or narrow that
language's range (e.g., "en-CA" = the variety of English as language's range (e.g., "en-CA" = the variety of English as
communicated in Canada). Whitespace is not allowed within a language communicated in Canada). Whitespace is not allowed within a language
skipping to change at page 15, line 14 skipping to change at page 14, line 42
o Otherwise, the payload is unidentified. o Otherwise, the payload is unidentified.
For a response message, the following rules are applied in order For a response message, the following rules are applied in order
until a match is found: until a match is found:
1. If the request method is GET or HEAD and the response status code 1. If the request method is GET or HEAD and the response status code
is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not
Modified), the payload is a representation of the resource Modified), the payload is a representation of the resource
identified by the effective request URI (Section 5.5 of identified by the effective request URI (Section 5.5 of
[RFC7230]). [MESSGNG]).
2. If the request method is GET or HEAD and the response status code 2. If the request method is GET or HEAD and the response status code
is 203 (Non-Authoritative Information), the payload is a is 203 (Non-Authoritative Information), the payload is a
potentially modified or enhanced representation of the target potentially modified or enhanced representation of the target
resource as provided by an intermediary. resource as provided by an intermediary.
3. If the response has a Content-Location header field and its 3. If the response has a Content-Location header field and its
field-value is a reference to the same URI as the effective field-value is a reference to the same URI as the effective
request URI, the payload is a representation of the resource request URI, the payload is a representation of the resource
identified by the effective request URI. identified by the effective request URI.
skipping to change at page 15, line 48 skipping to change at page 15, line 27
The "Content-Location" header field references a URI that can be used The "Content-Location" header field references a URI that can be used
as an identifier for a specific resource corresponding to the as an identifier for a specific resource corresponding to the
representation in this message's payload. In other words, if one representation in this message's payload. In other words, if one
were to perform a GET request on this URI at the time of this were to perform a GET request on this URI at the time of this
message's generation, then a 200 (OK) response would contain the same message's generation, then a 200 (OK) response would contain the same
representation that is enclosed as payload in this message. representation that is enclosed as payload in this message.
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
The Content-Location value is not a replacement for the effective The Content-Location value is not a replacement for the effective
Request URI (Section 5.5 of [RFC7230]). It is representation Request URI (Section 5.5 of [MESSGNG]). It is representation
metadata. It has the same syntax and semantics as the header field metadata. It has the same syntax and semantics as the header field
of the same name defined for MIME body parts in Section 4 of of the same name defined for MIME body parts in Section 4 of
[RFC2557]. However, its appearance in an HTTP message has some [RFC2557]. However, its appearance in an HTTP message has some
special implications for HTTP recipients. special implications for HTTP recipients.
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its value refers (after conversion to absolute form) to a message and its value refers (after conversion to absolute form) to a
URI that is the same as the effective request URI, then the recipient URI that is the same as the effective request URI, then the recipient
MAY consider the payload to be a current representation of that MAY consider the payload to be a current representation of that
resource at the time indicated by the message origination date. For resource at the time indicated by the message origination date. For
skipping to change at page 16, line 29 skipping to change at page 16, line 9
If Content-Location is included in a 2xx (Successful) response If Content-Location is included in a 2xx (Successful) response
message and its field-value refers to a URI that differs from the message and its field-value refers to a URI that differs from the
effective request URI, then the origin server claims that the URI is effective request URI, then the origin server claims that the URI is
an identifier for a different resource corresponding to the enclosed an identifier for a different resource corresponding to the enclosed
representation. Such a claim can only be trusted if both identifiers representation. Such a claim can only be trusted if both identifiers
share the same resource owner, which cannot be programmatically share the same resource owner, which cannot be programmatically
determined via HTTP. determined via HTTP.
o For a response to a GET or HEAD request, this is an indication o For a response to a GET or HEAD request, this is an indication
that the effective request URI refers to a resource that is that the effective request URI refers to a resource that is
subject to content negotiation and the Content-Location subject to content negotiation and the Content-Location field-
field-value is a more specific identifier for the selected value is a more specific identifier for the selected
representation. representation.
o For a 201 (Created) response to a state-changing method, a o For a 201 (Created) response to a state-changing method, a
Content-Location field-value that is identical to the Location Content-Location field-value that is identical to the Location
field-value indicates that this payload is a current field-value indicates that this payload is a current
representation of the newly created resource. representation of the newly created resource.
o Otherwise, such a Content-Location indicates that this payload is o Otherwise, such a Content-Location indicates that this payload is
a representation reporting on the requested action's status and a representation reporting on the requested action's status and
that the same report is available (for future access with GET) at that the same report is available (for future access with GET) at
skipping to change at page 18, line 25 skipping to change at page 18, line 8
for resolving it. for resolving it.
Header fields that specifically describe the payload, rather than the Header fields that specifically describe the payload, rather than the
associated representation, are referred to as "payload header associated representation, are referred to as "payload header
fields". Payload header fields are defined in other parts of this fields". Payload header fields are defined in other parts of this
specification, due to their impact on message parsing. specification, due to their impact on message parsing.
+-------------------+----------------------------+ +-------------------+----------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+----------------------------+ +-------------------+----------------------------+
| Content-Length | Section 3.3.2 of [RFC7230] | | Content-Length | Section 3.3.2 of [MESSGNG] |
| Content-Range | Section 4.2 of [RFC7233] | | Content-Range | Section 4.2 of [RANGERQ] |
| Trailer | Section 4.4 of [RFC7230] | | Trailer | Section 4.4 of [MESSGNG] |
| Transfer-Encoding | Section 3.3.1 of [RFC7230] | | Transfer-Encoding | Section 3.3.1 of [MESSGNG] |
+-------------------+----------------------------+ +-------------------+----------------------------+
3.4. Content Negotiation 3.4. Content Negotiation
When responses convey payload information, whether indicating a When responses convey payload information, whether indicating a
success or an error, the origin server often has different ways of success or an error, the origin server often has different ways of
representing that information; for example, in different formats, representing that information; for example, in different formats,
languages, or encodings. Likewise, different users or user agents languages, or encodings. Likewise, different users or user agents
might have differing capabilities, characteristics, or preferences might have differing capabilities, characteristics, or preferences
that could influence which representation, among those available, that could influence which representation, among those available,
skipping to change at page 21, line 26 skipping to change at page 21, line 18
The request method token is the primary source of request semantics; The request method token is the primary source of request semantics;
it indicates the purpose for which the client has made this request it indicates the purpose for which the client has made this request
and what is expected by the client as a successful result. and what is expected by the client as a successful result.
The request method's semantics might be further specialized by the The request method's semantics might be further specialized by the
semantics of some header fields when present in a request (Section 5) semantics of some header fields when present in a request (Section 5)
if those additional semantics do not conflict with the method. For if those additional semantics do not conflict with the method. For
example, a client can send conditional request header fields example, a client can send conditional request header fields
(Section 5.2) to make the requested action conditional on the current (Section 5.2) to make the requested action conditional on the current
state of the target resource ([RFC7232]). state of the target resource ([CONDTNL]).
method = token method = token
HTTP was originally designed to be usable as an interface to HTTP was originally designed to be usable as an interface to
distributed object systems. The request method was envisioned as distributed object systems. The request method was envisioned as
applying semantics to a target resource in much the same way as applying semantics to a target resource in much the same way as
invoking a defined method on an identified object would apply invoking a defined method on an identified object would apply
semantics. The method token is case-sensitive because it might be semantics. The method token is case-sensitive because it might be
used as a gateway to object-based systems with case-sensitive method used as a gateway to object-based systems with case-sensitive method
names. names.
Unlike distributed objects, the standardized request methods in HTTP Unlike distributed objects, the standardized request methods in HTTP
are not resource-specific, since uniform interfaces provide for are not resource-specific, since uniform interfaces provide for
better visibility and reuse in network-based systems [REST]. Once better visibility and reuse in network-based systems [REST]. Once
defined, a standardized method ought to have the same semantics when defined, a standardized method ought to have the same semantics when
applied to any resource, though each resource determines for itself applied to any resource, though each resource determines for itself
whether those semantics are implemented or allowed. whether those semantics are implemented or allowed.
This specification defines a number of standardized methods that are This specification defines a number of standardized methods that are
commonly used in HTTP, as outlined by the following table. By commonly used in HTTP, as outlined by the following table. By
convention, standardized methods are defined in all-uppercase convention, standardized methods are defined in all-uppercase US-
US-ASCII letters. ASCII letters.
+---------+-------------------------------------------------+-------+ +---------+-------------------------------------------------+-------+
| Method | Description | Sec. | | Method | Description | Sec. |
+---------+-------------------------------------------------+-------+ +---------+-------------------------------------------------+-------+
| GET | Transfer a current representation of the target | 4.3.1 | | GET | Transfer a current representation of the target | 4.3.1 |
| | resource. | | | | resource. | |
| HEAD | Same as GET, but only transfer the status line | 4.3.2 | | HEAD | Same as GET, but only transfer the status line | 4.3.2 |
| | and header section. | | | | and header section. | |
| POST | Perform resource-specific processing on the | 4.3.3 | | POST | Perform resource-specific processing on the | 4.3.3 |
| | request payload. | | | | request payload. | |
skipping to change at page 24, line 23 skipping to change at page 24, line 23
client sends a PUT request and the underlying connection is closed client sends a PUT request and the underlying connection is closed
before any response is received, then the client can establish a new before any response is received, then the client can establish a new
connection and retry the idempotent request. It knows that repeating connection and retry the idempotent request. It knows that repeating
the request will have the same intended effect, even if the original the request will have the same intended effect, even if the original
request succeeded, though the response might differ. request succeeded, though the response might differ.
4.2.3. Cacheable Methods 4.2.3. Cacheable Methods
Request methods can be defined as "cacheable" to indicate that Request methods can be defined as "cacheable" to indicate that
responses to them are allowed to be stored for future reuse; for responses to them are allowed to be stored for future reuse; for
specific requirements see [RFC7234]. In general, safe methods that specific requirements see [CACHING]. In general, safe methods that
do not depend on a current or authoritative response are defined as do not depend on a current or authoritative response are defined as
cacheable; this specification defines GET, HEAD, and POST as cacheable; this specification defines GET, HEAD, and POST as
cacheable, although the overwhelming majority of cache cacheable, although the overwhelming majority of cache
implementations only support GET and HEAD. implementations only support GET and HEAD.
4.3. Method Definitions 4.3. Method Definitions
4.3.1. GET 4.3.1. GET
The GET method requests transfer of a current selected representation The GET method requests transfer of a current selected representation
skipping to change at page 25, line 11 skipping to change at page 25, line 10
files with the request as input and send the output as the files with the request as input and send the output as the
representation rather than transfer the files directly. Regardless, representation rather than transfer the files directly. Regardless,
only the origin server needs to know how each of its resource only the origin server needs to know how each of its resource
identifiers corresponds to an implementation and how each identifiers corresponds to an implementation and how each
implementation manages to select and send a current representation of implementation manages to select and send a current representation of
the target resource in a response to GET. the target resource in a response to GET.
A client can alter the semantics of GET to be a "range request", A client can alter the semantics of GET to be a "range request",
requesting transfer of only some part(s) of the selected requesting transfer of only some part(s) of the selected
representation, by sending a Range header field in the request representation, by sending a Range header field in the request
([RFC7233]). ([RANGERQ]).
A payload within a GET request message has no defined semantics; A payload within a GET request message has no defined semantics;
sending a payload body on a GET request might cause some existing sending a payload body on a GET request might cause some existing
implementations to reject the request. implementations to reject the request.
The response to a GET request is cacheable; a cache MAY use it to The response to a GET request is cacheable; a cache MAY use it to
satisfy subsequent GET and HEAD requests unless otherwise indicated satisfy subsequent GET and HEAD requests unless otherwise indicated
by the Cache-Control header field (Section 5.2 of [RFC7234]). by the Cache-Control header field (Section 5.2 of [CACHING]).
4.3.2. HEAD 4.3.2. HEAD
The HEAD method is identical to GET except that the server MUST NOT The HEAD method is identical to GET except that the server MUST NOT
send a message body in the response (i.e., the response terminates at send a message body in the response (i.e., the response terminates at
the end of the header section). The server SHOULD send the same the end of the header section). The server SHOULD send the same
header fields in response to a HEAD request as it would have sent if header fields in response to a HEAD request as it would have sent if
the request had been a GET, except that the payload header fields the request had been a GET, except that the payload header fields
(Section 3.3) MAY be omitted. This method can be used for obtaining (Section 3.3) MAY be omitted. This method can be used for obtaining
metadata about the selected representation without transferring the metadata about the selected representation without transferring the
representation data and is often used for testing hypertext links for representation data and is often used for testing hypertext links for
validity, accessibility, and recent modification. validity, accessibility, and recent modification.
A payload within a HEAD request message has no defined semantics; A payload within a HEAD request message has no defined semantics;
sending a payload body on a HEAD request might cause some existing sending a payload body on a HEAD request might cause some existing
implementations to reject the request. implementations to reject the request.
The response to a HEAD request is cacheable; a cache MAY use it to The response to a HEAD request is cacheable; a cache MAY use it to
satisfy subsequent HEAD requests unless otherwise indicated by the satisfy subsequent HEAD requests unless otherwise indicated by the
Cache-Control header field (Section 5.2 of [RFC7234]). A HEAD Cache-Control header field (Section 5.2 of [CACHING]). A HEAD
response might also have an effect on previously cached responses to response might also have an effect on previously cached responses to
GET; see Section 4.3.5 of [RFC7234]. GET; see Section 4.3.5 of [CACHING].
4.3.3. POST 4.3.3. POST
The POST method requests that the target resource process the The POST method requests that the target resource process the
representation enclosed in the request according to the resource's representation enclosed in the request according to the resource's
own specific semantics. For example, POST is used for the following own specific semantics. For example, POST is used for the following
functions (among others): functions (among others):
o Providing a block of data, such as the fields entered into an HTML o Providing a block of data, such as the fields entered into an HTML
form, to a data-handling process; form, to a data-handling process;
skipping to change at page 26, line 28 skipping to change at page 26, line 28
Satisfiable)). Satisfiable)).
If one or more resources has been created on the origin server as a If one or more resources has been created on the origin server as a
result of successfully processing a POST request, the origin server result of successfully processing a POST request, the origin server
SHOULD send a 201 (Created) response containing a Location header SHOULD send a 201 (Created) response containing a Location header
field that provides an identifier for the primary resource created field that provides an identifier for the primary resource created
(Section 7.1.2) and a representation that describes the status of the (Section 7.1.2) and a representation that describes the status of the
request while referring to the new resource(s). request while referring to the new resource(s).
Responses to POST requests are only cacheable when they include Responses to POST requests are only cacheable when they include
explicit freshness information (see Section 4.2.1 of [RFC7234]). explicit freshness information (see Section 4.2.1 of [CACHING]).
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 MAY send a 200 (OK) response containing the result and a Content-
Content-Location header field that has the same value as the POST's Location header field that has the same value as the POST's effective
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
with the existing resource's identifier in the Location field. This with the existing resource's identifier in the Location field. This
has the benefits of providing the user agent a resource identifier has the benefits of providing the user agent a resource identifier
and transferring the representation via a method more amenable to and transferring the representation via a method more amenable to
shared caching, though at the cost of an extra request if the user shared caching, though at the cost of an extra request if the user
agent does not already have the representation cached. agent does not already have the representation cached.
skipping to change at page 29, line 12 skipping to change at page 29, line 12
identifying "the current version" (a resource) that is separate from identifying "the current version" (a resource) that is separate from
the URIs identifying each particular version (different resources the URIs identifying each particular version (different resources
that at one point shared the same state as the current version that at one point shared the same state as the current version
resource). A successful PUT request on "the current version" URI resource). A successful PUT request on "the current version" URI
might therefore create a new version resource in addition to changing might therefore create a new version resource in addition to changing
the state of the target resource, and might also cause links to be the state of the target resource, and might also cause links to be
added between the related resources. added between the related resources.
An origin server that allows PUT on a given target resource MUST send An origin server that allows PUT on a given target resource MUST send
a 400 (Bad Request) response to a PUT request that contains a a 400 (Bad Request) response to a PUT request that contains a
Content-Range header field (Section 4.2 of [RFC7233]), since the Content-Range header field (Section 4.2 of [RANGERQ]), since the
payload is likely to be partial content that has been mistakenly PUT payload is likely to be partial content that has been mistakenly PUT
as a full representation. Partial content updates are possible by as a full representation. Partial content updates are possible by
targeting a separately identified resource with state that overlaps a targeting a separately identified resource with state that overlaps a
portion of the larger resource, or by using a different method that portion of the larger resource, or by using a different method that
has been specifically defined for partial updates (for example, the has been specifically defined for partial updates (for example, the
PATCH method defined in [RFC5789]). PATCH method defined in [RFC5789]).
Responses to the PUT method are not cacheable. If a successful PUT Responses to the PUT method are not cacheable. If a successful PUT
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the effective request URI, those stored responses will be for the effective request URI, those stored responses will be
invalidated (see Section 4.4 of [RFC7234]). invalidated (see Section 4.4 of [CACHING]).
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 30, line 23 skipping to change at page 30, line 23
or a 200 (OK) status code if the action has been enacted and the or a 200 (OK) status code if the action has been enacted and the
response message includes a representation describing the status. response message includes a representation describing the status.
A payload within a DELETE request message has no defined semantics; A payload within a DELETE request message has no defined semantics;
sending a payload body on a DELETE request might cause some existing sending a payload body on a DELETE request might cause some existing
implementations to reject the request. implementations to reject the request.
Responses to the DELETE method are not cacheable. If a DELETE Responses to the DELETE method are not cacheable. If a DELETE
request passes through a cache that has one or more stored responses request passes through a cache that has one or more stored responses
for the effective request URI, those stored responses will be for the effective request URI, those stored responses will be
invalidated (see Section 4.4 of [RFC7234]). invalidated (see Section 4.4 of [CACHING]).
4.3.6. CONNECT 4.3.6. CONNECT
The CONNECT method requests that the recipient establish a tunnel to The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target and, the destination origin server identified by the request-target and,
if successful, thereafter restrict its behavior to blind forwarding if successful, thereafter restrict its behavior to blind forwarding
of packets, in both directions, until the tunnel is closed. Tunnels of packets, in both directions, until the tunnel is closed. Tunnels
are commonly used to create an end-to-end virtual connection, through are commonly used to create an end-to-end virtual connection, through
one or more proxies, which can then be secured using TLS (Transport one or more proxies, which can then be secured using TLS (Transport
Layer Security, [RFC5246]). Layer Security, [RFC5246]).
CONNECT is intended only for use in requests to a proxy. An origin CONNECT is intended only for use in requests to a proxy. An origin
server that receives a CONNECT request for itself MAY respond with a server that receives a CONNECT request for itself MAY respond with a
2xx (Successful) status code to indicate that a connection is 2xx (Successful) status code to indicate that a connection is
established. However, most origin servers do not implement CONNECT. established. However, most origin servers do not implement CONNECT.
A client sending a CONNECT request MUST send the authority form of A client sending a CONNECT request MUST send the authority form of
request-target (Section 5.3 of [RFC7230]); i.e., the request-target request-target (Section 5.3 of [MESSGNG]); i.e., the request-target
consists of only the host name and port number of the tunnel consists of only the host name and port number of the tunnel
destination, separated by a colon. For example, destination, separated by a colon. For example,
CONNECT server.example.com:80 HTTP/1.1 CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80 Host: server.example.com:80
The recipient proxy can establish a tunnel either by directly The recipient proxy can establish a tunnel either by directly
connecting to the request-target or, if configured to use another connecting to the request-target or, if configured to use another
proxy, by forwarding the CONNECT request to the next inbound proxy. proxy, by forwarding the CONNECT request to the next inbound proxy.
Any 2xx (Successful) response indicates that the sender (and all Any 2xx (Successful) response indicates that the sender (and all
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 section; 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 tunnel is closed when a tunnel intermediary detects that either A tunnel is closed when a tunnel intermediary detects that either
side has closed its connection: the intermediary MUST attempt to send side has closed its connection: the intermediary MUST attempt to send
skipping to change at page 32, line 6 skipping to change at page 32, line 8
4.3.7. OPTIONS 4.3.7. OPTIONS
The OPTIONS method requests information about the communication The OPTIONS method requests information about the communication
options available for the target resource, at either the origin options available for the target resource, at either the origin
server or an intervening intermediary. This method allows a client server or an intervening intermediary. This method allows a client
to determine the options and/or requirements associated with a to determine the options and/or requirements associated with a
resource, or the capabilities of a server, without implying a resource, or the capabilities of a server, without implying a
resource action. resource action.
An OPTIONS request with an asterisk ("*") as the request-target An OPTIONS request with an asterisk ("*") as the request-target
(Section 5.3 of [RFC7230]) applies to the server in general rather (Section 5.3 of [MESSGNG]) applies to the server in general rather
than to a specific resource. Since a server's communication options than to a specific resource. Since a server's communication options
typically depend on the resource, the "*" request is only useful as a typically depend on the resource, the "*" request is only useful as a
"ping" or "no-op" type of method; it does nothing beyond allowing the "ping" or "no-op" type of method; it does nothing beyond allowing the
client to test the capabilities of the server. For example, this can client to test the capabilities of the server. For example, this can
be used to test a proxy for HTTP/1.1 conformance (or lack thereof). be used to test a proxy for HTTP/1.1 conformance (or lack thereof).
If the request-target is not an asterisk, the OPTIONS request applies If the request-target is not an asterisk, the OPTIONS request applies
to the options that are available when communicating with the target to the options that are available when communicating with the target
resource. resource.
skipping to change at page 32, line 49 skipping to change at page 32, line 51
resource. resource.
Responses to the OPTIONS method are not cacheable. Responses to the OPTIONS method are not cacheable.
4.3.8. TRACE 4.3.8. TRACE
The TRACE method requests a remote, application-level loop-back of The TRACE method requests a remote, application-level loop-back of
the request message. The final recipient of the request SHOULD the request message. The final recipient of the request SHOULD
reflect the message received, excluding some fields described below, reflect the message received, excluding some fields described below,
back to the client as the message body of a 200 (OK) response with a back to the client as the message body of a 200 (OK) response with a
Content-Type of "message/http" (Section 8.3.1 of [RFC7230]). The Content-Type of "message/http" (Section 8.3.1 of [MESSGNG]). The
final recipient is either the origin server or the first server to final recipient is either the origin server or the first server to
receive a Max-Forwards value of zero (0) in the request receive a Max-Forwards value of zero (0) in the request
(Section 5.1.2). (Section 5.1.2).
A client MUST NOT generate header fields in a TRACE request A client MUST NOT generate header fields in a TRACE request
containing sensitive data that might be disclosed by the response. containing sensitive data that might be disclosed by the response.
For example, it would be foolish for a user agent to send stored user For example, it would be foolish for a user agent to send stored user
credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The credentials [AUTHFRM] or cookies [RFC6265] in a TRACE request. The
final recipient of the request SHOULD exclude any request header final recipient of the request SHOULD exclude any request header
fields that are likely to contain sensitive data when that recipient fields that are likely to contain sensitive data when that recipient
generates the response body. generates the response body.
TRACE allows the client to see what is being received at the other TRACE allows the client to see what is being received at the other
end of the request chain and use that data for testing or diagnostic end of the request chain and use that data for testing or diagnostic
information. The value of the Via header field (Section 5.7.1 of information. The value of the Via header field (Section 5.7.1 of
[RFC7230]) is of particular interest, since it acts as a trace of the [MESSGNG]) is of particular interest, since it acts as a trace of the
request chain. Use of the Max-Forwards header field allows the request chain. Use of the Max-Forwards header field allows the
client to limit the length of the request chain, which is useful for client to limit the length of the request chain, which is useful for
testing a chain of proxies forwarding messages in an infinite loop. testing a chain of proxies forwarding messages in an infinite loop.
A client MUST NOT send a message body in a TRACE request. A client MUST NOT send a message body in a TRACE request.
Responses to the TRACE method are not cacheable. Responses to the TRACE method are not cacheable.
5. Request Header Fields 5. Request Header Fields
skipping to change at page 33, line 42 skipping to change at page 34, line 8
parameters on a programming language method invocation. parameters on a programming language method invocation.
5.1. Controls 5.1. Controls
Controls are request header fields that direct specific handling of Controls are request header fields that direct specific handling of
the request. the request.
+-------------------+--------------------------+ +-------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+--------------------------+ +-------------------+--------------------------+
| Cache-Control | Section 5.2 of [RFC7234] | | Cache-Control | Section 5.2 of [CACHING] |
| Expect | Section 5.1.1 | | Expect | Section 5.1.1 |
| Host | Section 5.4 of [RFC7230] | | Host | Section 5.4 of [MESSGNG] |
| Max-Forwards | Section 5.1.2 | | Max-Forwards | Section 5.1.2 |
| Pragma | Section 5.4 of [RFC7234] | | Pragma | Section 5.4 of [CACHING] |
| Range | Section 3.1 of [RFC7233] | | Range | Section 3.1 of [RANGERQ] |
| TE | Section 4.3 of [RFC7230] | | TE | Section 4.3 of [MESSGNG] |
+-------------------+--------------------------+ +-------------------+--------------------------+
5.1.1. Expect 5.1.1. Expect
The "Expect" header field in a request indicates a certain set of The "Expect" header field in a request indicates a certain set of
behaviors (expectations) that need to be supported by the server in behaviors (expectations) that need to be supported by the server in
order to properly handle this request. The only such expectation order to properly handle this request. The only such expectation
defined by this specification is 100-continue. defined by this specification is 100-continue.
Expect = "100-continue" Expect = "100-continue"
The Expect field-value is case-insensitive. The Expect field-value is case-insensitive.
A server that receives an Expect field-value other than 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 MAY respond with a 417 (Expectation Failed) status code to indicate
that the unexpected expectation cannot be met. that the unexpected expectation cannot be met.
A 100-continue expectation informs recipients that the client is A 100-continue expectation informs recipients that the client is
about to send a (presumably large) message body in this request and about to send a (presumably large) message body in this request and
wishes to receive a 100 (Continue) interim response if the wishes to receive a 100 (Continue) interim response if the request-
request-line and header fields are not sufficient to cause an line and header fields are not sufficient to cause an immediate
immediate success, redirect, or error response. This allows the success, redirect, or error response. This allows the client to wait
client to wait for an indication that it is worthwhile to send the for an indication that it is worthwhile to send the message body
message body before actually doing so, which can improve efficiency before actually doing so, which can improve efficiency when the
when the message body is huge or when the client anticipates that an message body is huge or when the client anticipates that an error is
error is likely (e.g., when sending a state-changing method, for the likely (e.g., when sending a state-changing method, for the first
first time, without previously verified authentication credentials). time, without previously verified authentication credentials).
For example, a request that begins with For example, a request that begins with
PUT /somewhere/fun HTTP/1.1 PUT /somewhere/fun HTTP/1.1
Host: origin.example.com Host: origin.example.com
Content-Type: video/h264 Content-Type: video/h264
Content-Length: 1234567890987 Content-Length: 1234567890987
Expect: 100-continue Expect: 100-continue
allows the origin server to immediately respond with an error allows the origin server to immediately respond with an error
skipping to change at page 35, line 35 skipping to change at page 35, line 49
corresponding request, or if the framing indicates that there is corresponding request, or if the framing indicates that there is
no message body. no message body.
o A server that sends a 100 (Continue) response MUST ultimately send o A server that sends a 100 (Continue) response MUST ultimately send
a final status code, once the message body is received and a final status code, once the message body is received and
processed, unless the connection is closed prematurely. processed, unless the connection is closed prematurely.
o A server that responds with a final status code before reading the o A server that responds with a final status code before reading the
entire message body SHOULD indicate in that response whether it entire message body SHOULD indicate in that response whether it
intends to close the connection or continue reading and discarding intends to close the connection or continue reading and discarding
the request message (see Section 6.6 of [RFC7230]). the request message (see Section 6.6 of [MESSGNG]).
An origin server MUST, upon receiving an HTTP/1.1 (or later) An origin server MUST, upon receiving an HTTP/1.1 (or later) request-
request-line and a complete header section that contains a line and a complete header section that contains a 100-continue
100-continue expectation and indicates a request message body will expectation and indicates a request message body will follow, either
follow, either send an immediate response with a final status code, send an immediate response with a final status code, if that status
if that status can be determined by examining just the request-line can be determined by examining just the request-line and header
and header fields, or send an immediate 100 (Continue) response to fields, or send an immediate 100 (Continue) response to encourage the
encourage the client to send the request's message body. The origin client to send the request's message body. The origin server MUST
server MUST NOT wait for the message body before sending the 100 NOT wait for the message body before sending the 100 (Continue)
(Continue) response. response.
A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and
a complete header section that contains a 100-continue expectation a complete header section that contains a 100-continue expectation
and indicates a request message body will follow, either send an and indicates a request message body will follow, either send an
immediate response with a final status code, if that status can be immediate response with a final status code, if that status can be
determined by examining just the request-line and header fields, or determined by examining just the request-line and header fields, or
begin forwarding the request toward the origin server by sending a begin forwarding the request toward the origin server by sending a
corresponding request-line and header section to the next inbound corresponding request-line and header section to the next inbound
server. If the proxy believes (from configuration or past server. If the proxy believes (from configuration or past
interaction) that the next inbound server only supports HTTP/1.0, the interaction) that the next inbound server only supports HTTP/1.0, the
skipping to change at page 36, line 48 skipping to change at page 37, line 14
value is greater than zero, the intermediary MUST generate an updated value is greater than zero, the intermediary MUST generate an updated
Max-Forwards field in the forwarded message with a field-value that Max-Forwards field in the forwarded message with a field-value that
is the lesser of a) the received value decremented by one (1) or b) is the lesser of a) the received value decremented by one (1) or b)
the recipient's maximum supported value for Max-Forwards. the recipient's maximum supported value for Max-Forwards.
A recipient MAY ignore a Max-Forwards header field received with any A recipient MAY ignore a Max-Forwards header field received with any
other request methods. other request methods.
5.2. Conditionals 5.2. Conditionals
The HTTP conditional request header fields [RFC7232] allow a client The HTTP conditional request header fields [CONDTNL] allow a client
to place a precondition on the state of the target resource, so that to place a precondition on the state of the target resource, so that
the action corresponding to the method semantics will not be applied the action corresponding to the method semantics will not be applied
if the precondition evaluates to false. Each precondition defined by if the precondition evaluates to false. Each precondition defined by
this specification consists of a comparison between a set of this specification consists of a comparison between a set of
validators obtained from prior representations of the target resource validators obtained from prior representations of the target resource
to the current state of validators for the selected representation to the current state of validators for the selected representation
(Section 7.2). Hence, these preconditions evaluate whether the state (Section 7.2). Hence, these preconditions evaluate whether the state
of the target resource has changed since a given state known by the of the target resource has changed since a given state known by the
client. The effect of such an evaluation depends on the method client. The effect of such an evaluation depends on the method
semantics and choice of conditional, as defined in Section 5 of semantics and choice of conditional, as defined in Section 5 of
[RFC7232]. [CONDTNL].
+---------------------+--------------------------+ +---------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+---------------------+--------------------------+ +---------------------+--------------------------+
| If-Match | Section 3.1 of [RFC7232] | | If-Match | Section 3.1 of [CONDTNL] |
| If-None-Match | Section 3.2 of [RFC7232] | | If-None-Match | Section 3.2 of [CONDTNL] |
| If-Modified-Since | Section 3.3 of [RFC7232] | | If-Modified-Since | Section 3.3 of [CONDTNL] |
| If-Unmodified-Since | Section 3.4 of [RFC7232] | | If-Unmodified-Since | Section 3.4 of [CONDTNL] |
| If-Range | Section 3.2 of [RFC7233] | | If-Range | Section 3.2 of [RANGERQ] |
+---------------------+--------------------------+ +---------------------+--------------------------+
5.3. Content Negotiation 5.3. Content Negotiation
The following request header fields are sent by a user agent to The following request header fields are sent by a user agent to
engage in proactive negotiation of the response content, as defined engage in proactive negotiation of the response content, as defined
in Section 3.4.1. The preferences sent in these fields apply to any in Section 3.4.1. The preferences sent in these fields apply to any
content in the response, including representations of the target content in the response, including representations of the target
resource, representations of error or processing status, and resource, representations of error or processing status, and
potentially even the miscellaneous text strings that might appear potentially even the miscellaneous text strings that might appear
skipping to change at page 38, line 23 skipping to change at page 38, line 42
A sender of qvalue MUST NOT generate more than three digits after the A sender of qvalue MUST NOT generate more than three digits after the
decimal point. User configuration of these values ought to be decimal point. User configuration of these values ought to be
limited in the same fashion. limited in the same fashion.
5.3.2. Accept 5.3.2. Accept
The "Accept" header field can be used by user agents to specify The "Accept" header field can be used by user agents to specify
response media types that are acceptable. Accept header fields can response media types that are acceptable. Accept header fields can
be used to indicate that the request is specifically limited to a be used to indicate that the request is specifically limited to a
small set of desired types, as in the case of a request for an small set of desired types, as in the case of a request for an in-
in-line image. line image.
Accept = #( media-range [ accept-params ] ) Accept = #( media-range [ accept-params ] )
media-range = ( "*/*" media-range = ( "*/*"
/ ( type "/" "*" ) / ( type "/" "*" )
/ ( type "/" subtype ) / ( type "/" subtype )
) *( OWS ";" OWS parameter ) ) *( OWS ";" OWS parameter )
accept-params = weight *( accept-ext ) accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
skipping to change at page 40, line 44 skipping to change at page 41, line 17
Accept-Charset = 1#( ( charset / "*" ) [ weight ] ) Accept-Charset = 1#( ( charset / "*" ) [ weight ] )
Charset names are defined in Section 3.1.1.2. A user agent MAY Charset names are defined in Section 3.1.1.2. A user agent MAY
associate a quality value with each charset to indicate the user's associate a quality value with each charset to indicate the user's
relative preference for that charset, as defined in Section 5.3.1. relative preference for that charset, as defined in Section 5.3.1.
An example is An example is
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8 Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
The special value "*", if present in the Accept-Charset field, The special value "*", if present in the Accept-Charset field,
matches every charset that is not mentioned elsewhere in the matches every charset that is not mentioned elsewhere in the Accept-
Accept-Charset field. If no "*" is present in an Accept-Charset Charset field. If no "*" is present in an Accept-Charset field, then
field, then any charsets not explicitly mentioned in the field are any charsets not explicitly mentioned in the field are considered
considered "not acceptable" to the client. "not acceptable" to the client.
A request without any Accept-Charset header field implies that the A request without any Accept-Charset header field implies that the
user agent will accept any charset in response. Most general-purpose user agent will accept any charset in response. Most general-purpose
user agents do not send Accept-Charset, unless specifically user agents do not send Accept-Charset, unless specifically
configured to do so, because a detailed list of supported charsets configured to do so, because a detailed list of supported charsets
makes it easier for a server to identify an individual by virtue of makes it easier for a server to identify an individual by virtue of
the user agent's request characteristics (Section 9.7). the user agent's request characteristics (Section 9.7).
If an Accept-Charset header field is present in a request and none of If an Accept-Charset header field is present in a request and none of
the available representations for the response has a charset that is the available representations for the response has a charset that is
skipping to change at page 42, line 6 skipping to change at page 42, line 26
does not imply that the user agent will be able to correctly process does not imply that the user agent will be able to correctly process
all encodings. all encodings.
A server tests whether a content-coding for a given representation is A server tests whether a content-coding for a given representation is
acceptable using these rules: acceptable using these rules:
1. If no Accept-Encoding field is in the request, any content-coding 1. If no Accept-Encoding field is in the request, any content-coding
is considered acceptable by the user agent. is considered acceptable by the user agent.
2. If the representation has no content-coding, then it is 2. If the representation has no content-coding, then it is
acceptable by default unless specifically excluded by the acceptable by default unless specifically excluded by the Accept-
Accept-Encoding field stating either "identity;q=0" or "*;q=0" Encoding field stating either "identity;q=0" or "*;q=0" without a
without a more specific entry for "identity". more specific entry for "identity".
3. If the representation's content-coding is one of the 3. If the representation's content-coding is one of the content-
content-codings listed in the Accept-Encoding field, then it is codings listed in the Accept-Encoding field, then it is
acceptable unless it is accompanied by a qvalue of 0. (As acceptable unless it is accompanied by a qvalue of 0. (As
defined in Section 5.3.1, a qvalue of 0 means "not acceptable".) defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)
4. If multiple content-codings are acceptable, then the acceptable 4. If multiple content-codings are acceptable, then the acceptable
content-coding with the highest non-zero qvalue is preferred. content-coding with the highest non-zero qvalue is preferred.
An Accept-Encoding header field with a combined field-value that is An Accept-Encoding header field with a combined field-value that is
empty implies that the user agent does not want any content-coding in empty implies that the user agent does not want any content-coding in
response. If an Accept-Encoding header field is present in a request response. If an Accept-Encoding header field is present in a request
and none of the available representations for the response have a and none of the available representations for the response have a
skipping to change at page 43, line 32 skipping to change at page 44, line 9
was previously defined for HTTP in Section 14.4 of [RFC2616]. was previously defined for HTTP in Section 14.4 of [RFC2616].
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header field with the complete linguistic an Accept-Language header field with the complete linguistic
preferences of the user in every request (Section 9.7). preferences of the user in every request (Section 9.7).
Since intelligibility is highly dependent on the individual user, Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic preference user agents need to allow user control over the linguistic preference
(either through configuration of the user agent itself or by (either through configuration of the user agent itself or by
defaulting to a user controllable system setting). A user agent that defaulting to a user controllable system setting). A user agent that
does not provide such control to the user MUST NOT send an does not provide such control to the user MUST NOT send an Accept-
Accept-Language header field. Language header field.
Note: User agents ought to provide guidance to users when setting Note: User agents ought to provide guidance to users when setting
a preference, since users are rarely familiar with the details of a preference, since users are rarely familiar with the details of
language matching as described above. For example, users might language matching as described above. For example, users might
assume that on selecting "en-gb", they will be served any kind of assume that on selecting "en-gb", they will be served any kind of
English document if British English is not available. A user English document if British English is not available. A user
agent might suggest, in such a case, to add "en" to the list for agent might suggest, in such a case, to add "en" to the list for
better matching behavior. better matching behavior.
5.4. Authentication Credentials 5.4. Authentication Credentials
Two header fields are used for carrying authentication credentials, Two header fields are used for carrying authentication credentials,
as defined in [RFC7235]. Note that various custom mechanisms for as defined in [AUTHFRM]. Note that various custom mechanisms for
user authentication use the Cookie header field for this purpose, as user authentication use the Cookie header field for this purpose, as
defined in [RFC6265]. defined in [RFC6265].
+---------------------+--------------------------+ +---------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+---------------------+--------------------------+ +---------------------+--------------------------+
| Authorization | Section 4.2 of [RFC7235] | | Authorization | Section 4.2 of [AUTHFRM] |
| Proxy-Authorization | Section 4.4 of [RFC7235] | | Proxy-Authorization | Section 4.4 of [AUTHFRM] |
+---------------------+--------------------------+ +---------------------+--------------------------+
5.5. Request Context 5.5. Request Context
The following request header fields provide additional information The following request header fields provide additional information
about the request context, including information about the user, user about the request context, including information about the user, user
agent, and resource behind the request. agent, and resource behind the request.
+-------------------+---------------+ +-------------------+---------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
skipping to change at page 46, line 31 skipping to change at page 46, line 48
identify the scope of reported interoperability problems, to work identify the scope of reported interoperability problems, to work
around or tailor responses to avoid particular user agent around or tailor responses to avoid particular user agent
limitations, and for analytics regarding browser or operating system limitations, and for analytics regarding browser or operating system
use. A user agent SHOULD send a User-Agent field in each request use. A user agent SHOULD send a User-Agent field in each request
unless specifically configured not to do so. unless specifically configured not to do so.
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
The User-Agent field-value consists of one or more product The User-Agent field-value consists of one or more product
identifiers, each followed by zero or more comments (Section 3.2 of identifiers, each followed by zero or more comments (Section 3.2 of
[RFC7230]), which together identify the user agent software and its [MESSGNG]), which together identify the user agent software and its
significant subproducts. By convention, the product identifiers are significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the listed in decreasing order of their significance for identifying the
user agent software. Each product identifier consists of a name and user agent software. Each product identifier consists of a name and
optional version. optional version.
product = token ["/" product-version] product = token ["/" product-version]
product-version = token product-version = token
A sender SHOULD limit generated product identifiers to what is A sender SHOULD limit generated product identifiers to what is
necessary to identify the product; a sender MUST NOT generate necessary to identify the product; a sender MUST NOT generate
advertising or other nonessential information within the product advertising or other nonessential information within the product
identifier. A sender SHOULD NOT generate information in identifier. A sender SHOULD NOT generate information in product-
product-version that is not a version identifier (i.e., successive version that is not a version identifier (i.e., successive versions
versions of the same product name ought to differ only in the of the same product name ought to differ only in the product-version
product-version portion of the product identifier). portion of the product identifier).
Example: Example:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3 User-Agent: CERN-LineMode/2.15 libwww/2.17b3
A user agent SHOULD NOT generate a User-Agent field containing A user agent SHOULD NOT generate a User-Agent field containing
needlessly fine-grained detail and SHOULD limit the addition of needlessly fine-grained detail and SHOULD limit the addition of
subproducts by third parties. Overly long and detailed User-Agent subproducts by third parties. Overly long and detailed User-Agent
field values increase request latency and the risk of a user being field values increase request latency and the risk of a user being
identified against their wishes ("fingerprinting"). identified against their wishes ("fingerprinting").
skipping to change at page 48, line 11 skipping to change at page 48, line 26
o 4xx (Client Error): The request contains bad syntax or cannot be o 4xx (Client Error): The request contains bad syntax or cannot be
fulfilled fulfilled
o 5xx (Server Error): The server failed to fulfill an apparently o 5xx (Server Error): The server failed to fulfill an apparently
valid request valid request
6.1. Overview of Status Codes 6.1. Overview of Status Codes
The status codes listed below are defined in this specification, The status codes listed below are defined in this specification,
Section 4 of [RFC7232], Section 4 of [RFC7233], and Section 3 of Section 4 of [CONDTNL], Section 4 of [RANGERQ], and Section 3 of
[RFC7235]. The reason phrases listed here are only recommendations [AUTHFRM]. The reason phrases listed here are only recommendations
-- they can be replaced by local equivalents without affecting the -- they can be replaced by local equivalents without affecting the
protocol. protocol.
Responses with status codes that are defined as cacheable by default Responses with status codes that are defined as cacheable by default
(e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
this specification) can be reused by a cache with heuristic this specification) can be reused by a cache with heuristic
expiration unless otherwise indicated by the method definition or expiration unless otherwise indicated by the method definition or
explicit cache controls [RFC7234]; all other status codes are not explicit cache controls [CACHING]; all other status codes are not
cacheable by default. 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 |
| 205 | Reset Content | Section 6.3.6 | | 205 | Reset Content | Section 6.3.6 |
| 206 | Partial Content | Section 4.1 of [RFC7233] | | 206 | Partial Content | Section 4.1 of [RANGERQ] |
| 300 | Multiple Choices | Section 6.4.1 | | 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 | | 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 | | 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 | | 303 | See Other | Section 6.4.4 |
| 304 | Not Modified | Section 4.1 of [RFC7232] | | 304 | Not Modified | Section 4.1 of [CONDTNL] |
| 305 | Use Proxy | Section 6.4.5 | | 305 | Use Proxy | Section 6.4.5 |
| 307 | Temporary Redirect | Section 6.4.7 | | 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 | | 400 | Bad Request | Section 6.5.1 |
| 401 | Unauthorized | Section 3.1 of [RFC7235] | | 401 | Unauthorized | Section 3.1 of [AUTHFRM] |
| 402 | Payment Required | Section 6.5.2 | | 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 | | 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 | | 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 | | 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 | | 406 | Not Acceptable | Section 6.5.6 |
| 407 | Proxy Authentication Required | Section 3.2 of [RFC7235] | | 407 | Proxy Authentication Required | Section 3.2 of [AUTHFRM] |
| 408 | Request Timeout | Section 6.5.7 | | 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 | | 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 | | 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 | | 411 | Length Required | Section 6.5.10 |
| 412 | Precondition Failed | Section 4.2 of [RFC7232] | | 412 | Precondition Failed | Section 4.2 of [CONDTNL] |
| 413 | Payload Too Large | Section 6.5.11 | | 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 | | 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 | | 415 | Unsupported Media Type | Section 6.5.13 |
| 416 | Range Not Satisfiable | Section 4.4 of [RFC7233] | | 416 | Range Not Satisfiable | Section 4.4 of [RANGERQ] |
| 417 | Expectation Failed | Section 6.5.14 | | 417 | Expectation Failed | Section 6.5.14 |
| 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 Timeout | Section 6.6.5 | | 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 | | 505 | HTTP Version Not Supported | Section 6.6.6 |
+------+-------------------------------+--------------------------+ +------+-------------------------------+--------------------------+
Note that this list is not exhaustive -- it does not include Note that this list is not exhaustive -- it does not include
extension status codes defined in other specifications. The complete extension status codes defined in other specifications. The complete
list of status codes is maintained by IANA. See Section 8.2 for list of status codes is maintained by IANA. See Section 8.2 for
details. details.
6.2. Informational 1xx 6.2. Informational 1xx
The 1xx (Informational) class of status code indicates an interim The 1xx (Informational) class of status code indicates an interim
response for communicating connection status or request progress response for communicating connection status or request progress
prior to completing the requested action and sending a final prior to completing the requested action and sending a final
response. 1xx responses are terminated by the first empty line after response. 1xx responses are terminated by the first empty line after
the status-line (the empty line signaling the end of the header the status-line (the empty line signaling the end of the header
section). Since HTTP/1.0 did not define any 1xx status codes, a section). Since HTTP/1.0 did not define any 1xx status codes, a
server MUST NOT send a 1xx response to an HTTP/1.0 client. server MUST NOT send a 1xx response to an HTTP/1.0 client.
A client MUST be able to parse one or more 1xx responses received A client MUST be able to parse one or more 1xx responses received
prior to a final response, even if the client does not expect one. A prior to a final response, even if the client does not expect one. A
user agent MAY ignore unexpected 1xx responses. user agent MAY ignore unexpected 1xx responses.
A proxy MUST forward 1xx responses unless the proxy itself requested A proxy MUST forward 1xx responses unless the proxy itself requested
the generation of the 1xx response. For example, if a proxy adds an the generation of the 1xx response. For example, if a proxy adds an
skipping to change at page 50, line 49 skipping to change at page 50, line 47
discard the 100 response. discard the 100 response.
If the request did not contain an Expect header field containing the If the request did not contain an Expect header field containing the
100-continue expectation, the client can simply discard this interim 100-continue expectation, the client can simply discard this interim
response. response.
6.2.2. 101 Switching Protocols 6.2.2. 101 Switching Protocols
The 101 (Switching Protocols) status code indicates that the server The 101 (Switching Protocols) status code indicates that the server
understands and is willing to comply with the client's request, via understands and is willing to comply with the client's request, via
the Upgrade header field (Section 6.7 of [RFC7230]), for a change in the Upgrade header field (Section 6.7 of [MESSGNG]), for a change in
the application protocol being used on this connection. The server the application protocol being used on this connection. The server
MUST generate an Upgrade header field in the response that indicates MUST generate an Upgrade header field in the response that indicates
which protocol(s) will be switched to immediately after the empty which protocol(s) will be switched to immediately after the empty
line that terminates the 101 response. line that terminates the 101 response.
It is assumed that the server will only agree to switch protocols It is assumed that the server will only agree to switch protocols
when it is advantageous to do so. For example, switching to a newer when it is advantageous to do so. For example, switching to a newer
version of HTTP might be advantageous over older versions, and version of HTTP might be advantageous over older versions, and
switching to a real-time, synchronous protocol might be advantageous switching to a real-time, synchronous protocol might be advantageous
when delivering resources that use such features. when delivering resources that use such features.
skipping to change at page 51, line 50 skipping to change at page 51, line 47
Aside from responses to CONNECT, a 200 response always has a payload, Aside from responses to CONNECT, a 200 response always has a payload,
though an origin server MAY generate a payload body of zero length. though an origin server MAY generate a payload body of zero length.
If no payload is desired, an origin server ought to send 204 (No If no payload is desired, an origin server ought to send 204 (No
Content) instead. For CONNECT, no payload is allowed because the Content) instead. For CONNECT, no payload is allowed because the
successful result is a tunnel, which begins immediately after the 200 successful result is a tunnel, which begins immediately after the 200
response header section. response header section.
A 200 response is cacheable by default; i.e., unless otherwise A 200 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [CACHING]).
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
resource(s) created. See Section 7.2 for a discussion of the meaning resource(s) created. See Section 7.2 for a discussion of the meaning
and purpose of validator header fields, such as ETag and and purpose of validator header fields, such as ETag and Last-
Last-Modified, in a 201 response. Modified, in a 201 response.
6.3.3. 202 Accepted 6.3.3. 202 Accepted
The 202 (Accepted) status code indicates that the request has been The 202 (Accepted) status code indicates that the request has been
accepted for processing, but the processing has not been completed. accepted for processing, but the processing has not been completed.
The request might or might not eventually be acted upon, as it might The request might or might not eventually be acted upon, as it might
be disallowed when processing actually takes place. There is no be disallowed when processing actually takes place. There is no
facility in HTTP for re-sending a status code from an asynchronous facility in HTTP for re-sending a status code from an asynchronous
operation. operation.
skipping to change at page 52, line 41 skipping to change at page 52, line 41
until the process is completed. The representation sent with this until the process is completed. The representation sent with this
response ought to describe the request's current status and point to response ought to describe the request's current status and point to
(or embed) a status monitor that can provide the user with an (or embed) a status monitor that can provide the user with an
estimate of when the request will be fulfilled. estimate of when the request will be fulfilled.
6.3.4. 203 Non-Authoritative Information 6.3.4. 203 Non-Authoritative Information
The 203 (Non-Authoritative Information) status code indicates that The 203 (Non-Authoritative Information) status code indicates that
the request was successful but the enclosed payload has been modified the request was successful but the enclosed payload has been modified
from that of the origin server's 200 (OK) response by a transforming from that of the origin server's 200 (OK) response by a transforming
proxy (Section 5.7.2 of [RFC7230]). This status code allows the proxy (Section 5.7.2 of [MESSGNG]). This status code allows the
proxy to notify recipients when a transformation has been applied, proxy to notify recipients when a transformation has been applied,
since that knowledge might impact later decisions regarding the since that knowledge might impact later decisions regarding the
content. For example, future cache validation requests for the content. For example, future cache validation requests for the
content might only be applicable along the same request path (through content might only be applicable along the same request path (through
the same proxies). the same proxies).
The 203 response is similar to the Warning code of 214 Transformation The 203 response is similar to the Warning code of 214 Transformation
Applied (Section 5.5 of [RFC7234]), which has the advantage of being Applied (Section 5.5 of [CACHING]), which has the advantage of being
applicable to responses with any status code. applicable to responses with any status code.
A 203 response is cacheable by default; i.e., unless otherwise A 203 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [CACHING]).
6.3.5. 204 No Content 6.3.5. 204 No Content
The 204 (No Content) status code indicates that the server has The 204 (No Content) status code indicates that the server has
successfully fulfilled the request and that there is no additional successfully fulfilled the request and that there is no additional
content to send in the response payload body. Metadata in the content to send in the response payload body. Metadata in the
response header fields refer to the target resource and its selected response header fields refer to the target resource and its selected
representation after the requested action was applied. representation after the requested action was applied.
For example, if a 204 status code is received in response to a PUT For example, if a 204 status code is received in response to a PUT
skipping to change at page 53, line 41 skipping to change at page 53, line 41
interfaces corresponding to a "save" action, such that the document interfaces corresponding to a "save" action, such that the document
being saved remains available to the user for editing. It is also being saved remains available to the user for editing. It is also
frequently used with interfaces that expect automated data transfers frequently used with interfaces that expect automated data transfers
to be prevalent, such as within distributed version control systems. to be prevalent, such as within distributed version control systems.
A 204 response is terminated by the first empty line after the header A 204 response is terminated by the first empty line after the header
fields because it cannot contain a message body. fields because it cannot contain a message body.
A 204 response is cacheable by default; i.e., unless otherwise A 204 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [CACHING]).
6.3.6. 205 Reset Content 6.3.6. 205 Reset Content
The 205 (Reset Content) status code indicates that the server has The 205 (Reset Content) status code indicates that the server has
fulfilled the request and desires that the user agent reset the fulfilled the request and desires that the user agent reset the
"document view", which caused the request to be sent, to its original "document view", which caused the request to be sent, to its original
state as received from the origin server. state as received from the origin server.
This response is intended to support a common data entry use case This response is intended to support a common data entry use case
where the user receives content that supports data entry (a form, where the user receives content that supports data entry (a form,
skipping to change at page 56, line 7 skipping to change at page 56, line 14
from that list automatically if it understands the provided media from that list automatically if it understands the provided media
type. A specific format for automatic selection is not defined by type. A specific format for automatic selection is not defined by
this specification because HTTP tries to remain orthogonal to the this specification because HTTP tries to remain orthogonal to the
definition of its payloads. In practice, the representation is definition of its payloads. In practice, the representation is
provided in some easily parsed format believed to be acceptable to provided in some easily parsed format believed to be acceptable to
the user agent, as determined by shared design or content the user agent, as determined by shared design or content
negotiation, or in some commonly accepted hypertext format. negotiation, or in some commonly accepted hypertext format.
A 300 response is cacheable by default; i.e., unless otherwise A 300 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [CACHING]).
Note: The original proposal for the 300 status code defined the Note: The original proposal for the 300 status code defined the
URI header field as providing a list of alternative URI header field as providing a list of alternative
representations, such that it would be usable for 200, 300, and representations, such that it would be usable for 200, 300, and
406 responses and be transferred in responses to the HEAD method. 406 responses and be transferred in responses to the HEAD method.
However, lack of deployment and disagreement over syntax led to However, lack of deployment and disagreement over syntax led to
both URI and Alternates (a subsequent proposal) being dropped from both URI and Alternates (a subsequent proposal) being dropped from
this specification. It is possible to communicate the list using this specification. It is possible to communicate the list using
a set of Link header fields [RFC5988], each with a relationship of a set of Link header fields [RFC5988], each with a relationship of
"alternate", though deployment is a chicken-and-egg problem. "alternate", though deployment is a chicken-and-egg problem.
skipping to change at page 56, line 41 skipping to change at page 56, line 48
redirection. The server's response payload usually contains a short redirection. The server's response payload usually contains a short
hypertext note with a hyperlink to the new URI(s). hypertext note with a hyperlink to the new URI(s).
Note: For historical reasons, a user agent MAY change the request Note: For historical reasons, a user agent MAY change the request
method from POST to GET for the subsequent request. If this method from POST to GET for the subsequent request. If this
behavior is undesired, the 307 (Temporary Redirect) status code behavior is undesired, the 307 (Temporary Redirect) status code
can be used instead. can be used instead.
A 301 response is cacheable by default; i.e., unless otherwise A 301 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [CACHING]).
6.4.3. 302 Found 6.4.3. 302 Found
The 302 (Found) status code indicates that the target resource The 302 (Found) status code indicates that the target resource
resides temporarily under a different URI. Since the redirection resides temporarily under a different URI. Since the redirection
might be altered on occasion, the client ought to continue to use the might be altered on occasion, the client ought to continue to use the
effective request URI for future requests. effective request URI for future requests.
The server SHOULD generate a Location header field in the response The server SHOULD generate a Location header field in the response
containing a URI reference for the different URI. The user agent MAY containing a URI reference for the different URI. The user agent MAY
skipping to change at page 58, line 8 skipping to change at page 58, line 12
representations are adequate, and what might be a useful description representations are adequate, and what might be a useful description
are outside the scope of HTTP. are outside the scope of HTTP.
Except for responses to a HEAD request, the representation of a 303 Except for responses to a HEAD request, the representation of a 303
response ought to contain a short hypertext note with a hyperlink to response ought to contain a short hypertext note with a hyperlink to
the same URI reference provided in the Location header field. the same URI reference provided in the Location header field.
6.4.5. 305 Use Proxy 6.4.5. 305 Use Proxy
The 305 (Use Proxy) status code was defined in a previous version of The 305 (Use Proxy) status code was defined in a previous version of
this specification and is now deprecated (Appendix B). this specification and is now deprecated (Appendix B of [RFC7231]).
6.4.6. 306 (Unused) 6.4.6. 306 (Unused)
The 306 status code was defined in a previous version of this The 306 status code was defined in a previous version of this
specification, is no longer used, and the code is reserved. specification, is no longer used, and the code is reserved.
6.4.7. 307 Temporary Redirect 6.4.7. 307 Temporary Redirect
The 307 (Temporary Redirect) status code indicates that the target The 307 (Temporary Redirect) status code indicates that the target
resource resides temporarily under a different URI and the user agent resource resides temporarily under a different URI and the user agent
skipping to change at page 59, line 39 skipping to change at page 59, line 46
The 404 (Not Found) status code indicates that the origin server did The 404 (Not Found) status code indicates that the origin server did
not find a current representation for the target resource or is not not find a current representation for the target resource or is not
willing to disclose that one exists. A 404 status code does not willing to disclose that one exists. A 404 status code does not
indicate whether this lack of representation is temporary or indicate whether this lack of representation is temporary or
permanent; the 410 (Gone) status code is preferred over 404 if the permanent; the 410 (Gone) status code is preferred over 404 if the
origin server knows, presumably through some configurable means, that origin server knows, presumably through some configurable means, that
the condition is likely to be permanent. the condition is likely to be permanent.
A 404 response is cacheable by default; i.e., unless otherwise A 404 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [CACHING]).
6.5.5. 405 Method Not Allowed 6.5.5. 405 Method Not Allowed
The 405 (Method Not Allowed) status code indicates that the method The 405 (Method Not Allowed) status code indicates that the method
received in the request-line is known by the origin server but not received in the request-line is known by the origin server but not
supported by the target resource. The origin server MUST generate an supported by the target resource. The origin server MUST generate an
Allow header field in a 405 response containing a list of the target Allow header field in a 405 response containing a list of the target
resource's currently supported methods. resource's currently supported methods.
A 405 response is cacheable by default; i.e., unless otherwise A 405 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [CACHING]).
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 60, line 26 skipping to change at page 60, line 32
appropriate. A user agent MAY automatically select the most appropriate. A user agent MAY automatically select the most
appropriate choice from that list. However, this specification does appropriate choice from that list. However, this specification does
not define any standard for such automatic selection, as described in not define any standard for such automatic selection, as described in
Section 6.4.1. Section 6.4.1.
6.5.7. 408 Request Timeout 6.5.7. 408 Request Timeout
The 408 (Request Timeout) status code indicates that the server did The 408 (Request Timeout) status code indicates that the server did
not receive a complete request message within the time that it was not receive a complete request message within the time that it was
prepared to wait. A server SHOULD send the "close" connection option prepared to wait. A server SHOULD send the "close" connection option
(Section 6.1 of [RFC7230]) in the response, since 408 implies that (Section 6.1 of [MESSGNG]) in the response, since 408 implies that
the server has decided to close the connection rather than continue the server has decided to close the connection rather than continue
waiting. If the client has an outstanding request in transit, the waiting. If the client has an outstanding request in transit, the
client MAY repeat that request on a new connection. client MAY repeat that request on a new connection.
6.5.8. 409 Conflict 6.5.8. 409 Conflict
The 409 (Conflict) status code indicates that the request could not The 409 (Conflict) status code indicates that the request could not
be completed due to a conflict with the current state of the target be completed due to a conflict with the current state of the target
resource. This code is used in situations where the user might be resource. This code is used in situations where the user might be
able to resolve the conflict and resubmit the request. The server able to resolve the conflict and resubmit the request. The server
skipping to change at page 61, line 20 skipping to change at page 61, line 28
intentionally unavailable and that the server owners desire that intentionally unavailable and that the server owners desire that
remote links to that resource be removed. Such an event is common remote links to that resource be removed. Such an event is common
for limited-time, promotional services and for resources belonging to for limited-time, promotional services and for resources belonging to
individuals no longer associated with the origin server's site. It individuals no longer associated with the origin server's site. It
is not necessary to mark all permanently unavailable resources as is not necessary to mark all permanently unavailable resources as
"gone" or to keep the mark for any length of time -- that is left to "gone" or to keep the mark for any length of time -- that is left to
the discretion of the server owner. the discretion of the server owner.
A 410 response is cacheable by default; i.e., unless otherwise A 410 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [CACHING]).
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 [RFC7230]). The client MAY repeat the request if (Section 3.3.2 of [MESSGNG]). The client MAY repeat the request if
it adds a valid Content-Length header field containing the length of it adds a valid Content-Length header field containing the length of
the message body in the request message. the message body in the request message.
6.5.11. 413 Payload Too Large 6.5.11. 413 Payload Too Large
The 413 (Payload Too Large) status code indicates that the server is The 413 (Payload Too Large) status code indicates that the server is
refusing to process a request because the request payload is larger refusing to process a request because the request payload is larger
than the server is willing or able to process. The server MAY close than the server is willing or able to process. The server MAY close
the connection to prevent the client from continuing the request. the connection to prevent the client from continuing the request.
If the condition is temporary, the server SHOULD generate a If the condition is temporary, the server SHOULD generate a Retry-
Retry-After header field to indicate that it is temporary and after After header field to indicate that it is temporary and after what
what time the client MAY try again. time the client MAY try again.
6.5.12. 414 URI Too Long 6.5.12. 414 URI Too Long
The 414 (URI Too Long) status code indicates that the server is The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the request-target (Section refusing to service the request because the request-target
5.3 of [RFC7230]) is longer than the server is willing to interpret. (Section 5.3 of [MESSGNG]) is longer than the server is willing to
This rare condition is only likely to occur when a client has interpret. This rare condition is only likely to occur when a client
improperly converted a POST request to a GET request with long query has improperly converted a POST request to a GET request with long
information, when the client has descended into a "black hole" of query information, when the client has descended into a "black hole"
redirection (e.g., a redirected URI prefix that points to a suffix of of redirection (e.g., a redirected URI prefix that points to a suffix
itself) or when the server is under attack by a client attempting to of itself) or when the server is under attack by a client attempting
exploit potential security holes. to exploit potential security holes.
A 414 response is cacheable by default; i.e., unless otherwise A 414 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [CACHING]).
6.5.13. 415 Unsupported Media Type 6.5.13. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource. is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated The format problem might be due to the request's indicated Content-
Content-Type or Content-Encoding, or as a result of inspecting the Type or Content-Encoding, or as a result of inspecting the data
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.
6.5.15. 426 Upgrade Required 6.5.15. 426 Upgrade Required
The 426 (Upgrade Required) status code indicates that the server The 426 (Upgrade Required) status code indicates that the server
refuses to perform the request using the current protocol but might refuses to perform the request using the current protocol but might
be willing to do so after the client upgrades to a different be willing to do so after the client upgrades to a different
protocol. The server MUST send an Upgrade header field in a 426 protocol. The server MUST send an Upgrade header field in a 426
response to indicate the required protocol(s) (Section 6.7 of response to indicate the required protocol(s) (Section 6.7 of
[RFC7230]). [MESSGNG]).
Example: Example:
HTTP/1.1 426 Upgrade Required HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0 Upgrade: HTTP/3.0
Connection: Upgrade Connection: Upgrade
Content-Length: 53 Content-Length: 53
Content-Type: text/plain Content-Type: text/plain
This service requires use of the HTTP/3.0 protocol. This service requires use of the HTTP/3.0 protocol.
skipping to change at page 63, line 23 skipping to change at page 63, line 41
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 by default; i.e., unless otherwise A 501 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [CACHING]).
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 64, line 12 skipping to change at page 64, line 32
from an upstream server it needed to access in order to complete the from an upstream server it needed to access in order to complete the
request. request.
6.6.6. 505 HTTP Version Not Supported 6.6.6. 505 HTTP Version Not Supported
The 505 (HTTP Version Not Supported) status code indicates that the The 505 (HTTP Version Not Supported) status code indicates that the
server does not support, or refuses to support, the major version of server does not support, or refuses to support, the major version of
HTTP that was used in the request message. The server is indicating HTTP that was used in the request message. The server is indicating
that it is unable or unwilling to complete the request using the same that it is unable or unwilling to complete the request using the same
major version as the client, as described in Section 2.6 of major version as the client, as described in Section 2.6 of
[RFC7230], other than with this error message. The server SHOULD [MESSGNG], other than with this error message. The server SHOULD
generate a representation for the 505 response that describes why generate a representation for the 505 response that describes why
that version is not supported and what other protocols are supported that version is not supported and what other protocols are supported
by that server. by that server.
7. Response Header Fields 7. Response Header Fields
The response header fields allow the server to pass additional The response header fields allow the server to pass additional
information about the response beyond what is placed in the information about the response beyond what is placed in the status-
status-line. These header fields give information about the server, line. These header fields give information about the server, about
about further access to the target resource, or about related further access to the target resource, or about related resources.
resources.
Although each response header field has a defined meaning, in Although each response header field has a defined meaning, in
general, the precise semantics might be further refined by the general, the precise semantics might be further refined by the
semantics of the request method and/or response status code. semantics of the request method and/or response status code.
7.1. Control Data 7.1. Control Data
Response header fields can supply control data that supplements the Response header fields can supply control data that supplements the
status code, directs caching, or instructs the client where to go status code, directs caching, or instructs the client where to go
next. next.
+-------------------+--------------------------+ +-------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+--------------------------+ +-------------------+--------------------------+
| Age | Section 5.1 of [RFC7234] | | Age | Section 5.1 of [CACHING] |
| Cache-Control | Section 5.2 of [RFC7234] | | Cache-Control | Section 5.2 of [CACHING] |
| Expires | Section 5.3 of [RFC7234] | | Expires | Section 5.3 of [CACHING] |
| Date | Section 7.1.1.2 | | Date | Section 7.1.1.2 |
| Location | Section 7.1.2 | | Location | Section 7.1.2 |
| Retry-After | Section 7.1.3 | | Retry-After | Section 7.1.3 |
| Vary | Section 7.1.4 | | Vary | Section 7.1.4 |
| Warning | Section 5.5 of [RFC7234] | | Warning | Section 5.5 of [CACHING] |
+-------------------+--------------------------+ +-------------------+--------------------------+
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 65, line 28 skipping to change at page 65, line 41
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 HTTP-date formats. When a sender generates a MUST accept all three HTTP-date formats. When a sender generates a
header field that contains one or more timestamps defined as header field that contains one or more timestamps defined as HTTP-
HTTP-date, the sender MUST generate those timestamps in the date, the sender MUST generate those timestamps in the IMF-fixdate
IMF-fixdate format. format.
An HTTP-date value represents time as an instance of Coordinated An HTTP-date value represents time as an instance of Coordinated
Universal Time (UTC). The first two formats indicate UTC by the Universal Time (UTC). The first two formats indicate UTC by the
three-letter abbreviation for Greenwich Mean Time, "GMT", a three-letter abbreviation for Greenwich Mean Time, "GMT", a
predecessor of the UTC name; values in the asctime format are assumed predecessor of the UTC name; values in the asctime format are assumed
to be in UTC. A sender that generates HTTP-date values from a local to be in UTC. A sender that generates HTTP-date values from a local
clock ought to use NTP ([RFC5905]) or some similar protocol to clock ought to use NTP ([RFC5905]) or some similar protocol to
synchronize its clock to UTC. synchronize its clock to UTC.
Preferred format: Preferred format:
skipping to change at page 66, line 35 skipping to change at page 67, line 4
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (leap second) ; 00:00:00 - 23:59:60 (leap second)
hour = 2DIGIT hour = 2DIGIT
minute = 2DIGIT minute = 2DIGIT
second = 2DIGIT second = 2DIGIT
Obsolete formats: Obsolete formats:
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
; e.g., 02-Jun-82 ; e.g., 02-Jun-82
day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive / %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive / %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive / %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive / %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive / %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive / %x53.75.6E.64.61.79 ; "Sunday", case-sensitive
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
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 the grammar. The semantics of day-name, day, month, year, and time-
time-of-day are the same as those defined for the Internet Message of-day are the same as those defined for the Internet Message Format
Format constructs with the corresponding name ([RFC5322], Section constructs with the corresponding name ([RFC5322], Section 3.3).
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, MUST 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 example, messages are occasionally forwarded over HTTP from a non-
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
to their usage within the protocol stream. Implementations are to their usage within the protocol stream. Implementations are
not required to use these formats for user presentation, request not required to use these formats for user presentation, request
logging, etc. logging, etc.
7.1.1.2. Date 7.1.1.2. Date
The "Date" header field represents the date and time at which the The "Date" header field represents the date and time at which the
skipping to change at page 70, line 18 skipping to change at page 70, line 28
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 in a response describes what parts of a The "Vary" header field in a response describes what parts of a
request message, aside from the method, Host header field, and request message, aside from the method, Host header field, and
request target, might influence the origin server's process for request target, might influence the origin server's process for
selecting and representing this response. The value consists of selecting and representing this response. The value consists of
either a single asterisk ("*") or a list of header field names either a single asterisk ("*") or a list of header field names (case-
(case-insensitive). 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). A recipient will not be able to determine whether network address). A recipient will not be able to determine whether
this response is appropriate for a later request without forwarding this response is appropriate for a later request without forwarding
the request to the origin server. A proxy MUST NOT generate a Vary the request to the origin server. A proxy MUST NOT generate a Vary
field with a "*" value. field with a "*" value.
skipping to change at page 70, line 51 skipping to change at page 71, line 19
indicates that the origin server might have used the request's indicates that the origin server might have used the request's
Accept-Encoding and Accept-Language fields (or lack thereof) as Accept-Encoding and Accept-Language fields (or lack thereof) as
determining factors while choosing the content for this response. determining factors while choosing the content for this response.
An origin server might send Vary with a list of fields for two An origin server might send Vary with a list of fields for two
purposes: purposes:
1. To inform cache recipients that they MUST NOT use this response 1. To inform cache recipients that they MUST NOT use this response
to satisfy a later request unless the later request has the same to satisfy a later request unless the later request has the same
values for the listed fields as the original request (Section 4.1 values for the listed fields as the original request (Section 4.1
of [RFC7234]). In other words, Vary expands the cache key of [CACHING]). In other words, Vary expands the cache key
required to match a new request to the stored cache entry. required to match a new request to the stored cache entry.
2. To inform user agent recipients that this response is subject to 2. To inform user agent recipients that this response is subject to
content negotiation (Section 5.3) and that a different content negotiation (Section 5.3) and that a different
representation might be sent in a subsequent request if representation might be sent in a subsequent request if
additional parameters are provided in the listed header fields additional parameters are provided in the listed header fields
(proactive negotiation). (proactive negotiation).
An origin server SHOULD send a Vary header field when its algorithm An origin server SHOULD send a Vary header field when its algorithm
for selecting a representation varies based on aspects of the request for selecting a representation varies based on aspects of the request
message other than the method and request target, unless the variance message other than the method and request target, unless the variance
cannot be crossed or the origin server has been deliberately cannot be crossed or the origin server has been deliberately
configured to prevent cache transparency. For example, there is no configured to prevent cache transparency. For example, there is no
need to send the Authorization field name in Vary because reuse need to send the Authorization field name in Vary because reuse
across users is constrained by the field definition (Section 4.2 of across users is constrained by the field definition (Section 4.2 of
[RFC7235]). Likewise, an origin server might use Cache-Control [AUTHFRM]). Likewise, an origin server might use Cache-Control
directives (Section 5.2 of [RFC7234]) to supplant Vary if it directives (Section 5.2 of [CACHING]) to supplant Vary if it
considers the variance less significant than the performance cost of considers the variance less significant than the performance cost of
Vary's impact on caching. Vary's impact on caching.
7.2. Validator Header Fields 7.2. Validator Header Fields
Validator header fields convey metadata about the selected Validator header fields convey metadata about the selected
representation (Section 3). In responses to safe requests, validator representation (Section 3). In responses to safe requests, validator
fields describe the selected representation chosen by the origin fields describe the selected representation chosen by the origin
server while handling the response. Note that, depending on the server while handling the response. Note that, depending on the
status code semantics, the selected representation for a given status code semantics, the selected representation for a given
response is not necessarily the same as the representation enclosed response is not necessarily the same as the representation enclosed
as response payload. as response payload.
In a successful response to a state-changing request, validator In a successful response to a state-changing request, validator
fields describe the new representation that has replaced the prior fields describe the new representation that has replaced the prior
selected representation as a result of processing the request. selected representation as a result of processing the request.
For example, an ETag header field in a 201 (Created) response For example, an ETag header field in a 201 (Created) response
communicates the entity-tag of the newly created resource's communicates the entity-tag of the newly created resource's
representation, so that it can be used in later conditional requests representation, so that it can be used in later conditional requests
to prevent the "lost update" problem [RFC7232]. to prevent the "lost update" problem [CONDTNL].
+-------------------+--------------------------+ +-------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+--------------------------+ +-------------------+--------------------------+
| ETag | Section 2.3 of [RFC7232] | | ETag | Section 2.3 of [CONDTNL] |
| Last-Modified | Section 2.2 of [RFC7232] | | Last-Modified | Section 2.2 of [CONDTNL] |
+-------------------+--------------------------+ +-------------------+--------------------------+
7.3. Authentication Challenges 7.3. Authentication Challenges
Authentication challenges indicate what mechanisms are available for Authentication challenges indicate what mechanisms are available for
the client to provide authentication credentials in future requests. the client to provide authentication credentials in future requests.
+--------------------+--------------------------+ +--------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+--------------------+--------------------------+ +--------------------+--------------------------+
| WWW-Authenticate | Section 4.1 of [RFC7235] | | WWW-Authenticate | Section 4.1 of [AUTHFRM] |
| Proxy-Authenticate | Section 4.3 of [RFC7235] | | Proxy-Authenticate | Section 4.3 of [AUTHFRM] |
+--------------------+--------------------------+ +--------------------+--------------------------+
7.4. Response Context 7.4. Response Context
The remaining response header fields provide more information about The remaining response header fields provide more information about
the target resource for potential use in later requests. the target resource for potential use in later requests.
+-------------------+--------------------------+ +-------------------+--------------------------+
| Header Field Name | Defined in... | | Header Field Name | Defined in... |
+-------------------+--------------------------+ +-------------------+--------------------------+
| Accept-Ranges | Section 2.3 of [RFC7233] | | Accept-Ranges | Section 2.3 of [RANGERQ] |
| Allow | Section 7.4.1 | | Allow | Section 7.4.1 |
| Server | Section 7.4.2 | | Server | Section 7.4.2 |
+-------------------+--------------------------+ +-------------------+--------------------------+
7.4.1. Allow 7.4.1. Allow
The "Allow" header field lists the set of methods advertised as The "Allow" header field lists the set of methods advertised as
supported by the target resource. The purpose of this field is supported by the target resource. The purpose of this field is
strictly to inform the recipient of valid request methods associated strictly to inform the recipient of valid request methods associated
with the resource. with the resource.
skipping to change at page 73, line 18 skipping to change at page 73, line 35
used by the origin server to handle the request, which is often used used by the origin server to handle the request, which is often used
by clients to help identify the scope of reported interoperability by clients to help identify the scope of reported interoperability
problems, to work around or tailor requests to avoid particular problems, to work around or tailor requests to avoid particular
server limitations, and for analytics regarding server or operating server limitations, and for analytics regarding server or operating
system use. An origin server MAY generate a Server field in its system use. An origin server MAY generate a Server field in its
responses. responses.
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
The Server field-value consists of one or more product identifiers, The Server field-value consists of one or more product identifiers,
each followed by zero or more comments (Section 3.2 of [RFC7230]), each followed by zero or more comments (Section 3.2 of [MESSGNG]),
which together identify the origin server software and its which together identify the origin server software and its
significant subproducts. By convention, the product identifiers are significant subproducts. By convention, the product identifiers are
listed in decreasing order of their significance for identifying the listed in decreasing order of their significance for identifying the
origin server software. Each product identifier consists of a name origin server software. Each product identifier consists of a name
and optional version, as defined in Section 5.5.3. and optional version, as defined in Section 5.5.3.
Example: Example:
Server: CERN/3.0 libwww/2.17 Server: CERN/3.0 libwww/2.17
skipping to change at page 74, line 29 skipping to change at page 74, line 38
8.1.2. Considerations for New Methods 8.1.2. Considerations for New Methods
Standardized methods are generic; that is, they are potentially Standardized methods are generic; that is, they are potentially
applicable to any resource, not just one particular media type, kind applicable to any resource, not just one particular media type, kind
of resource, or application. As such, it is preferred that new of resource, or application. As such, it is preferred that new
methods be registered in a document that isn't specific to a single methods be registered in a document that isn't specific to a single
application or data format, since orthogonal technologies deserve application or data format, since orthogonal technologies deserve
orthogonal specification. orthogonal specification.
Since message parsing (Section 3.3 of [RFC7230]) needs to be Since message parsing (Section 3.3 of [MESSGNG]) needs to be
independent of method semantics (aside from responses to HEAD), independent of method semantics (aside from responses to HEAD),
definitions of new methods cannot change the parsing algorithm or definitions of new methods cannot change the parsing algorithm or
prohibit the presence of a message body on either the request or the prohibit the presence of a message body on either the request or the
response message. Definitions of new methods can specify that only a response message. Definitions of new methods can specify that only a
zero-length message body is allowed by requiring a Content-Length zero-length message body is allowed by requiring a Content-Length
header field with a value of "0". header field with a value of "0".
A new method definition needs to indicate whether it is safe A new method definition needs to indicate whether it is safe
(Section 4.2.1), idempotent (Section 4.2.2), cacheable (Section 4.2.1), idempotent (Section 4.2.2), cacheable
(Section 4.2.3), what semantics are to be associated with the payload (Section 4.2.3), what semantics are to be associated with the payload
body if any is present in the request and what refinements the method body if any is present in the request and what refinements the method
makes to header field or status code semantics. If the new method is makes to header field or status code semantics. If the new method is
cacheable, its definition ought to describe how, and under what cacheable, its definition ought to describe how, and under what
conditions, a cache can store a response and use it to satisfy a conditions, a cache can store a response and use it to satisfy a
subsequent request. The new method ought to describe whether it can subsequent request. The new method ought to describe whether it can
be made conditional (Section 5.2) and, if so, how a server responds be made conditional (Section 5.2) and, if so, how a server responds
when the condition is false. Likewise, if the new method might have when the condition is false. Likewise, if the new method might have
some use for partial response semantics ([RFC7233]), it ought to some use for partial response semantics ([RANGERQ]), it ought to
document this, too. document this, too.
Note: Avoid defining a method name that starts with "M-", since Note: Avoid defining a method name that starts with "M-", since
that prefix might be misinterpreted as having the semantics that prefix might be misinterpreted as having the semantics
assigned to it by [RFC2774]. assigned to it by [RFC2774].
8.1.3. Registrations 8.1.3. Registrations
The "Hypertext Transfer Protocol (HTTP) Method Registry" has been The "Hypertext Transfer Protocol (HTTP) Method Registry" has been
populated with the registrations below: populated with the registrations below:
+---------+------+------------+---------------+ +---------+------+------------+----------------+
| Method | Safe | Idempotent | Reference | | Method | Safe | Idempotent | Reference |
+---------+------+------------+---------------+ +---------+------+------------+----------------+
| CONNECT | no | no | Section 4.3.6 | | CONNECT | no | no | Section 4.3.6 |
| DELETE | no | yes | Section 4.3.5 | | DELETE | no | yes | Section 4.3.5 |
| GET | yes | yes | Section 4.3.1 | | GET | yes | yes | Section 4.3.1 |
| HEAD | yes | yes | Section 4.3.2 | | HEAD | yes | yes | Section 4.3.2 |
| OPTIONS | yes | yes | Section 4.3.7 | | OPTIONS | yes | yes | Section 4.3.7 |
| POST | no | no | Section 4.3.3 | | POST | no | no | Section 4.3.3 |
| PUT | no | yes | Section 4.3.4 | | PUT | no | yes | Section 4.3.4 |
| TRACE | yes | yes | Section 4.3.8 | | TRACE | yes | yes | Section 4.3.8 |
+---------+------+------------+---------------+ +---------+------+------------+----------------+
8.2. Status Code Registry 8.2. Status Code Registry
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines
the namespace for the response status-code token (Section 6). The the namespace for the response status-code token (Section 6). The
status code registry is maintained at status code registry is maintained at
<http://www.iana.org/assignments/http-status-codes>. <http://www.iana.org/assignments/http-status-codes>.
This section replaces the registration procedure for HTTP Status This section replaces the registration procedure for HTTP Status
Codes previously defined in Section 7.1 of [RFC2817]. Codes previously defined in Section 7.1 of [RFC2817].
skipping to change at page 76, line 41 skipping to change at page 76, line 43
are required, what fields can modify the semantics, and what header are required, what fields can modify the semantics, and what header
field semantics are further refined when used with the new status field semantics are further refined when used with the new status
code). code).
The definition of a new status code ought to specify whether or not The definition of a new status code ought to specify whether or not
it is cacheable. Note that all status codes can be cached if the it is cacheable. Note that all status codes can be cached if the
response they occur in has explicit freshness information; however, response they occur in has explicit freshness information; however,
status codes that are defined as being cacheable are allowed to be status codes that are defined as being cacheable are allowed to be
cached without explicit freshness information. Likewise, the cached without explicit freshness information. Likewise, the
definition of a status code can place constraints upon cache definition of a status code can place constraints upon cache
behavior. See [RFC7234] for more information. behavior. See [CACHING] for more information.
Finally, the definition of a new status code ought to indicate Finally, the definition of a new status code ought to indicate
whether the payload has any implied association with an identified whether the payload has any implied association with an identified
resource (Section 3.1.4.1). resource (Section 3.1.4.1).
8.2.3. Registrations 8.2.3. Registrations
The status code registry has been updated with the registrations The status code registry has been updated with the registrations
below: below:
+-------+-------------------------------+----------------+ +-------+-------------------------------+-----------------+
| Value | Description | Reference | | Value | Description | Reference |
+-------+-------------------------------+----------------+ +-------+-------------------------------+-----------------+
| 100 | Continue | Section 6.2.1 | | 100 | Continue | Section 6.2.1 |
| 101 | Switching Protocols | Section 6.2.2 | | 101 | Switching Protocols | Section 6.2.2 |
| 200 | OK | Section 6.3.1 | | 200 | OK | Section 6.3.1 |
| 201 | Created | Section 6.3.2 | | 201 | Created | Section 6.3.2 |
| 202 | Accepted | Section 6.3.3 | | 202 | Accepted | Section 6.3.3 |
| 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 |
| 205 | Reset Content | Section 6.3.6 | | 205 | Reset Content | Section 6.3.6 |
| 300 | Multiple Choices | Section 6.4.1 | | 300 | Multiple Choices | Section 6.4.1 |
| 301 | Moved Permanently | Section 6.4.2 | | 301 | Moved Permanently | Section 6.4.2 |
| 302 | Found | Section 6.4.3 | | 302 | Found | Section 6.4.3 |
| 303 | See Other | Section 6.4.4 | | 303 | See Other | Section 6.4.4 |
| 305 | Use Proxy | Section 6.4.5 | | 305 | Use Proxy | Section 6.4.5 |
| 306 | (Unused) | Section 6.4.6 | | 306 | (Unused) | Section 6.4.6 |
| 307 | Temporary Redirect | Section 6.4.7 | | 307 | Temporary Redirect | Section 6.4.7 |
| 400 | Bad Request | Section 6.5.1 | | 400 | Bad Request | Section 6.5.1 |
| 402 | Payment Required | Section 6.5.2 | | 402 | Payment Required | Section 6.5.2 |
| 403 | Forbidden | Section 6.5.3 | | 403 | Forbidden | Section 6.5.3 |
| 404 | Not Found | Section 6.5.4 | | 404 | Not Found | Section 6.5.4 |
| 405 | Method Not Allowed | Section 6.5.5 | | 405 | Method Not Allowed | Section 6.5.5 |
| 406 | Not Acceptable | Section 6.5.6 | | 406 | Not Acceptable | Section 6.5.6 |
| 408 | Request Timeout | Section 6.5.7 | | 408 | Request Timeout | Section 6.5.7 |
| 409 | Conflict | Section 6.5.8 | | 409 | Conflict | Section 6.5.8 |
| 410 | Gone | Section 6.5.9 | | 410 | Gone | Section 6.5.9 |
| 411 | Length Required | Section 6.5.10 | | 411 | Length Required | Section 6.5.10 |
| 413 | Payload Too Large | Section 6.5.11 | | 413 | Payload Too Large | Section 6.5.11 |
| 414 | URI Too Long | Section 6.5.12 | | 414 | URI Too Long | Section 6.5.12 |
| 415 | Unsupported Media Type | Section 6.5.13 | | 415 | Unsupported Media Type | Section 6.5.13 |
| 417 | Expectation Failed | Section 6.5.14 | | 417 | Expectation Failed | Section 6.5.14 |
| 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 Timeout | Section 6.6.5 | | 504 | Gateway Timeout | Section 6.6.5 |
| 505 | HTTP Version Not Supported | Section 6.6.6 | | 505 | HTTP Version Not Supported | Section 6.6.6 |
+-------+-------------------------------+----------------+ +-------+-------------------------------+-----------------+
8.3. Header Field Registry 8.3. Header Field Registry
HTTP header fields are registered within the "Message Headers" HTTP header fields are registered within the "Message Headers"
registry located at registry located at <http://www.iana.org/assignments/message-
<http://www.iana.org/assignments/message-headers>, as defined by headers>, as defined by [BCP90].
[BCP90].
8.3.1. Considerations for New Header Fields 8.3.1. Considerations for New Header Fields
Header fields are key:value pairs that can be used to communicate Header fields are key:value pairs that can be used to communicate
data about the message, its payload, the target resource, or the data about the message, its payload, the target resource, or the
connection (i.e., control data). See Section 3.2 of [RFC7230] for a connection (i.e., control data). See Section 3.2 of [MESSGNG] for a
general definition of header field syntax in HTTP messages. general definition of header field syntax in HTTP messages.
The requirements for header field names are defined in [BCP90]. The requirements for header field names are defined in [BCP90].
Authors of specifications defining new fields are advised to keep the Authors of specifications defining new fields are advised to keep the
name as short as practical and not to prefix the name with "X-" name as short as practical and not to prefix the name with "X-"
unless the header field will never be used on the Internet. (The unless the header field will never be used on the Internet. (The
"X-" prefix idiom has been extensively misused in practice; it was "X-" prefix idiom has been extensively misused in practice; it was
intended to only be used as a mechanism for avoiding name collisions intended to only be used as a mechanism for avoiding name collisions
inside proprietary software or intranet processing, since the prefix inside proprietary software or intranet processing, since the prefix
would ensure that private names never collide with a newly registered would ensure that private names never collide with a newly registered
Internet name; see [BCP178] for further information). Internet name; see [BCP178] for further information).
New header field values typically have their syntax defined using New header field values typically have their syntax defined using
ABNF ([RFC5234]), using the extension defined in Section 7 of ABNF ([RFC5234]), using the extension defined in Section 7 of
[RFC7230] as necessary, and are usually constrained to the range of [MESSGNG] as necessary, and are usually constrained to the range of
US-ASCII characters. Header fields needing a greater range of US-ASCII characters. Header fields needing a greater range of
characters can use an encoding such as the one defined in [RFC5987]. characters can use an encoding such as the one defined in [RFC5987].
Leading and trailing whitespace in raw field values is removed upon Leading and trailing whitespace in raw field values is removed upon
field parsing (Section 3.2.4 of [RFC7230]). Field definitions where field parsing (Section 3.2.4 of [MESSGNG]). Field definitions where
leading or trailing whitespace in values is significant will have to leading or trailing whitespace in values is significant will have to
use a container syntax such as quoted-string (Section 3.2.6 of use a container syntax such as quoted-string (Section 3.2.6 of
[RFC7230]). [MESSGNG]).
Because commas (",") are used as a generic delimiter between Because commas (",") are used as a generic delimiter between field-
field-values, they need to be treated with care if they are allowed values, they need to be treated with care if they are allowed in the
in the field-value. Typically, components that might contain a comma field-value. Typically, components that might contain a comma are
are protected with double-quotes using the quoted-string ABNF protected with double-quotes using the quoted-string ABNF production.
production.
For example, a textual date and a URI (either of which might contain For example, a textual date and a URI (either of which might contain
a comma) could be safely carried in field-values like these: a comma) could be safely carried in field-values like these:
Example-URI-Field: "http://example.com/a.html,foo", Example-URI-Field: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/" "http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
Note that double-quote delimiters almost always are used with the Note that double-quote delimiters almost always are used with the
quoted-string production; using a different syntax inside quoted-string production; using a different syntax inside double-
double-quotes will likely cause unnecessary confusion. quotes will likely cause unnecessary confusion.
Many header fields use a format including (case-insensitively) named Many header fields use a format including (case-insensitively) named
parameters (for instance, Content-Type, defined in Section 3.1.1.5). parameters (for instance, Content-Type, defined in Section 3.1.1.5).
Allowing both unquoted (token) and quoted (quoted-string) syntax for Allowing both unquoted (token) and quoted (quoted-string) syntax for
the parameter value enables recipients to use existing parser the parameter value enables recipients to use existing parser
components. When allowing both forms, the meaning of a parameter components. When allowing both forms, the meaning of a parameter
value ought to be independent of the syntax used for it (for an value ought to be independent of the syntax used for it (for an
example, see the notes on parameter handling for media types in example, see the notes on parameter handling for media types in
Section 3.1.1.1). Section 3.1.1.1).
Authors of specifications defining new header fields are advised to Authors of specifications defining new header fields are advised to
consider documenting: consider documenting:
o Whether the field is a single value or whether it can be a list o Whether the field is a single value or whether it can be a list
(delimited by commas; see Section 3.2 of [RFC7230]). (delimited by commas; see Section 3.2 of [MESSGNG]).
If it does not use the list syntax, document how to treat messages If it does not use the list syntax, document how to treat messages
where the field occurs multiple times (a sensible default would be where the field occurs multiple times (a sensible default would be
to ignore the field, but this might not always be the right to ignore the field, but this might not always be the right
choice). choice).
Note that intermediaries and software libraries might combine Note that intermediaries and software libraries might combine
multiple header field instances into a single one, despite the multiple header field instances into a single one, despite the
field's definition not allowing the list syntax. A robust format field's definition not allowing the list syntax. A robust format
enables recipients to discover these situations (good example: enables recipients to discover these situations (good example:
skipping to change at page 79, line 45 skipping to change at page 79, line 49
particular request method, etc. particular request method, etc.
o Whether the field should be stored by origin servers that o Whether the field should be stored by origin servers that
understand it upon a PUT request. understand it upon a PUT request.
o Whether the field semantics are further refined by the context, o Whether the field semantics are further refined by the context,
such as by existing request methods or status codes. such as by existing request methods or status codes.
o Whether it is appropriate to list the field-name in the Connection o Whether it is appropriate to list the field-name in the Connection
header field (i.e., if the header field is to be hop-by-hop; see header field (i.e., if the header field is to be hop-by-hop; see
Section 6.1 of [RFC7230]). Section 6.1 of [MESSGNG]).
o Under what conditions intermediaries are allowed to insert, o Under what conditions intermediaries are allowed to insert,
delete, or modify the field's value. delete, or modify the field's value.
o Whether it is appropriate to list the field-name in a Vary o Whether it is appropriate to list the field-name in a Vary
response header field (e.g., when the request header field is used response header field (e.g., when the request header field is used
by an origin server's content selection algorithm; see by an origin server's content selection algorithm; see
Section 7.1.4). Section 7.1.4).
o Whether the header field is useful or allowable in trailers (see o Whether the header field is useful or allowable in trailers (see
Section 4.1 of [RFC7230]). Section 4.1 of [MESSGNG]).
o Whether the header field ought to be preserved across redirects. o Whether the header field ought to be preserved across redirects.
o Whether it introduces any additional security considerations, such o Whether it introduces any additional security considerations, such
as disclosure of privacy-related data. as disclosure of privacy-related data.
8.3.2. Registrations 8.3.2. Registrations
The "Message Headers" registry has been updated with the following The "Message Headers" registry has been updated with the following
permanent registrations: permanent registrations:
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+------------------+
| Header Field Name | Protocol | Status | Reference | | Header Field Name | Protocol | Status | Reference |
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+------------------+
| Accept | http | standard | Section 5.3.2 | | Accept | http | standard | Section 5.3.2 |
| Accept-Charset | http | standard | Section 5.3.3 | | Accept-Charset | http | standard | Section 5.3.3 |
| Accept-Encoding | http | standard | Section 5.3.4 | | Accept-Encoding | http | standard | Section 5.3.4 |
| Accept-Language | http | standard | Section 5.3.5 | | Accept-Language | http | standard | Section 5.3.5 |
| Allow | http | standard | Section 7.4.1 | | Allow | http | standard | Section 7.4.1 |
| Content-Encoding | http | standard | Section 3.1.2.2 | | Content-Encoding | http | standard | Section 3.1.2.2 |
| Content-Language | http | standard | Section 3.1.3.2 | | Content-Language | http | standard | Section 3.1.3.2 |
| Content-Location | http | standard | Section 3.1.4.2 | | Content-Location | http | standard | Section 3.1.4.2 |
| Content-Type | http | standard | Section 3.1.1.5 | | Content-Type | http | standard | Section 3.1.1.5 |
| Date | http | standard | Section 7.1.1.2 | | Date | http | standard | Section 7.1.1.2 |
| Expect | http | standard | Section 5.1.1 | | Expect | http | standard | Section 5.1.1 |
| From | http | standard | Section 5.5.1 | | From | http | standard | Section 5.5.1 |
| Location | http | standard | Section 7.1.2 | | Location | http | standard | Section 7.1.2 |
| Max-Forwards | http | standard | Section 5.1.2 | | Max-Forwards | http | standard | Section 5.1.2 |
| MIME-Version | http | standard | Appendix A.1 | | MIME-Version | http | standard | Appendix A.1 |
| Referer | http | standard | Section 5.5.2 | | Referer | http | standard | Section 5.5.2 |
| Retry-After | http | standard | Section 7.1.3 | | Retry-After | http | standard | Section 7.1.3 |
| Server | http | standard | Section 7.4.2 | | Server | http | standard | Section 7.4.2 |
| User-Agent | http | standard | Section 5.5.3 | | User-Agent | http | standard | Section 5.5.3 |
| Vary | http | standard | Section 7.1.4 | | Vary | http | standard | Section 7.1.4 |
+-------------------+----------+----------+-----------------+ +-------------------+----------+----------+------------------+
The change controller for the above registrations is: "IETF The change controller for the above registrations is: "IETF
(iesg@ietf.org) - Internet Engineering Task Force". (iesg@ietf.org) - Internet Engineering Task Force".
8.4. Content Coding Registry 8.4. Content Coding Registry
The "HTTP Content Coding Registry" defines the namespace for content The "HTTP Content Coding Registry" defines the namespace for content
coding names (Section 4.2 of [RFC7230]). The content coding registry coding names (Section 4.2 of [MESSGNG]). The content coding registry
is maintained at <http://www.iana.org/assignments/http-parameters>. is maintained at <http://www.iana.org/assignments/http-parameters>.
8.4.1. Procedure 8.4.1. Procedure
Content coding registrations MUST include the following fields: Content coding registrations MUST include the following fields:
o Name o Name
o Description o Description
o Pointer to specification text o Pointer to specification text
Names of content codings MUST NOT overlap with names of transfer Names of content codings MUST NOT overlap with names of transfer
codings (Section 4 of [RFC7230]), unless the encoding transformation codings (Section 4 of [MESSGNG]), unless the encoding transformation
is identical (as is the case for the compression codings defined in is identical (as is the case for the compression codings defined in
Section 4.2 of [RFC7230]). Section 4.2 of [MESSGNG]).
Values to be added to this namespace require IETF Review (see Section Values to be added to this namespace require IETF Review (see
4.1 of [RFC5226]) and MUST conform to the purpose of content coding Section 4.1 of [RFC5226]) and MUST conform to the purpose of content
defined in this section. coding defined in this section.
8.4.2. Registrations 8.4.2. Registrations
The "HTTP Content Coding Registry" has been updated with the The "HTTP Content Coding Registry" has been updated with the
registrations below: registrations below:
+----------+----------------------------------------+---------------+ +----------+------------------------------------------+-------------+
| Name | Description | Reference | | Name | Description | Reference |
+----------+----------------------------------------+---------------+ +----------+------------------------------------------+-------------+
| identity | Reserved (synonym for "no encoding" in | Section 5.3.4 | | identity | Reserved (synonym for "no encoding" in | Section 5.3 |
| | Accept-Encoding) | | | | Accept-Encoding) | .4 |
+----------+----------------------------------------+---------------+ +----------+------------------------------------------+-------------+
9. Security Considerations 9. Security Considerations
This section is meant to inform developers, information providers, This section is meant to inform developers, information providers,
and users of known security concerns relevant to HTTP semantics and and users of known security concerns relevant to HTTP semantics and
its use for transferring information over the Internet. its use for transferring information over the Internet.
Considerations related to message syntax, parsing, and routing are Considerations related to message syntax, parsing, and routing are
discussed in Section 9 of [RFC7230]. discussed in Section 9 of [MESSGNG].
The list of considerations below is not exhaustive. Most security The list of considerations below is not exhaustive. Most security
concerns related to HTTP semantics are about securing server-side concerns related to HTTP semantics are about securing server-side
applications (code behind the HTTP interface), securing user agent applications (code behind the HTTP interface), securing user agent
processing of payloads received via HTTP, or secure use of the processing of payloads received via HTTP, or secure use of the
Internet in general, rather than security of the protocol. Various Internet in general, rather than security of the protocol. Various
organizations maintain topical information and links to current organizations maintain topical information and links to current
research on Web application security (e.g., [OWASP]). research on Web application security (e.g., [OWASP]).
9.1. Attacks Based on File and Path Names 9.1. Attacks Based on File and Path Names
skipping to change at page 83, line 36 skipping to change at page 83, line 36
9.4. Disclosure of Sensitive Information in URIs 9.4. Disclosure of Sensitive Information in URIs
URIs are intended to be shared, not secured, even when they identify URIs are intended to be shared, not secured, even when they identify
secure resources. URIs are often shown on displays, added to secure resources. URIs are often shown on displays, added to
templates when a page is printed, and stored in a variety of templates when a page is printed, and stored in a variety of
unprotected bookmark lists. It is therefore unwise to include unprotected bookmark lists. It is therefore unwise to include
information within a URI that is sensitive, personally identifiable, information within a URI that is sensitive, personally identifiable,
or a risk to disclose. or a risk to disclose.
Authors of services ought to avoid GET-based forms for the submission Authors of services ought to avoid GET-based forms for the submission
of sensitive data because that data will be placed in the of sensitive data because that data will be placed in the request-
request-target. Many existing servers, proxies, and user agents log target. Many existing servers, proxies, and user agents log or
or display the request-target in places where it might be visible to display the request-target in places where it might be visible to
third parties. Such services ought to use POST-based form submission third parties. Such services ought to use POST-based form submission
instead. instead.
Since the Referer header field tells a target site about the context Since the Referer header field tells a target site about the context
that resulted in a request, it has the potential to reveal that resulted in a request, it has the potential to reveal
information about the user's immediate browsing history and any information about the user's immediate browsing history and any
personal information that might be found in the referring resource's personal information that might be found in the referring resource's
URI. Limitations on the Referer header field are described in URI. Limitations on the Referer header field are described in
Section 5.5.2 to address some of its security considerations. Section 5.5.2 to address some of its security considerations.
skipping to change at page 84, line 20 skipping to change at page 84, line 20
of the response. In particular, when a redirect occurs and the of the response. In particular, when a redirect occurs and the
original request's fragment identifier is inherited by the new original request's fragment identifier is inherited by the new
reference in Location (Section 7.1.2), this might have the effect of reference in Location (Section 7.1.2), this might have the effect of
disclosing one site's fragment to another site. If the first site disclosing one site's fragment to another site. If the first site
uses personal information in fragments, it ought to ensure that uses personal information in fragments, it ought to ensure that
redirects to other sites include a (possibly empty) fragment redirects to other sites include a (possibly empty) fragment
component in order to block that inheritance. component in order to block that inheritance.
9.6. Disclosure of Product Information 9.6. Disclosure of Product Information
The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [RFC7230]), and The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [MESSGNG]), and
Server (Section 7.4.2) header fields often reveal information about Server (Section 7.4.2) header fields often reveal information about
the respective sender's software systems. In theory, this can make the respective sender's software systems. In theory, this can make
it easier for an attacker to exploit known security holes; in it easier for an attacker to exploit known security holes; in
practice, attackers tend to try all potential holes regardless of the practice, attackers tend to try all potential holes regardless of the
apparent software versions being used. apparent software versions being used.
Proxies that serve as a portal through a network firewall ought to Proxies that serve as a portal through a network firewall ought to
take special precautions regarding the transfer of header information take special precautions regarding the transfer of header information
that might identify hosts behind the firewall. The Via header field that might identify hosts behind the firewall. The Via header field
allows intermediaries to replace sensitive machine names with allows intermediaries to replace sensitive machine names with
skipping to change at page 85, line 21 skipping to change at page 85, line 20
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
Accept-Language header field can reveal information the user might Accept-Language header field can reveal information the user might
consider to be of a private nature. For example, understanding a consider to be of a private nature. For example, understanding a
given language set might be strongly correlated to membership in a given language set might be strongly correlated to membership in a
particular ethnic group. An approach that limits such loss of particular ethnic group. An approach that limits such loss of
privacy would be for a user agent to omit the sending of privacy would be for a user agent to omit the sending of Accept-
Accept-Language except for sites that have been whitelisted, perhaps Language except for sites that have been whitelisted, perhaps via
via interaction after detecting a Vary header field that indicates interaction after detecting a Vary header field that indicates
language negotiation might be useful. language negotiation might be useful.
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. References
See Section 10 of [RFC7230]. 10.1. Normative References
11. References [AUTHFRM] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP): Authentication",
draft-ietf-httpbis-auth-00 (work in progress), April 2018.
11.1. Normative References [CACHING] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP): Caching", draft-
ietf-httpbis-cache-00 (work in progress), April 2018.
[CONDTNL] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP): Conditional
Requests", draft-ietf-httpbis-conditional-00 (work in
progress), April 2018.
[MESSGNG] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message
Syntax and Routing", draft-ietf-httpbis-messaging-00 (work
in progress), April 2018.
[RANGERQ] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP): Range Requests",
draft-ietf-httpbis-range-00 (work in progress), April
2018.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996. Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
<https://www.rfc-editor.org/info/rfc2045>.
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, Extensions (MIME) Part Two: Media Types", RFC 2046,
November 1996. DOI 10.17487/RFC2046, November 1996,
<https://www.rfc-editor.org/info/rfc2046>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language [RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language
Tags", BCP 47, RFC 4647, September 2006. Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September
2006, <https://www.rfc-editor.org/info/rfc4647>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
September 2011. DOI 10.17487/RFC6365, September 2011,
<https://www.rfc-editor.org/info/rfc6365>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, June 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
June 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
RFC 7233, June 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, June 2014.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
11.2. Informative References 10.2. Informative References
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013. RFC 6838, January 2013,
<https://www.rfc-editor.org/info/bcp13>.
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012. Application Protocols", BCP 178, RFC 6648, June 2012,
<https://www.rfc-editor.org/info/bcp178>.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004, <https://www.rfc-editor.org/info/bcp90>.
[OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web [OWASP] van der Stock, A., Ed., "A Guide to Building Secure Web
Applications and Web Services", The Open Web Application Applications and Web Services", The Open Web Application
Security Project (OWASP) 2.0.1, July 2005, Security Project (OWASP) 2.0.1, July 2005,
<https://www.owasp.org/>. <https://www.owasp.org/>.
[REST] Fielding, R., "Architectural Styles and the Design of [REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", Network-based Software Architectures",
Doctoral Dissertation, University of California, Irvine, Doctoral Dissertation, University of California, Irvine,
September 2000, September 2000,
<http://roy.gbiv.com/pubs/dissertation/top.htm>. <http://roy.gbiv.com/pubs/dissertation/top.htm>.
[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext [RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. Transfer Protocol -- HTTP/1.0", RFC 1945,
DOI 10.17487/RFC1945, May 1996,
<https://www.rfc-editor.org/info/rfc1945>.
[RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2049] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Five: Conformance Criteria and Extensions (MIME) Part Five: Conformance Criteria and
Examples", RFC 2049, November 1996. Examples", RFC 2049, DOI 10.17487/RFC2049, November 1996,
<https://www.rfc-editor.org/info/rfc2049>.
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T.
Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1",
RFC 2068, January 1997. RFC 2068, DOI 10.17487/RFC2068, January 1997,
<https://www.rfc-editor.org/info/rfc2068>.
[RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation [RFC2295] Holtman, K. and A. Mutz, "Transparent Content Negotiation
in HTTP", RFC 2295, March 1998. in HTTP", RFC 2295, DOI 10.17487/RFC2295, March 1998,
<https://www.rfc-editor.org/info/rfc2295>.
[RFC2388] Masinter, L., "Returning Values from Forms: multipart/ [RFC2388] Masinter, L., "Returning Values from Forms: multipart/
form-data", RFC 2388, August 1998. form-data", RFC 2388, DOI 10.17487/RFC2388, August 1998,
<https://www.rfc-editor.org/info/rfc2388>.
[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, [RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud,
"MIME Encapsulation of Aggregate Documents, such as HTML "MIME Encapsulation of Aggregate Documents, such as HTML
(MHTML)", RFC 2557, March 1999. (MHTML)", RFC 2557, DOI 10.17487/RFC2557, March 1999,
<https://www.rfc-editor.org/info/rfc2557>.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616,
DOI 10.17487/RFC2616, June 1999,
<https://www.rfc-editor.org/info/rfc2616>.
[RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP [RFC2774] Frystyk, H., Leach, P., and S. Lawrence, "An HTTP
Extension Framework", RFC 2774, February 2000. Extension Framework", RFC 2774, DOI 10.17487/RFC2774,
February 2000, <https://www.rfc-editor.org/info/rfc2774>.
[RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within
HTTP/1.1", RFC 2817, May 2000. HTTP/1.1", RFC 2817, DOI 10.17487/RFC2817, May 2000,
<https://www.rfc-editor.org/info/rfc2817>.
[RFC2978] Freed, N. and J. Postel, "IANA Charset Registration [RFC2978] Freed, N. and J. Postel, "IANA Charset Registration
Procedures", BCP 19, RFC 2978, October 2000. Procedures", BCP 19, RFC 2978, DOI 10.17487/RFC2978,
October 2000, <https://www.rfc-editor.org/info/rfc2978>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. DOI 10.17487/RFC5226, May 2008,
<https://www.rfc-editor.org/info/rfc5226>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008,
<https://www.rfc-editor.org/info/rfc5246>.
[RFC5322] Resnick, P., "Internet Message Format", RFC 5322, [RFC5322] Resnick, P., "Internet Message Format", RFC 5322,
October 2008. DOI 10.17487/RFC5322, October 2008,
<https://www.rfc-editor.org/info/rfc5322>.
[RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP", [RFC5789] Dusseault, L. and J. Snell, "PATCH Method for HTTP",
RFC 5789, March 2010. RFC 5789, DOI 10.17487/RFC5789, March 2010,
<https://www.rfc-editor.org/info/rfc5789>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, June 2010. Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC5987] Reschke, J., "Character Set and Language Encoding for [RFC5987] Reschke, J., "Character Set and Language Encoding for
Hypertext Transfer Protocol (HTTP) Header Field Hypertext Transfer Protocol (HTTP) Header Field
Parameters", RFC 5987, August 2010. Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010,
<https://www.rfc-editor.org/info/rfc5987>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
in the Hypertext Transfer Protocol (HTTP)", RFC 6266, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
June 2011. DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>.
[RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP) [RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Status Code 308 (Permanent Redirect)", RFC 7238, Status Code 308 (Permanent Redirect)", draft-reschke-http-
June 2014. status-308-07 (work in progress), March 2012.
Appendix A. Differences between HTTP and MIME Appendix A. Differences between HTTP and MIME
HTTP/1.1 uses many of the constructs defined for the Internet Message HTTP/1.1 uses many of the constructs defined for the Internet Message
Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME)
[RFC2045] to allow a message body to be transmitted in an open [RFC2045] to allow a message body to be transmitted in an open
variety of representations and with extensible header fields. variety of representations and with extensible header fields.
However, RFC 2045 is focused only on email; applications of HTTP have However, RFC 2045 is focused only on email; applications of HTTP have
many characteristics that differ from email; hence, HTTP has features many characteristics that differ from email; hence, HTTP has features
that differ from MIME. These differences were carefully chosen to that differ from MIME. These differences were carefully chosen to
skipping to change at page 89, line 28 skipping to change at page 90, line 28
This appendix describes specific areas where HTTP differs from MIME. This appendix describes specific areas where HTTP differs from MIME.
Proxies and gateways to and from strict MIME environments need to be Proxies and gateways to and from strict MIME environments need to be
aware of these differences and provide the appropriate conversions aware of these differences and provide the appropriate conversions
where necessary. where necessary.
A.1. MIME-Version A.1. MIME-Version
HTTP is not a MIME-compliant protocol. However, messages can include HTTP is not a MIME-compliant protocol. However, messages can include
a single MIME-Version header field to indicate what version of the a single MIME-Version header field to indicate what version of the
MIME protocol was used to construct the message. Use of the MIME protocol was used to construct the message. Use of the MIME-
MIME-Version header field indicates that the message is in full Version header field indicates that the message is in full
conformance with the MIME protocol (as defined in [RFC2045]). conformance with the MIME protocol (as defined in [RFC2045]).
Senders are responsible for ensuring full conformance (where Senders are responsible for ensuring full conformance (where
possible) when exporting HTTP messages to strict MIME environments. possible) when exporting HTTP messages to strict MIME environments.
A.2. Conversion to Canonical Form A.2. Conversion to Canonical Form
MIME requires that an Internet mail body part be converted to MIME requires that an Internet mail body part be converted to
canonical form prior to being transferred, as described in Section 4 canonical form prior to being transferred, as described in Section 4
of [RFC2049]. Section 3.1.1.3 of this document describes the forms of [RFC2049]. Section 3.1.1.3 of this document describes the forms
allowed for subtypes of the "text" media type when transmitted over allowed for subtypes of the "text" media type when transmitted over
skipping to change at page 90, line 20 skipping to change at page 91, line 20
A.3. Conversion of Date Formats A.3. Conversion of Date Formats
HTTP/1.1 uses a restricted set of date formats (Section 7.1.1.1) to HTTP/1.1 uses a restricted set of date formats (Section 7.1.1.1) to
simplify the process of date comparison. Proxies and gateways from simplify the process of date comparison. Proxies and gateways from
other protocols ought to ensure that any Date header field present in other protocols ought to ensure that any Date header field present in
a message conforms to one of the HTTP/1.1 formats and rewrite the a message conforms to one of the HTTP/1.1 formats and rewrite the
date if necessary. date if necessary.
A.4. Conversion of Content-Encoding A.4. Conversion of Content-Encoding
MIME does not include any concept equivalent to HTTP/1.1's MIME does not include any concept equivalent to HTTP/1.1's Content-
Content-Encoding header field. Since this acts as a modifier on the Encoding header field. Since this acts as a modifier on the media
media type, proxies and gateways from HTTP to MIME-compliant type, proxies and gateways from HTTP to MIME-compliant protocols
protocols ought to either change the value of the Content-Type header ought to either change the value of the Content-Type header field or
field or decode the representation before forwarding the message. decode the representation before forwarding the message. (Some
(Some experimental applications of Content-Type for Internet mail experimental applications of Content-Type for Internet mail have used
have used a media-type parameter of ";conversions=<content-coding>" a media-type parameter of ";conversions=<content-coding>" to perform
to perform a function equivalent to Content-Encoding. However, this a function equivalent to Content-Encoding. However, this parameter
parameter is not part of the MIME standards). is not part of the MIME standards).
A.5. Conversion of Content-Transfer-Encoding A.5. Conversion of Content-Transfer-Encoding
HTTP does not use the Content-Transfer-Encoding field of MIME. HTTP does not use the Content-Transfer-Encoding field of MIME.
Proxies and gateways from MIME-compliant protocols to HTTP need to Proxies and gateways from MIME-compliant protocols to HTTP need to
remove any Content-Transfer-Encoding prior to delivering the response remove any Content-Transfer-Encoding prior to delivering the response
message to an HTTP client. message to an HTTP client.
Proxies and gateways from HTTP to MIME-compliant protocols are Proxies and gateways from HTTP to MIME-compliant protocols are
responsible for ensuring that the message is in the correct format responsible for ensuring that the message is in the correct format
skipping to change at page 91, line 5 skipping to change at page 92, line 5
A.6. MHTML and Line Length Limitations A.6. MHTML and Line Length Limitations
HTTP implementations that share code with MHTML [RFC2557] HTTP implementations that share code with MHTML [RFC2557]
implementations need to be aware of MIME line length limitations. implementations need to be aware of MIME line length limitations.
Since HTTP does not have this limitation, HTTP does not fold long Since HTTP does not have this limitation, HTTP does not fold long
lines. MHTML messages being transported by HTTP follow all lines. MHTML messages being transported by HTTP follow all
conventions of MHTML, including line length limitations and folding, conventions of MHTML, including line length limitations and folding,
canonicalization, etc., since HTTP transfers message-bodies as canonicalization, etc., since HTTP transfers message-bodies as
payload and, aside from the "multipart/byteranges" type (Appendix A payload and, aside from the "multipart/byteranges" type (Appendix A
of [RFC7233]), does not interpret the content or any MIME header of [RANGERQ]), does not interpret the content or any MIME header
lines that might be contained therein. lines that might be contained therein.
Appendix B. Changes from RFC 2616 Appendix B. Changes from RFC 7231
The primary changes in this revision have been editorial in nature:
extracting the messaging syntax and partitioning HTTP semantics into
separate documents for the core features, conditional requests,
partial requests, caching, and authentication. The conformance
language has been revised to clearly target requirements and the
terminology has been improved to distinguish payload from
representations and representations from resources.
A new requirement has been added that semantics embedded in a URI be
disabled when those semantics are inconsistent with the request
method, since this is a common cause of interoperability failure.
(Section 2)
An algorithm has been added for determining if a payload is
associated with a specific identifier. (Section 3.1.4.1)
The default charset of ISO-8859-1 for text media types has been
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
affect the base URI for resolving relative URI references, due to
poor implementation support and the undesirable effect of potentially
breaking relative links in content-negotiated resources.
(Section 3.1.4.2)
To be consistent with the method-neutral parsing algorithm of
[RFC7230], the definition of GET has been relaxed so that requests
can have a body, even though a body has no meaning for GET.
(Section 4.3.1)
Servers are no longer required to handle all Content-* header fields
and use of Content-Range has been explicitly banned in PUT requests.
(Section 4.3.4)
Definition of the CONNECT method has been moved from [RFC2817] to
this specification. (Section 4.3.6)
The OPTIONS and TRACE request methods have been defined as being
safe. (Section 4.3.7 and Section 4.3.8)
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 has been restricted to the OPTIONS and
TRACE methods; previously, extension methods could have used it as
well. (Section 5.1.2)
The "about:blank" URI has been suggested as a value for the Referer
header field when no referring URI is applicable, which distinguishes
that case from others where the Referer field is not sent or has been
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 possibility that more than one resource has been created.
(Section 6.3.2)
The definition of 203 (Non-Authoritative Information) has been
broadened to include cases of payload transformations as well.
(Section 6.3.4)
The set of request methods that are safe to automatically redirect is
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 status codes 301 and 302 have been changed to allow user agents
to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3)
The description of the 303 (See Other) status code has been changed
to allow it to be cached if explicit freshness information is given,
and a specific definition has been added for a 303 response to GET.
(Section 6.4.4)
The 305 (Use Proxy) status code has been deprecated due to security
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
limited to syntax errors. (Section 6.5.1)
The 426 (Upgrade Required) status code has been incorporated from
[RFC2817]. (Section 6.5.15)
The target of requirements on HTTP-date and the Date header field
have been reduced to those systems generating the date, rather than
all systems sending a date. (Section 7.1.1)
The syntax of the Location header field has been changed to allow all
URI references, including relative references and fragments, along
with some clarifications as to when use of fragments would not be
appropriate. (Section 7.1.2)
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)
A Method Registry has been defined. (Section 8.1)
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
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 None yet.
inconsistently implemented with respect to partial responses.
Appendix C. Imported ABNF Appendix C. Imported ABNF
The following core rules are included by reference, as defined in The following core rules are included by reference, as defined in
Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF
(line feed), OCTET (any 8-bit sequence of data), SP (space), and (line feed), OCTET (any 8-bit sequence of data), SP (space), and
VCHAR (any visible US-ASCII character). VCHAR (any visible US-ASCII character).
The rules below are defined in [RFC7230]: The rules below are defined in [MESSGNG]:
BWS = <BWS, see [RFC7230], Section 3.2.3> BWS = <BWS, see [MESSGNG], Section 3.2.3>
OWS = <OWS, see [RFC7230], Section 3.2.3> OWS = <OWS, see [MESSGNG], Section 3.2.3>
RWS = <RWS, see [RFC7230], Section 3.2.3> RWS = <RWS, see [MESSGNG], Section 3.2.3>
URI-reference = <URI-reference, see [RFC7230], Section 2.7> URI-reference = <URI-reference, see [MESSGNG], Section 2.7>
absolute-URI = <absolute-URI, see [RFC7230], Section 2.7> absolute-URI = <absolute-URI, see [MESSGNG], Section 2.7>
comment = <comment, see [RFC7230], Section 3.2.6> comment = <comment, see [MESSGNG], Section 3.2.6>
field-name = <comment, see [RFC7230], Section 3.2> field-name = <comment, see [MESSGNG], Section 3.2>
partial-URI = <partial-URI, see [RFC7230], Section 2.7> partial-URI = <partial-URI, see [MESSGNG], Section 2.7>
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6> quoted-string = <quoted-string, see [MESSGNG], Section 3.2.6>
token = <token, see [RFC7230], Section 3.2.6> token = <token, see [MESSGNG], Section 3.2.6>
Appendix D. Collected ABNF Appendix D. Collected ABNF
In the collected ABNF below, list rules are expanded as per Section In the collected ABNF below, list rules are expanded as per
1.2 of [RFC7230]. Section 1.2 of [MESSGNG].
Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [ Accept = [ ( "," / ( media-range [ accept-params ] ) ) *( OWS "," [
OWS ( media-range [ accept-params ] ) ] ) ] OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS Accept-Charset = *( "," OWS ) ( ( charset / "*" ) [ weight ] ) *( OWS
"," [ OWS ( ( charset / "*" ) [ weight ] ) ] ) "," [ OWS ( ( charset / "*" ) [ weight ] ) ] )
Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS Accept-Encoding = [ ( "," / ( codings [ weight ] ) ) *( OWS "," [ OWS
( codings [ weight ] ) ] ) ] ( codings [ weight ] ) ] ) ]
Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS Accept-Language = *( "," OWS ) ( language-range [ weight ] ) *( OWS
"," [ OWS ( language-range [ weight ] ) ] ) "," [ OWS ( language-range [ weight ] ) ] )
Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ] Allow = [ ( "," / method ) *( OWS "," [ OWS method ] ) ]
BWS = <BWS, see [RFC7230], Section 3.2.3> BWS = <BWS, see [MESSGNG], Section 3.2.3>
Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS Content-Encoding = *( "," OWS ) content-coding *( OWS "," [ OWS
content-coding ] ) content-coding ] )
Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS Content-Language = *( "," OWS ) language-tag *( OWS "," [ OWS
language-tag ] ) language-tag ] )
Content-Location = absolute-URI / partial-URI Content-Location = absolute-URI / partial-URI
Content-Type = media-type Content-Type = media-type
Date = HTTP-date Date = HTTP-date
skipping to change at page 94, line 47 skipping to change at page 93, line 26
GMT = %x47.4D.54 ; GMT GMT = %x47.4D.54 ; GMT
HTTP-date = IMF-fixdate / obs-date HTTP-date = IMF-fixdate / obs-date
IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
Location = URI-reference Location = URI-reference
Max-Forwards = 1*DIGIT Max-Forwards = 1*DIGIT
OWS = <OWS, see [RFC7230], Section 3.2.3> OWS = <OWS, see [MESSGNG], Section 3.2.3>
RWS = <RWS, see [RFC7230], Section 3.2.3> RWS = <RWS, see [MESSGNG], Section 3.2.3>
Referer = absolute-URI / partial-URI Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-seconds Retry-After = HTTP-date / delay-seconds
Server = product *( RWS ( product / comment ) ) Server = product *( RWS ( product / comment ) )
URI-reference = <URI-reference, see [RFC7230], Section 2.7> URI-reference = <URI-reference, see [MESSGNG], Section 2.7>
User-Agent = product *( RWS ( product / comment ) ) User-Agent = product *( RWS ( product / comment ) )
Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ] Vary = "*" / ( *( "," OWS ) field-name *( OWS "," [ OWS field-name ]
) ) ) )
absolute-URI = <absolute-URI, see [RFC7230], Section 2.7> absolute-URI = <absolute-URI, see [MESSGNG], Section 2.7>
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ] accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]
accept-params = weight *accept-ext accept-params = weight *accept-ext
asctime-date = day-name SP date3 SP time-of-day SP year asctime-date = day-name SP date3 SP time-of-day SP year
charset = token charset = token
codings = content-coding / "identity" / "*" codings = content-coding / "identity" / "*"
comment = <comment, see [RFC7230], Section 3.2.6> comment = <comment, see [MESSGNG], Section 3.2.6>
content-coding = token content-coding = token
date1 = day SP month SP year date1 = day SP month SP year
date2 = day "-" month "-" 2DIGIT date2 = day "-" month "-" 2DIGIT
date3 = month SP ( 2DIGIT / ( SP DIGIT ) ) date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
day = 2DIGIT day = 2DIGIT
day-name = %x4D.6F.6E ; Mon day-name = %x4D.6F.6E ; Mon
/ %x54.75.65 ; Tue / %x54.75.65 ; Tue
/ %x57.65.64 ; Wed / %x57.65.64 ; Wed
/ %x54.68.75 ; Thu / %x54.68.75 ; Thu
skipping to change at page 95, line 42 skipping to change at page 94, line 22
/ %x53.75.6E ; Sun / %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday / %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday / %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday / %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday / %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday / %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday / %x53.75.6E.64.61.79 ; Sunday
delay-seconds = 1*DIGIT delay-seconds = 1*DIGIT
field-name = <comment, see [RFC7230], Section 3.2> field-name = <comment, see [MESSGNG], Section 3.2>
hour = 2DIGIT hour = 2DIGIT
language-range = <language-range, see [RFC4647], Section 2.1> language-range = <language-range, see [RFC4647], Section 2.1>
language-tag = <Language-Tag, see [RFC5646], Section 2.1> language-tag = <Language-Tag, see [RFC5646], Section 2.1>
mailbox = <mailbox, see [RFC5322], Section 3.4> mailbox = <mailbox, see [RFC5322], Section 3.4>
media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS media-range = ( "*/*" / ( type "/*" ) / ( type "/" subtype ) ) *( OWS
";" OWS parameter ) ";" OWS parameter )
media-type = type "/" subtype *( OWS ";" OWS parameter ) media-type = type "/" subtype *( OWS ";" OWS parameter )
method = token method = token
minute = 2DIGIT minute = 2DIGIT
month = %x4A.61.6E ; Jan month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb / %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar / %x4D.61.72 ; Mar
/ %x41.70.72 ; Apr / %x41.70.72 ; Apr
/ %x4D.61.79 ; May / %x4D.61.79 ; May
/ %x4A.75.6E ; Jun / %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul / %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug / %x41.75.67 ; Aug
/ %x53.65.70 ; Sep / %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct / %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov / %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec / %x44.65.63 ; Dec
obs-date = rfc850-date / asctime-date obs-date = rfc850-date / asctime-date
parameter = token "=" ( token / quoted-string ) parameter = token "=" ( token / quoted-string )
partial-URI = <partial-URI, see [RFC7230], Section 2.7> partial-URI = <partial-URI, see [MESSGNG], Section 2.7>
product = token [ "/" product-version ] product = token [ "/" product-version ]
product-version = token product-version = token
quoted-string = <quoted-string, see [RFC7230], Section 3.2.6>
quoted-string = <quoted-string, see [MESSGNG], Section 3.2.6>
qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] ) qvalue = ( "0" [ "." *3DIGIT ] ) / ( "1" [ "." *3"0" ] )
rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
second = 2DIGIT second = 2DIGIT
subtype = token subtype = token
time-of-day = hour ":" minute ":" second time-of-day = hour ":" minute ":" second
token = <token, see [RFC7230], Section 3.2.6> token = <token, see [MESSGNG], Section 3.2.6>
type = token type = token
weight = OWS ";" OWS "q=" qvalue weight = OWS ";" OWS "q=" qvalue
year = 4DIGIT year = 4DIGIT
Index Appendix E. Change Log
1 This section is to be removed before publishing as an RFC.
1xx Informational (status code class) 50
2 E.1. Since RFC 7231
2xx Successful (status code class) 51
3 The changes in this draft are purely editorial:
3xx Redirection (status code class) 54
4 o Change boilerplate and abstract to indicate the "draft" status,
4xx Client Error (status code class) 58 and update references to ancestor specifications.
5 o Remove version "1.1" from document title, indicating that this
5xx Server Error (status code class) 62 specification applies to all HTTP versions.
o Adjust historical notes.
o Update links to sibling specifications.
o Replace sections listing changes from RFC 2616 by new empty
sections referring to RFC 723x.
o Remove acknowledgements specific to RFC 723x.
o Move "Acknowledgements" to the very end and make them unnumbered.
Index
1 1
100 Continue (status code) 50 100 Continue (status code) 50
100-continue (expect value) 34 100-continue (expect value) 34
101 Switching Protocols (status code) 50 101 Switching Protocols (status code) 50
1xx Informational (status code class) 50
2 2
200 OK (status code) 51 200 OK (status code) 51
201 Created (status code) 52 201 Created (status code) 52
202 Accepted (status code) 52 202 Accepted (status code) 52
203 Non-Authoritative Information (status code) 52 203 Non-Authoritative Information (status code) 52
204 No Content (status code) 53 204 No Content (status code) 53
205 Reset Content (status code) 53 205 Reset Content (status code) 53
2xx Successful (status code class) 51
3 3
300 Multiple Choices (status code) 55 300 Multiple Choices (status code) 55
301 Moved Permanently (status code) 56 301 Moved Permanently (status code) 56
302 Found (status code) 56 302 Found (status code) 57
303 See Other (status code) 57 303 See Other (status code) 57
305 Use Proxy (status code) 58 305 Use Proxy (status code) 58
306 (Unused) (status code) 58 306 (Unused) (status code) 58
307 Temporary Redirect (status code) 58 307 Temporary Redirect (status code) 58
3xx Redirection (status code class) 54
4 4
400 Bad Request (status code) 58 400 Bad Request (status code) 59
402 Payment Required (status code) 59 402 Payment Required (status code) 59
403 Forbidden (status code) 59 403 Forbidden (status code) 59
404 Not Found (status code) 59 404 Not Found (status code) 59
405 Method Not Allowed (status code) 59 405 Method Not Allowed (status code) 59
406 Not Acceptable (status code) 59 406 Not Acceptable (status code) 60
408 Request Timeout (status code) 60 408 Request Timeout (status code) 60
409 Conflict (status code) 60 409 Conflict (status code) 60
410 Gone (status code) 60 410 Gone (status code) 61
411 Length Required (status code) 61 411 Length Required (status code) 61
413 Payload Too Large (status code) 61 413 Payload Too Large (status code) 61
414 URI Too Long (status code) 61 414 URI Too Long (status code) 62
415 Unsupported Media Type (status code) 62 415 Unsupported Media Type (status code) 62
417 Expectation Failed (status code) 62 417 Expectation Failed (status code) 62
426 Upgrade Required (status code) 62 426 Upgrade Required (status code) 62
4xx Client Error (status code class) 58
5 5
500 Internal Server Error (status code) 63 500 Internal Server Error (status code) 63
501 Not Implemented (status code) 63 501 Not Implemented (status code) 63
502 Bad Gateway (status code) 63 502 Bad Gateway (status code) 63
503 Service Unavailable (status code) 63 503 Service Unavailable (status code) 64
504 Gateway Timeout (status code) 63 504 Gateway Timeout (status code) 64
505 HTTP Version Not Supported (status code) 64 505 HTTP Version Not Supported (status code) 64
5xx Server Error (status code class) 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 43
Allow header field 72 Allow header field 72
C C
cacheable 24
compress (content coding) 11
conditional request 36
CONNECT method 30 CONNECT method 30
content coding 11 Content-Encoding header field 11
content negotiation 6
Content-Encoding header field 12
Content-Language header field 13 Content-Language header field 13
Content-Location header field 15 Content-Location header field 15
Content-Transfer-Encoding header field 89 Content-Transfer-Encoding header field 91
Content-Type header field 10 Content-Type header field 10
cacheable 24
compress (content coding) 11
conditional request 37
content coding 11
content negotiation 6
D D
DELETE method 29
Date header field 67 Date header field 67
deflate (content coding) 11 deflate (content coding) 11
DELETE method 29
E E
Expect header field 34 Expect header field 34
F F
From header field 44 From header field 44
G G
GET method 24 GET method 24
Grammar Grammar
Accept 38 Accept 38
Accept-Charset 40 Accept-Charset 41
Accept-Encoding 41 Accept-Encoding 41
accept-ext 38 accept-ext 38
Accept-Language 42 Accept-Language 43
accept-params 38 accept-params 38
Allow 72 Allow 73
asctime-date 66 asctime-date 67
charset 9 charset 9
codings 41 codings 41
content-coding 11 content-coding 11
Content-Encoding 12 Content-Encoding 12
Content-Language 13 Content-Language 13
Content-Location 15 Content-Location 15
Content-Type 10 Content-Type 10
Date 67 Date 67
date1 65 date1 66
day 65 day 66
day-name 65 day-name 66
day-name-l 65 day-name-l 66
delay-seconds 69 delay-seconds 70
Expect 34 Expect 34
From 44 From 45
GMT 65 GMT 66
hour 65 hour 66
HTTP-date 65 HTTP-date 65
IMF-fixdate 65 IMF-fixdate 66
language-range 42 language-range 43
language-tag 13 language-tag 13
Location 68 Location 68
Max-Forwards 36 Max-Forwards 36
media-range 38 media-range 38
media-type 8 media-type 8
method 21 method 21
minute 65 minute 66
month 65 month 66
obs-date 66 obs-date 66
parameter 8 parameter 8
product 46 product 47
product-version 46 product-version 47
qvalue 38 qvalue 38
Referer 45 Referer 45
Retry-After 69 Retry-After 70
rfc850-date 66 rfc850-date 67
second 65 second 66
Server 73 Server 73
subtype 8 subtype 8
time-of-day 65 time-of-day 66
type 8 type 8
User-Agent 46 User-Agent 46
Vary 70 Vary 70
weight 38 weight 38
year 65 year 66
gzip (content coding) 11 gzip (content coding) 11
H H
HEAD method 25 HEAD method 25
I I
idempotent 23 idempotent 23
L L
Location header field 68 Location header field 68
M M
MIME-Version header field 90
Max-Forwards header field 36 Max-Forwards header field 36
MIME-Version header field 89
O O
OPTIONS method 31 OPTIONS method 31
P P
payload 17
POST method 25 POST method 25
PUT method 26 PUT method 26
payload 17
R R
Referer header field 45 Referer header field 45
representation 7
Retry-After header field 69 Retry-After header field 69
representation 7
S S
safe 22
selected representation 7, 71
Server header field 73 Server header field 73
Status Codes Classes Status Codes Classes
1xx Informational 50 1xx Informational 50
2xx Successful 51 2xx Successful 51
3xx Redirection 54 3xx Redirection 54
4xx Client Error 58 4xx Client Error 58
5xx Server Error 62 5xx Server Error 63
safe 22
selected representation 7, 71
T T
TRACE method 32 TRACE method 32
U U
User-Agent header field 46 User-Agent header field 46
V V
Vary header field 70 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
Acknowledgments
See Appendix "Acknowledgments" of [MESSGNG].
Authors' Addresses Authors' Addresses
Roy T. Fielding (editor) Roy T. Fielding (editor)
Adobe Systems Incorporated Adobe
345 Park Ave 345 Park Ave
San Jose, CA 95110 San Jose, CA 95110
USA USA
EMail: fielding@gbiv.com EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/ URI: http://roy.gbiv.com/
Mark Nottingham (editor)
Fastly
EMail: mnot@mnot.net
URI: https://www.mnot.net/
Julian F. Reschke (editor) Julian F. Reschke (editor)
greenbytes GmbH greenbytes GmbH
Hafenweg 16 Hafenweg 16
Muenster, NW 48155 Muenster, NW 48155
Germany Germany
EMail: julian.reschke@greenbytes.de EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/ URI: http://greenbytes.de/tech/webdav/
 End of changes. 238 change blocks. 
715 lines changed or deleted 684 lines changed or added

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