p2-semantics.unpg.txt   rfc7231.txt 
HTTPbis Working Group R. Fielding, Ed. Internet Engineering Task Force (IETF) R. Fielding, Ed.
Internet-Draft Adobe Request for Comments: 7231 Adobe
Obsoletes: 2616 (if approved) J. Reschke, Ed. Obsoletes: 2616 J. Reschke, Ed.
Updates: 2817 (if approved) greenbytes Updates: 2817 greenbytes
Intended status: Standards Track June 6, 2014 Category: Standards Track June 2014
Expires: December 8, 2014 ISSN: 2070-1721
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
draft-ietf-httpbis-p2-semantics-latest
Abstract Abstract
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level protocol for distributed, collaborative, hypertext information level protocol for distributed, collaborative, hypertext information
systems. This document defines the semantics of HTTP/1.1 messages, systems. This document defines the semantics of HTTP/1.1 messages,
as expressed by request methods, request header fields, response as expressed by request methods, request header fields, response
status codes, and response header fields, along with the payload of status codes, and response header fields, along with the payload of
messages (metadata and body content) and mechanisms for content messages (metadata and body content) and mechanisms for content
negotiation. negotiation.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at
<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
The current issues list is at
<http://tools.ietf.org/wg/httpbis/trac/report/3> and related
documents (including fancy diffs) can be found at
<http://tools.ietf.org/wg/httpbis/>.
_This is a temporary document for the purpose of tracking the
editorial changes made during the AUTH48 (RFC publication) phase._
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on December 8, 2014. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7231.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 37 skipping to change at page 3, line 7
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 ....................................................6
1.1. Conformance and Error Handling . . . . . . . . . . . . . . 6 1.1. Conformance and Error Handling .............................6
1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6 1.2. Syntax Notation ............................................6
2. Resources . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Resources .......................................................7
3. Representations . . . . . . . . . . . . . . . . . . . . . . . 7 3. Representations .................................................7
3.1. Representation Metadata . . . . . . . . . . . . . . . . . 8 3.1. Representation Metadata ....................................8
3.1.1. Processing Representation Data . . . . . . . . . . . . 8 3.1.1. Processing Representation Data ......................8
3.1.2. Encoding for Compression or Integrity . . . . . . . . 11 3.1.2. Encoding for Compression or Integrity ..............11
3.1.3. Audience Language . . . . . . . . . . . . . . . . . . 13 3.1.3. Audience Language ..................................13
3.1.4. Identification . . . . . . . . . . . . . . . . . . . . 14 3.1.4. Identification .....................................14
3.2. Representation Data . . . . . . . . . . . . . . . . . . . 17 3.2. Representation Data .......................................17
3.3. Payload Semantics . . . . . . . . . . . . . . . . . . . . 17 3.3. Payload Semantics .........................................17
3.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 18 3.4. Content Negotiation .......................................18
3.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 19 3.4.1. Proactive Negotiation ..............................19
3.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . . 20 3.4.2. Reactive Negotiation ...............................20
4. Request Methods ................................................21
4.1. Overview ..................................................21
4.2. Common Method Properties ..................................22
4.2.1. Safe Methods .......................................22
4.2.2. Idempotent Methods .................................23
4.2.3. Cacheable Methods ..................................24
4.3. Method Definitions ........................................24
4.3.1. GET ................................................24
4.3.2. HEAD ...............................................25
4.3.3. POST ...............................................25
4.3.4. PUT ................................................26
4.3.5. DELETE .............................................29
4.3.6. CONNECT ............................................30
4.3.7. OPTIONS ............................................31
4.3.8. TRACE ..............................................32
5. Request Header Fields ..........................................33
5.1. Controls ..................................................33
5.1.1. Expect .............................................34
5.1.2. Max-Forwards .......................................36
5.2. Conditionals ..............................................36
5.3. Content Negotiation .......................................37
5.3.1. Quality Values .....................................37
5.3.2. Accept .............................................38
5.3.3. Accept-Charset .....................................40
5.3.4. Accept-Encoding ....................................41
5.3.5. Accept-Language ....................................42
5.4. Authentication Credentials ................................44
5.5. Request Context ...........................................44
5.5.1. From ...............................................44
5.5.2. Referer ............................................45
5.5.3. User-Agent .........................................46
4. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 21 6. Response Status Codes ..........................................47
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 21 6.1. Overview of Status Codes ..................................48
4.2. Common Method Properties . . . . . . . . . . . . . . . . . 22 6.2. Informational 1xx .........................................50
4.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . 22 6.2.1. 100 Continue .......................................50
4.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . . 23 6.2.2. 101 Switching Protocols ............................50
4.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 24 6.3. Successful 2xx ............................................51
4.3. Method Definitions . . . . . . . . . . . . . . . . . . . . 24 6.3.1. 200 OK .............................................51
4.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 24 6.3.2. 201 Created ........................................52
4.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3.3. 202 Accepted .......................................52
4.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3.4. 203 Non-Authoritative Information ..................52
4.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.3.5. 204 No Content .....................................53
4.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . . 29 6.3.6. 205 Reset Content ..................................53
4.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 30 6.4. Redirection 3xx ...........................................54
4.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 31 6.4.1. 300 Multiple Choices ...............................55
4.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 32 6.4.2. 301 Moved Permanently ..............................56
5. Request Header Fields . . . . . . . . . . . . . . . . . . . . 33 6.4.3. 302 Found ..........................................56
5.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.4.4. 303 See Other ......................................57
5.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . . 34 6.4.5. 305 Use Proxy ......................................58
5.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . . 36 6.4.6. 306 (Unused) .......................................58
5.2. Conditionals . . . . . . . . . . . . . . . . . . . . . . . 36 6.4.7. 307 Temporary Redirect .............................58
5.3. Content Negotiation . . . . . . . . . . . . . . . . . . . 37 6.5. Client Error 4xx ..........................................58
5.3.1. Quality Values . . . . . . . . . . . . . . . . . . . . 37 6.5.1. 400 Bad Request ....................................58
5.3.2. Accept . . . . . . . . . . . . . . . . . . . . . . . . 38 6.5.2. 402 Payment Required ...............................59
5.3.3. Accept-Charset . . . . . . . . . . . . . . . . . . . . 40 6.5.3. 403 Forbidden ......................................59
5.3.4. Accept-Encoding . . . . . . . . . . . . . . . . . . . 41 6.5.4. 404 Not Found ......................................59
5.3.5. Accept-Language . . . . . . . . . . . . . . . . . . . 42 6.5.5. 405 Method Not Allowed .............................59
5.4. Authentication Credentials . . . . . . . . . . . . . . . . 43 6.5.6. 406 Not Acceptable .................................60
5.5. Request Context . . . . . . . . . . . . . . . . . . . . . 44 6.5.7. 408 Request Timeout ................................60
5.5.1. From . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.5.8. 409 Conflict .......................................60
5.5.2. Referer . . . . . . . . . . . . . . . . . . . . . . . 45 6.5.9. 410 Gone ...........................................60
5.5.3. User-Agent . . . . . . . . . . . . . . . . . . . . . . 46 6.5.10. 411 Length Required ...............................61
6. Response Status Codes . . . . . . . . . . . . . . . . . . . . 47 6.5.11. 413 Payload Too Large .............................61
6.1. Overview of Status Codes . . . . . . . . . . . . . . . . . 48 6.5.12. 414 URI Too Long ..................................61
6.2. Informational 1xx . . . . . . . . . . . . . . . . . . . . 50 6.5.13. 415 Unsupported Media Type ........................62
6.2.1. 100 Continue . . . . . . . . . . . . . . . . . . . . . 50 6.5.14. 417 Expectation Failed ............................62
6.2.2. 101 Switching Protocols . . . . . . . . . . . . . . . 50 6.5.15. 426 Upgrade Required ..............................62
6.3. Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51 6.6. Server Error 5xx ..........................................62
6.3.1. 200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51 6.6.1. 500 Internal Server Error ..........................63
6.3.2. 201 Created . . . . . . . . . . . . . . . . . . . . . 51 6.6.2. 501 Not Implemented ................................63
6.3.3. 202 Accepted . . . . . . . . . . . . . . . . . . . . . 52 6.6.3. 502 Bad Gateway ....................................63
6.3.4. 203 Non-Authoritative Information . . . . . . . . . . 52 6.6.4. 503 Service Unavailable ............................63
6.3.5. 204 No Content . . . . . . . . . . . . . . . . . . . . 53 6.6.5. 504 Gateway Timeout ................................63
6.3.6. 205 Reset Content . . . . . . . . . . . . . . . . . . 53 6.6.6. 505 HTTP Version Not Supported .....................64
6.4. Redirection 3xx . . . . . . . . . . . . . . . . . . . . . 54 7. Response Header Fields .........................................64
6.4.1. 300 Multiple Choices . . . . . . . . . . . . . . . . . 55 7.1. Control Data ..............................................64
6.4.2. 301 Moved Permanently . . . . . . . . . . . . . . . . 56 7.1.1. Origination Date ...................................65
6.4.3. 302 Found . . . . . . . . . . . . . . . . . . . . . . 56 7.1.2. Location ...........................................68
6.4.4. 303 See Other . . . . . . . . . . . . . . . . . . . . 57 7.1.3. Retry-After ........................................69
6.4.5. 305 Use Proxy . . . . . . . . . . . . . . . . . . . . 57 7.1.4. Vary ...............................................70
6.4.6. 306 (Unused) . . . . . . . . . . . . . . . . . . . . . 57 7.2. Validator Header Fields ...................................71
6.4.7. 307 Temporary Redirect . . . . . . . . . . . . . . . . 58 7.3. Authentication Challenges .................................72
6.5. Client Error 4xx . . . . . . . . . . . . . . . . . . . . . 58 7.4. Response Context ..........................................72
6.5.1. 400 Bad Request . . . . . . . . . . . . . . . . . . . 58 7.4.1. Allow ..............................................72
6.5.2. 402 Payment Required . . . . . . . . . . . . . . . . . 58 7.4.2. Server .............................................73
6.5.3. 403 Forbidden . . . . . . . . . . . . . . . . . . . . 58 8. IANA Considerations ............................................73
6.5.4. 404 Not Found . . . . . . . . . . . . . . . . . . . . 59 8.1. Method Registry ...........................................73
6.5.5. 405 Method Not Allowed . . . . . . . . . . . . . . . . 59 8.1.1. Procedure ..........................................74
6.5.6. 406 Not Acceptable . . . . . . . . . . . . . . . . . . 59 8.1.2. Considerations for New Methods .....................74
6.5.7. 408 Request Timeout . . . . . . . . . . . . . . . . . 60 8.1.3. Registrations ......................................75
6.5.8. 409 Conflict . . . . . . . . . . . . . . . . . . . . . 60 8.2. Status Code Registry ......................................75
6.5.9. 410 Gone . . . . . . . . . . . . . . . . . . . . . . . 60 8.2.1. Procedure ..........................................75
6.5.10. 411 Length Required . . . . . . . . . . . . . . . . . 61 8.2.2. Considerations for New Status Codes ................76
6.5.11. 413 Payload Too Large . . . . . . . . . . . . . . . . 61 8.2.3. Registrations ......................................76
6.5.12. 414 URI Too Long . . . . . . . . . . . . . . . . . . . 61 8.3. Header Field Registry .....................................77
6.5.13. 415 Unsupported Media Type . . . . . . . . . . . . . . 61 8.3.1. Considerations for New Header Fields ...............78
6.5.14. 417 Expectation Failed . . . . . . . . . . . . . . . . 62 8.3.2. Registrations ......................................80
6.5.15. 426 Upgrade Required . . . . . . . . . . . . . . . . . 62 8.4. Content Coding Registry ...................................81
6.6. Server Error 5xx . . . . . . . . . . . . . . . . . . . . . 62 8.4.1. Procedure ..........................................81
6.6.1. 500 Internal Server Error . . . . . . . . . . . . . . 62 8.4.2. Registrations ......................................81
6.6.2. 501 Not Implemented . . . . . . . . . . . . . . . . . 63 9. Security Considerations ........................................81
6.6.3. 502 Bad Gateway . . . . . . . . . . . . . . . . . . . 63 9.1. Attacks Based on File and Path Names ......................82
6.6.4. 503 Service Unavailable . . . . . . . . . . . . . . . 63 9.2. Attacks Based on Command, Code, or Query Injection ........82
6.6.5. 504 Gateway Timeout . . . . . . . . . . . . . . . . . 63 9.3. Disclosure of Personal Information ........................83
6.6.6. 505 HTTP Version Not Supported . . . . . . . . . . . . 63 9.4. Disclosure of Sensitive Information in URIs ...............83
7. Response Header Fields . . . . . . . . . . . . . . . . . . . . 64 9.5. Disclosure of Fragment after Redirects ....................84
7.1. Control Data . . . . . . . . . . . . . . . . . . . . . . . 64 9.6. Disclosure of Product Information .........................84
7.1.1. Origination Date . . . . . . . . . . . . . . . . . . . 64 9.7. Browser Fingerprinting ....................................84
7.1.2. Location . . . . . . . . . . . . . . . . . . . . . . . 68 10. Acknowledgments ...............................................85
7.1.3. Retry-After . . . . . . . . . . . . . . . . . . . . . 69 11. References ....................................................85
7.1.4. Vary . . . . . . . . . . . . . . . . . . . . . . . . . 70 11.1. Normative References .....................................85
7.2. Validator Header Fields . . . . . . . . . . . . . . . . . 71 11.2. Informative References ...................................86
7.3. Authentication Challenges . . . . . . . . . . . . . . . . 72 Appendix A. Differences between HTTP and MIME .....................89
7.4. Response Context . . . . . . . . . . . . . . . . . . . . . 72 A.1. MIME-Version ..............................................89
7.4.1. Allow . . . . . . . . . . . . . . . . . . . . . . . . 72 A.2. Conversion to Canonical Form ..............................89
7.4.2. Server . . . . . . . . . . . . . . . . . . . . . . . . 73 A.3. Conversion of Date Formats ................................90
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 A.4. Conversion of Content-Encoding ..........................90
8.1. Method Registry . . . . . . . . . . . . . . . . . . . . . 74 A.5. Conversion of Content-Transfer-Encoding .................90
8.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 74 A.6. MHTML and Line Length Limitations .........................90
8.1.2. Considerations for New Methods . . . . . . . . . . . . 74 Appendix B. Changes from RFC 2616 .................................91
8.1.3. Registrations . . . . . . . . . . . . . . . . . . . . 75 Appendix C. Imported ABNF .........................................93
8.2. Status Code Registry . . . . . . . . . . . . . . . . . . . 75 Appendix D. Collected ABNF ........................................94
8.2.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 75 Index .............................................................97
8.2.2. Considerations for New Status Codes . . . . . . . . . 76
8.2.3. Registrations . . . . . . . . . . . . . . . . . . . . 76
8.3. Header Field Registry . . . . . . . . . . . . . . . . . . 77
8.3.1. Considerations for New Header Fields . . . . . . . . . 78
8.3.2. Registrations . . . . . . . . . . . . . . . . . . . . 80
8.4. Content Coding Registry . . . . . . . . . . . . . . . . . 80
8.4.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 81
8.4.2. Registrations . . . . . . . . . . . . . . . . . . . . 81
9. Security Considerations . . . . . . . . . . . . . . . . . . . 81
9.1. Attacks Based on File and Path Names . . . . . . . . . . . 82
9.2. Attacks Based on Command, Code, or Query Injection . . . . 82
9.3. Disclosure of Personal Information . . . . . . . . . . . . 83
9.4. Disclosure of Sensitive Information in URIs . . . . . . . 83
9.5. Disclosure of Fragment after Redirects . . . . . . . . . . 83
9.6. Disclosure of Product Information . . . . . . . . . . . . 84
9.7. Browser Fingerprinting . . . . . . . . . . . . . . . . . . 84
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 85
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85
11.1. Normative References . . . . . . . . . . . . . . . . . . . 85
11.2. Informative References . . . . . . . . . . . . . . . . . . 86
Appendix A. Differences between HTTP and MIME . . . . . . . . . . 88
A.1. MIME-Version . . . . . . . . . . . . . . . . . . . . . . . 89
A.2. Conversion to Canonical Form . . . . . . . . . . . . . . . 89
A.3. Conversion of Date Formats . . . . . . . . . . . . . . . . 89
A.4. Conversion of Content-Encoding . . . . . . . . . . . . . . 89
A.5. Conversion of Content-Transfer-Encoding . . . . . . . . . 90
A.6. MHTML and Line Length Limitations . . . . . . . . . . . . 90
Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 90
Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 93
Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 93
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
1. Introduction 1. Introduction
Each Hypertext Transfer Protocol (HTTP) message is either a request Each Hypertext Transfer Protocol (HTTP) message is either a request
or a response. A server listens on a connection for a request, or a response. A server listens on a connection for a request,
parses each message received, interprets the message semantics in parses each message received, interprets the message semantics in
relation to the identified request target, and responds to that relation to the identified request target, and responds to that
request with one or more response messages. A client constructs request with one or more response messages. A client constructs
request messages to communicate specific intentions, 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
skipping to change at page 7, line 25 skipping to change at page 7, line 25
Section 2.7 of [RFC7230]. Section 2.7 of [RFC7230].
When a client constructs an HTTP/1.1 request message, it sends the When a client constructs an HTTP/1.1 request message, it sends the
target URI in one of various forms, as defined in (Section 5.3 of target URI in one of various forms, as defined in (Section 5.3 of
[RFC7230]). When a request is received, the server reconstructs an [RFC7230]). When a request is received, the server reconstructs an
effective request URI for the target resource (Section 5.5 of effective request URI for the target resource (Section 5.5 of
[RFC7230]). [RFC7230]).
One design goal of HTTP is to separate resource identification from One design goal of HTTP is to separate resource identification from
request semantics, which is made possible by vesting the request request semantics, which is made possible by vesting the request
semantics in the request method (Section 4) and a few request- semantics in the request method (Section 4) and a few
modifying header fields (Section 5). If there is a conflict between request-modifying header fields (Section 5). If there is a conflict
the method semantics and any semantic implied by the URI itself, as between the method semantics and any semantic implied by the URI
described in Section 4.2.1, the method semantics take precedence. itself, as described in Section 4.2.1, the method semantics take
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 13, line 14 skipping to change at page 13, line 21
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 Content- HTTP uses language tags within the Accept-Language and
Language header fields. Accept-Language uses the broader language- Content-Language header fields. Accept-Language uses the broader
range production defined in Section 5.3.5, whereas Content-Language language-range production defined in Section 5.3.5, whereas
uses the language-tag production defined below. Content-Language 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 16, line 18 skipping to change at page 16, line 29
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 field- subject to content negotiation and the Content-Location
value is a more specific identifier for the selected field-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 21, line 39 skipping to change at page 21, line 47
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 US- convention, standardized methods are defined in all-uppercase
ASCII letters. US-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 26, line 29 skipping to change at page 26, line 32
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 [RFC7234]).
However, POST caching is not widely implemented. For cases where an However, POST caching is not widely implemented. For cases where an
origin server wishes the client to be able to cache the result of a origin server wishes the client to be able to cache the result of a
POST in a way that can be reused by a later GET, the origin server POST in a way that can be reused by a later GET, the origin server
MAY send a 200 (OK) response containing the result and a Content- MAY send a 200 (OK) response containing the result and a
Location header field that has the same value as the POST's effective Content-Location header field that has the same value as the POST's
request URI (Section 3.1.4.2). effective 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 34, line 22 skipping to change at page 34, line 22
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 request- wishes to receive a 100 (Continue) interim response if the
line and header fields are not sufficient to cause an immediate request-line and header fields are not sufficient to cause an
success, redirect, or error response. This allows the client to wait immediate success, redirect, or error response. This allows the
for an indication that it is worthwhile to send the message body client to wait for an indication that it is worthwhile to send the
before actually doing so, which can improve efficiency when the message body before actually doing so, which can improve efficiency
message body is huge or when the client anticipates that an error is when the message body is huge or when the client anticipates that an
likely (e.g., when sending a state-changing method, for the first error is likely (e.g., when sending a state-changing method, for the
time, without previously verified authentication credentials). first 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 37 skipping to change at page 35, line 37
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 [RFC7230]).
An origin server MUST, upon receiving an HTTP/1.1 (or later) request- An origin server MUST, upon receiving an HTTP/1.1 (or later)
line and a complete header section that contains a 100-continue request-line and a complete header section that contains a
expectation and indicates a request message body will follow, either 100-continue expectation and indicates a request message body will
send an immediate response with a final status code, if that status follow, either send an immediate response with a final status code,
can be determined by examining just the request-line and header if that status can be determined by examining just the request-line
fields, or send an immediate 100 (Continue) response to encourage the and header fields, or send an immediate 100 (Continue) response to
client to send the request's message body. The origin server MUST encourage the client to send the request's message body. The origin
NOT wait for the message body before sending the 100 (Continue) server MUST NOT wait for the message body before sending the 100
response. (Continue) 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 38, line 23 skipping to change at page 38, line 23
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 in- small set of desired types, as in the case of a request for an
line image. in-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 40, line 44
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 Accept- matches every charset that is not mentioned elsewhere in the
Charset field. If no "*" is present in an Accept-Charset field, then Accept-Charset field. If no "*" is present in an Accept-Charset
any charsets not explicitly mentioned in the field are considered field, then any charsets not explicitly mentioned in the field are
"not acceptable" to the client. considered "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 6
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 Accept- acceptable by default unless specifically excluded by the
Encoding field stating either "identity;q=0" or "*;q=0" without a Accept-Encoding field stating either "identity;q=0" or "*;q=0"
more specific entry for "identity". without a more specific entry for "identity".
3. If the representation's content-coding is one of the content- 3. If the representation's content-coding is one of the
codings listed in the Accept-Encoding field, then it is content-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 43, line 32
was previously defined for HTTP in Section 14.4 of [RFC2616]. was previously defined for HTTP in Section 14.4 of [RFC2616].
It might be contrary to the privacy expectations of the user to send It might be contrary to the privacy expectations of the user to send
an Accept-Language header field with the complete linguistic an Accept-Language header field with the complete linguistic
preferences of the user in every request (Section 9.7). preferences of the user in every request (Section 9.7).
Since intelligibility is highly dependent on the individual user, Since intelligibility is highly dependent on the individual user,
user agents need to allow user control over the linguistic preference user agents need to allow user control over the linguistic preference
(either through configuration of the user agent itself or by (either through configuration of the user agent itself or by
defaulting to a user controllable system setting). A user agent that defaulting to a user controllable system setting). A user agent that
does not provide such control to the user MUST NOT send an Accept- does not provide such control to the user MUST NOT send an
Language header field. Accept-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
skipping to change at page 46, line 36 skipping to change at page 46, line 43
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 product- identifier. A sender SHOULD NOT generate information in
version that is not a version identifier (i.e., successive versions product-version that is not a version identifier (i.e., successive
of the same product name ought to differ only in the product-version versions of the same product name ought to differ only in the
portion of the product identifier). product-version 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 50, line 33 skipping to change at page 50, line 35
"Expect: 100-continue" field when it forwards a request, then it need "Expect: 100-continue" field when it forwards a request, then it need
not forward the corresponding 100 (Continue) response(s). not forward the corresponding 100 (Continue) response(s).
6.2.1. 100 Continue 6.2.1. 100 Continue
The 100 (Continue) status code indicates that the initial part of a The 100 (Continue) status code indicates that the initial part of a
request has been received and has not yet been rejected by the request has been received and has not yet been rejected by the
server. The server intends to send a final response after the server. The server intends to send a final response after the
request has been fully received and acted upon. request has been fully received and acted upon.
When the request contains an Expect header field that includes a 100- When the request contains an Expect header field that includes a
continue expectation, the 100 response indicates that the server 100-continue expectation, the 100 response indicates that the server
wishes to receive the request payload body, as described in wishes to receive the request payload body, as described in
Section 5.1.1. The client ought to continue sending the request and Section 5.1.1. The client ought to continue sending the request and
discard the 100 response. discard the 100 response.
If the request did not contain an Expect header field containing the If the request did not contain an Expect header field containing the
100-continue expectation, the client can simply discard this interim 100-continue expectation, the client can simply discard this interim
response. response.
6.2.2. 101 Switching Protocols 6.2.2. 101 Switching Protocols
skipping to change at page 52, line 10 skipping to change at page 52, line 15
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 Last- and purpose of validator header fields, such as ETag and
Modified, in a 201 response. Last-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 61, line 26 skipping to change at page 61, line 37
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 Retry- If the condition is temporary, the server SHOULD generate a
After header field to indicate that it is temporary and after what Retry-After header field to indicate that it is temporary and after
time the client MAY try again. what time the client MAY try again.
6.5.12. 414 URI Too Long 6.5.12. 414 URI Too Long
The 414 (URI Too Long) status code indicates that the server is The 414 (URI Too Long) status code indicates that the server is
refusing to service the request because the request-target (Section refusing to service the request because the request-target (Section
5.3 of [RFC7230]) is longer than the server is willing to interpret. 5.3 of [RFC7230]) is longer than the server is willing to interpret.
This rare condition is only likely to occur when a client has This rare condition is only likely to occur when a client has
improperly converted a POST request to a GET request with long query improperly converted a POST request to a GET request with long query
information, when the client has descended into a "black hole" of information, when the client has descended into a "black hole" of
redirection (e.g., a redirected URI prefix that points to a suffix of redirection (e.g., a redirected URI prefix that points to a suffix of
skipping to change at page 61, line 51 skipping to change at page 62, line 14
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 [RFC7234]).
6.5.13. 415 Unsupported Media Type 6.5.13. 415 Unsupported Media Type
The 415 (Unsupported Media Type) status code indicates that the The 415 (Unsupported Media Type) status code indicates that the
origin server is refusing to service the request because the payload origin server is refusing to service the request because the payload
is in a format not supported by this method on the target resource. is in a format not supported by this method on the target resource.
The format problem might be due to the request's indicated Content- The format problem might be due to the request's indicated
Type or Content-Encoding, or as a result of inspecting the data Content-Type or Content-Encoding, or as a result of inspecting the
directly. data 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
skipping to change at page 64, line 8 skipping to change at page 64, line 20
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 [RFC7230], 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 status- information about the response beyond what is placed in the
line. These header fields give information about the server, about status-line. These header fields give information about the server,
further access to the target resource, or about related resources. about further access to the target resource, or about related
resources.
Although each response header field has a defined meaning, in Although each response header field has a defined meaning, in
general, the precise semantics might be further refined by the general, the precise semantics might be further refined by the
semantics of the request method and/or response status code. semantics of the request method and/or response status code.
7.1. Control Data 7.1. Control Data
Response header fields can supply control data that supplements the Response header fields can supply control data that supplements the
status code, directs caching, or instructs the client where to go status code, directs caching, or instructs the client where to go
next. next.
skipping to change at page 65, line 12 skipping to change at page 65, line 28
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 HTTP- header field that contains one or more timestamps defined as
date, the sender MUST generate those timestamps in the IMF-fixdate HTTP-date, the sender MUST generate those timestamps in the
format. IMF-fixdate format.
An HTTP-date value represents time as an instance of Coordinated An HTTP-date value represents time as an instance of Coordinated
Universal Time (UTC). The first two formats indicate UTC by the Universal Time (UTC). The first two formats indicate UTC by the
three-letter abbreviation for Greenwich Mean Time, "GMT", a three-letter abbreviation for Greenwich Mean Time, "GMT", a
predecessor of the UTC name; values in the asctime format are assumed predecessor of the UTC name; values in the asctime format are assumed
to be in UTC. A sender that generates HTTP-date values from a local to be in UTC. A sender that generates HTTP-date values from a local
clock ought to use NTP ([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 67, line 22 skipping to change at page 67, line 7
/ %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 time- the grammar. The semantics of day-name, day, month, year, and
of-day are the same as those defined for the Internet Message Format time-of-day are the same as those defined for the Internet Message
constructs with the corresponding name ([RFC5322], Section 3.3). Format constructs with the corresponding name ([RFC5322], Section
3.3).
Recipients of a timestamp value in rfc850-date format, which uses a Recipients of a timestamp value in rfc850-date format, which uses a
two-digit year, 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 non- example, messages are occasionally forwarded over HTTP from a
HTTP source that might generate any of the date and time non-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 30 skipping to change at page 70, line 18
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 (case- either a single asterisk ("*") or a list of header field names
insensitive). (case-insensitive).
Vary = "*" / 1#field-name Vary = "*" / 1#field-name
A Vary field value of "*" signals that anything about the request A Vary field value of "*" signals that anything about the request
might play a role in selecting the response representation, possibly might play a role in selecting the response representation, possibly
including elements outside the message syntax (e.g., the client's including elements outside the message syntax (e.g., the client's
network address). 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 78, line 35 skipping to change at page 78, line 35
[RFC7230] as necessary, and are usually constrained to the range of [RFC7230] 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 [RFC7230]). Field definitions where
leading or trailing whitespace in values is significant will have to leading or trailing whitespace in values is significant will have to
use a container syntax such as quoted-string (Section 3.2.6 of use a container syntax such as quoted-string (Section 3.2.6 of
[RFC7230]). [RFC7230]).
Because commas (",") are used as a generic delimiter between field- Because commas (",") are used as a generic delimiter between
values, they need to be treated with care if they are allowed in the field-values, they need to be treated with care if they are allowed
field-value. Typically, components that might contain a comma are in the field-value. Typically, components that might contain a comma
protected with double-quotes using the quoted-string ABNF production. are protected with double-quotes using the quoted-string ABNF
production.
For example, a textual date and a URI (either of which might contain For example, a textual date and a URI (either of which might contain
a comma) could be safely carried in field-values like these: a comma) could be safely carried in field-values like these:
Example-URI-Field: "http://example.com/a.html,foo", Example-URI-Field: "http://example.com/a.html,foo",
"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 double- quoted-string production; using a different syntax inside
quotes will likely cause unnecessary confusion. double-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:
skipping to change at page 83, line 31 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 request- of sensitive data because that data will be placed in the
target. Many existing servers, proxies, and user agents log or request-target. Many existing servers, proxies, and user agents log
display the request-target in places where it might be visible to or 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 85, line 12 skipping to change at page 85, line 21
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 Accept- privacy would be for a user agent to omit the sending of
Language except for sites that have been whitelisted, perhaps via Accept-Language except for sites that have been whitelisted, perhaps
interaction after detecting a Vary header field that indicates via 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.
skipping to change at page 86, line 15 skipping to change at page 86, line 24
[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, September 2009.
[RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in [RFC6365] Hoffman, P. and J. Klensin, "Terminology Used in
Internationalization in the IETF", BCP 166, RFC 6365, Internationalization in the IETF", BCP 166, RFC 6365,
September 2011. September 2011.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
draft-ietf-httpbis-p1-messaging-latest (work in progress), RFC 7230, June 2014.
June 2014.
[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Conditional Requests", Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
draft-ietf-httpbis-p4-conditional-latest (work in June 2014.
progress), June 2014.
[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
"Hypertext Transfer Protocol (HTTP/1.1): Range Requests", "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
draft-ietf-httpbis-p5-range-latest (work in progress), RFC 7233, June 2014.
June 2014.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
draft-ietf-httpbis-p6-cache-latest (work in progress), RFC 7234, June 2014.
June 2014.
[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Authentication", Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
draft-ietf-httpbis-p7-auth-latest (work in progress),
June 2014.
11.2. Informative References 11.2. Informative References
[BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type [BCP13] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, January 2013. RFC 6838, January 2013.
[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, [BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham,
"Deprecating the "X-" Prefix and Similar Constructs in "Deprecating the "X-" Prefix and Similar Constructs in
Application Protocols", BCP 178, RFC 6648, June 2012. Application Protocols", BCP 178, RFC 6648, June 2012.
skipping to change at page 88, line 32 skipping to change at page 88, line 36
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[RFC6266] Reschke, J., "Use of the Content-Disposition Header Field [RFC6266] Reschke, J., "Use of the Content-Disposition Header Field
in the Hypertext Transfer Protocol (HTTP)", RFC 6266, in the Hypertext Transfer Protocol (HTTP)", RFC 6266,
June 2011. June 2011.
[RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP) [RFC7238] Reschke, J., "The Hypertext Transfer Protocol (HTTP)
Status Code 308 (Permanent Redirect)", Status Code 308 (Permanent Redirect)", RFC 7238,
draft-reschke-http-status-308-07 (work in progress), June 2014.
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 10 skipping to change at page 89, 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- MIME protocol was used to construct the message. Use of the
Version header field indicates that the message is in full MIME-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 89, line 50 skipping to change at page 90, 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 Content- MIME does not include any concept equivalent to HTTP/1.1's
Encoding header field. Since this acts as a modifier on the media Content-Encoding header field. Since this acts as a modifier on the
type, proxies and gateways from HTTP to MIME-compliant protocols media type, proxies and gateways from HTTP to MIME-compliant
ought to either change the value of the Content-Type header field or protocols ought to either change the value of the Content-Type header
decode the representation before forwarding the message. (Some field or decode the representation before forwarding the message.
experimental applications of Content-Type for Internet mail have used (Some experimental applications of Content-Type for Internet mail
a media-type parameter of ";conversions=<content-coding>" to perform have used a media-type parameter of ";conversions=<content-coding>"
a function equivalent to Content-Encoding. However, this parameter to perform a function equivalent to Content-Encoding. However, this
is not part of the MIME standards). parameter 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 96, line 49 skipping to change at page 97, line 29
5 5
5xx Server Error (status code class) 62 5xx Server Error (status code class) 62
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
2 2
200 OK (status code) 51 200 OK (status code) 51
201 Created (status code) 51 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
3 3
300 Multiple Choices (status code) 55 300 Multiple Choices (status code) 55
301 Moved Permanently (status code) 56 301 Moved Permanently (status code) 56
302 Found (status code) 56 302 Found (status code) 56
303 See Other (status code) 57 303 See Other (status code) 57
305 Use Proxy (status code) 57 305 Use Proxy (status code) 58
306 (Unused) (status code) 57 306 (Unused) (status code) 58
307 Temporary Redirect (status code) 58 307 Temporary Redirect (status code) 58
4 4
400 Bad Request (status code) 58 400 Bad Request (status code) 58
402 Payment Required (status code) 58 402 Payment Required (status code) 59
403 Forbidden (status code) 58 403 Forbidden (status code) 59
404 Not Found (status code) 59 404 Not Found (status code) 59
405 Method Not Allowed (status code) 59 405 Method Not Allowed (status code) 59
406 Not Acceptable (status code) 59 406 Not Acceptable (status code) 59
408 Request Timeout (status code) 60 408 Request Timeout (status code) 60
409 Conflict (status code) 60 409 Conflict (status code) 60
410 Gone (status code) 60 410 Gone (status code) 60
411 Length Required (status code) 61 411 Length Required (status code) 61
413 Payload Too Large (status code) 61 413 Payload Too Large (status code) 61
414 URI Too Long (status code) 61 414 URI Too Long (status code) 61
415 Unsupported Media Type (status code) 61 415 Unsupported Media Type (status code) 62
417 Expectation Failed (status code) 62 417 Expectation Failed (status code) 62
426 Upgrade Required (status code) 62 426 Upgrade Required (status code) 62
5 5
500 Internal Server Error (status code) 62 500 Internal Server Error (status code) 63
501 Not Implemented (status code) 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) 63
504 Gateway Timeout (status code) 63 504 Gateway Timeout (status code) 63
505 HTTP Version Not Supported (status code) 63 505 HTTP Version Not Supported (status code) 64
A A
Accept header field 38 Accept header field 38
Accept-Charset header field 40 Accept-Charset header field 40
Accept-Encoding header field 41 Accept-Encoding header field 41
Accept-Language header field 42 Accept-Language header field 42
Allow header field 72 Allow header field 72
C C
cacheable 24 cacheable 24
compress (content coding) 11 compress (content coding) 11
conditional request 36 conditional request 36
CONNECT method 30 CONNECT method 30
content coding 11 content coding 11
content negotiation 6 content negotiation 6
Content-Encoding header field 12 Content-Encoding header field 12
Content-Language header field 13 Content-Language header field 13
Content-Location header field 15 Content-Location header field 15
Content-Transfer-Encoding header field 90 Content-Transfer-Encoding header field 89
Content-Type header field 10 Content-Type header field 10
D D
Date header field 67 Date header field 67
deflate (content coding) 11 deflate (content coding) 11
DELETE method 29 DELETE method 29
E E
Expect header field 34 Expect header field 34
skipping to change at page 98, line 34 skipping to change at page 99, line 15
G G
GET method 24 GET method 24
Grammar Grammar
Accept 38 Accept 38
Accept-Charset 40 Accept-Charset 40
Accept-Encoding 41 Accept-Encoding 41
accept-ext 38 accept-ext 38
Accept-Language 42 Accept-Language 42
accept-params 38 accept-params 38
Allow 72 Allow 72
asctime-date 67 asctime-date 66
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 66 date1 65
day 66 day 65
day-name 66 day-name 65
day-name-l 66 day-name-l 65
delay-seconds 70 delay-seconds 69
Expect 34 Expect 34
From 44 From 44
GMT 66 GMT 65
hour 66 hour 65
HTTP-date 64 HTTP-date 65
IMF-fixdate 66 IMF-fixdate 65
language-range 42 language-range 42
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 66 minute 65
month 66 month 65
obs-date 66 obs-date 66
parameter 8 parameter 8
product 46 product 46
product-version 46 product-version 46
qvalue 38 qvalue 38
Referer 45 Referer 45
Retry-After 70 Retry-After 69
rfc850-date 67 rfc850-date 66
second 66 second 65
Server 73 Server 73
subtype 8 subtype 8
time-of-day 66 time-of-day 65
type 8 type 8
User-Agent 46 User-Agent 46
Vary 70 Vary 70
weight 38 weight 38
year 66 year 65
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
 End of changes. 57 change blocks. 
308 lines changed or deleted 286 lines changed or added

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