draft-ietf-httpbis-semantics-05.txt   draft-ietf-httpbis-semantics-latest.txt 
HTTP Working Group R. Fielding, Ed. HTTP Working Group R. Fielding, Ed.
Internet-Draft Adobe Internet-Draft Adobe
Obsoletes: M. Nottingham, Ed. Obsoletes: M. Nottingham, Ed.
7230,7231,7232,7233,7235,7538 Fastly 7230,7231,7232,7233,7235,7538 Fastly
,7615 (if approved) J. Reschke, Ed. ,7615 (if approved) J. Reschke, Ed.
Intended status: Standards Track greenbytes Intended status: Standards Track greenbytes
Expires: January 9, 2020 July 8, 2019 Expires: February 17, 2020 August 16, 2019
HTTP Semantics HTTP Semantics
draft-ietf-httpbis-semantics-05 draft-ietf-httpbis-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: its systems. This document defines the semantics of HTTP: its
architecture, terminology, the "http" and "https" Uniform Resource architecture, terminology, the "http" and "https" Uniform Resource
Identifier (URI) schemes, core request methods, request header Identifier (URI) schemes, core request methods, request header
fields, response status codes, response header fields, and content fields, response status codes, response header fields, and content
negotiation. negotiation.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this draft takes place on the HTTP working group Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
Working Group information can be found at <https://httpwg.org/>; Working Group information can be found at <https://httpwg.org/>;
source code and issues list for this draft can be found at source code and issues list for this draft can be found at
<https://github.com/httpwg/http-core>. <https://github.com/httpwg/http-core>.
The changes in this draft are summarized in Appendix I.6. The changes in this draft are summarized in Appendix I.7.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 9, 2020. This Internet-Draft will expire on February 17, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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
skipping to change at page 4, line 8 skipping to change at page 4, line 8
6.3.3. Content-Range . . . . . . . . . . . . . . . . . . . . 55 6.3.3. Content-Range . . . . . . . . . . . . . . . . . . . . 55
6.3.4. Media Type multipart/byteranges . . . . . . . . . . . 57 6.3.4. Media Type multipart/byteranges . . . . . . . . . . . 57
6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 59 6.4. Content Negotiation . . . . . . . . . . . . . . . . . . . 59
6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 60 6.4.1. Proactive Negotiation . . . . . . . . . . . . . . . . 60
6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 61 6.4.2. Reactive Negotiation . . . . . . . . . . . . . . . . 61
7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 62 7. Request Methods . . . . . . . . . . . . . . . . . . . . . . . 62
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 62 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 62
7.2. Common Method Properties . . . . . . . . . . . . . . . . 64 7.2. Common Method Properties . . . . . . . . . . . . . . . . 64
7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 64 7.2.1. Safe Methods . . . . . . . . . . . . . . . . . . . . 64
7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 65 7.2.2. Idempotent Methods . . . . . . . . . . . . . . . . . 65
7.2.3. Cacheable Methods . . . . . . . . . . . . . . . . . . 66 7.2.3. Methods and Caching . . . . . . . . . . . . . . . . . 66
7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 66 7.3. Method Definitions . . . . . . . . . . . . . . . . . . . 66
7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 66 7.3.1. GET . . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 67 7.3.2. HEAD . . . . . . . . . . . . . . . . . . . . . . . . 67
7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 67 7.3.3. POST . . . . . . . . . . . . . . . . . . . . . . . . 67
7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 68 7.3.4. PUT . . . . . . . . . . . . . . . . . . . . . . . . . 68
7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 71 7.3.5. DELETE . . . . . . . . . . . . . . . . . . . . . . . 71
7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 72 7.3.6. CONNECT . . . . . . . . . . . . . . . . . . . . . . . 72
7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 73 7.3.7. OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 73
7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 74 7.3.8. TRACE . . . . . . . . . . . . . . . . . . . . . . . . 74
7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 75 7.4. Method Extensibility . . . . . . . . . . . . . . . . . . 75
7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 75 7.4.1. Method Registry . . . . . . . . . . . . . . . . . . . 75
7.4.2. Considerations for New Methods . . . . . . . . . . . 75 7.4.2. Considerations for New Methods . . . . . . . . . . . 76
8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 76 8. Request Header Fields . . . . . . . . . . . . . . . . . . . . 76
8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 76 8.1. Controls . . . . . . . . . . . . . . . . . . . . . . . . 76
8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 77 8.1.1. Expect . . . . . . . . . . . . . . . . . . . . . . . 77
8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 79 8.1.2. Max-Forwards . . . . . . . . . . . . . . . . . . . . 79
8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 80 8.2. Preconditions . . . . . . . . . . . . . . . . . . . . . . 80
8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 81 8.2.1. Evaluation . . . . . . . . . . . . . . . . . . . . . 81
8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 82 8.2.2. Precedence . . . . . . . . . . . . . . . . . . . . . 82
8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 84 8.2.3. If-Match . . . . . . . . . . . . . . . . . . . . . . 84
8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 85 8.2.4. If-None-Match . . . . . . . . . . . . . . . . . . . . 85
8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 86 8.2.5. If-Modified-Since . . . . . . . . . . . . . . . . . . 86
skipping to change at page 7, line 30 skipping to change at page 7, line 30
Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 177 Appendix F. Changes from RFC 7235 . . . . . . . . . . . . . . . 177
Appendix G. Changes from RFC 7538 . . . . . . . . . . . . . . . 177 Appendix G. Changes from RFC 7538 . . . . . . . . . . . . . . . 177
Appendix H. Changes from RFC 7615 . . . . . . . . . . . . . . . 177 Appendix H. Changes from RFC 7615 . . . . . . . . . . . . . . . 177
Appendix I. Change Log . . . . . . . . . . . . . . . . . . . . . 177 Appendix I. Change Log . . . . . . . . . . . . . . . . . . . . . 177
I.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 177 I.1. Between RFC723x and draft 00 . . . . . . . . . . . . . . 177
I.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 178 I.2. Since draft-ietf-httpbis-semantics-00 . . . . . . . . . . 178
I.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 178 I.3. Since draft-ietf-httpbis-semantics-01 . . . . . . . . . . 178
I.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 180 I.4. Since draft-ietf-httpbis-semantics-02 . . . . . . . . . . 180
I.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 180 I.5. Since draft-ietf-httpbis-semantics-03 . . . . . . . . . . 180
I.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 181 I.6. Since draft-ietf-httpbis-semantics-04 . . . . . . . . . . 181
I.7. Since draft-ietf-httpbis-semantics-05 . . . . . . . . . . 182
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 190 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 190
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 190 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 190
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a stateless application- The Hypertext Transfer Protocol (HTTP) is a stateless application-
level request/response protocol that uses extensible semantics and level request/response protocol that uses extensible semantics and
self-descriptive messages for flexible interaction with network-based self-descriptive messages for flexible interaction with network-based
hypertext information systems. HTTP is defined by a series of hypertext information systems. HTTP is defined by a series of
skipping to change at page 66, line 12 skipping to change at page 66, line 12
to operate on a version control repository might be able to recover to operate on a version control repository might be able to recover
from partial failure conditions by checking the target resource from partial failure conditions by checking the target resource
revision(s) after a failed connection, reverting or fixing any revision(s) after a failed connection, reverting or fixing any
changes that were partially applied, and then automatically retrying changes that were partially applied, and then automatically retrying
the requests that failed. the requests that failed.
A proxy MUST NOT automatically retry non-idempotent requests. A proxy MUST NOT automatically retry non-idempotent requests.
A client SHOULD NOT automatically retry a failed automatic retry. A client SHOULD NOT automatically retry a failed automatic retry.
7.2.3. Cacheable Methods 7.2.3. Methods and Caching
Request methods can be defined as "cacheable" to indicate that For a cache to store and use a response, the associated method needs
responses to them are allowed to be stored for future reuse; for to explicitly allow caching, and detail under what conditions a
specific requirements see [Caching]. In general, safe methods that response can be used to satisfy subsequent requests; a method
do not depend on a current or authoritative response are defined as definition which does not do so cannot be cached. For additional
cacheable; this specification defines GET, HEAD, and POST as requirements see [Caching].
cacheable, although the overwhelming majority of cache
implementations only support GET and HEAD. This specification defines caching semantics for GET, HEAD, and POST,
although the overwhelming majority of cache implementations only
support GET and HEAD.
7.3. Method Definitions 7.3. Method Definitions
7.3.1. GET 7.3.1. GET
The GET method requests transfer of a current selected representation The GET method requests transfer of a current selected representation
for the target resource. GET is the primary mechanism of information for the target resource. GET is the primary mechanism of information
retrieval and the focus of almost all performance optimizations. retrieval and the focus of almost all performance optimizations.
Hence, when people speak of retrieving some identifiable information Hence, when people speak of retrieving some identifiable information
via HTTP, they are generally referring to making a GET request. via HTTP, they are generally referring to making a GET request.
skipping to change at page 123, line 21 skipping to change at page 123, line 21
the user agent SHOULD present the enclosed representation to the the user agent SHOULD present the enclosed representation to the
user, since it usually contains relevant diagnostic information. user, since it usually contains relevant diagnostic information.
9.5.3. 402 Payment Required 9.5.3. 402 Payment Required
The 402 (Payment Required) status code is reserved for future use. The 402 (Payment Required) status code is reserved for future use.
9.5.4. 403 Forbidden 9.5.4. 403 Forbidden
The 403 (Forbidden) status code indicates that the server understood The 403 (Forbidden) status code indicates that the server understood
the request but refuses to authorize it. A server that wishes to the request but refuses to fulfill it. A server that wishes to make
make public why the request has been forbidden can describe that public why the request has been forbidden can describe that reason in
reason in the response payload (if any). the response payload (if any).
If authentication credentials were provided in the request, the If authentication credentials were provided in the request, the
server considers them insufficient to grant access. The client server considers them insufficient to grant access. The client
SHOULD NOT automatically repeat the request with the same SHOULD NOT automatically repeat the request with the same
credentials. The client MAY repeat the request with new or different credentials. The client MAY repeat the request with new or different
credentials. However, a request might be forbidden for reasons credentials. However, a request might be forbidden for reasons
unrelated to the credentials. unrelated to the credentials.
An origin server that wishes to "hide" the current existence of a An origin server that wishes to "hide" the current existence of a
forbidden target resource MAY instead respond with a status code of forbidden target resource MAY instead respond with a status code of
skipping to change at page 164, line 25 skipping to change at page 164, line 25
<https://www.iana.org/assignments/media-types> with the registration <https://www.iana.org/assignments/media-types> with the registration
information in Section 6.3.4 for the media type "multipart/ information in Section 6.3.4 for the media type "multipart/
byteranges". byteranges".
14. References 14. References
14.1. Normative References 14.1. Normative References
[Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [Caching] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", draft-ietf-httpbis-cache-latest (work Ed., "HTTP Caching", draft-ietf-httpbis-cache-latest (work
in progress), July 2019. in progress), August 2019.
[Messaging] [Messaging]
Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging- Ed., "HTTP/1.1 Messaging", draft-ietf-httpbis-messaging-
latest (work in progress), July 2019. latest (work in progress), August 2019.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format [RFC1950] Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data Format
Specification version 3.3", RFC 1950, Specification version 3.3", RFC 1950,
DOI 10.17487/RFC1950, May 1996, DOI 10.17487/RFC1950, May 1996,
<https://www.rfc-editor.org/info/rfc1950>. <https://www.rfc-editor.org/info/rfc1950>.
skipping to change at page 182, line 19 skipping to change at page 182, line 19
o Fix editorial issue in Section 6 (<https://github.com/httpwg/http- o Fix editorial issue in Section 6 (<https://github.com/httpwg/http-
core/issues/223>) core/issues/223>)
o In Section 9.5.20, rephrase language not to use "entity" anymore, o In Section 9.5.20, rephrase language not to use "entity" anymore,
and also avoid lowercase "may" (<https://github.com/httpwg/http- and also avoid lowercase "may" (<https://github.com/httpwg/http-
core/issues/224>) core/issues/224>)
o Move discussion of retries from [Messaging] into Section 7.2.2 o Move discussion of retries from [Messaging] into Section 7.2.2
(<https://github.com/httpwg/http-core/issues/230>) (<https://github.com/httpwg/http-core/issues/230>)
I.7. Since draft-ietf-httpbis-semantics-05
o In Section 7.2.3, remove concept of "cacheable methods" in favor
of prose (<https://github.com/httpwg/http-core/issues/54>)
o In Section 9.5.4, replace "authorize" with "fulfill"
(<https://github.com/httpwg/http-core/issues/218>)
Index Index
1 1
100 Continue (status code) 110 100 Continue (status code) 110
100-continue (expect value) 77 100-continue (expect value) 77
101 Switching Protocols (status code) 110 101 Switching Protocols (status code) 110
1xx Informational (status code class) 109 1xx Informational (status code class) 109
2 2
200 OK (status code) 110 200 OK (status code) 110
skipping to change at page 184, line 11 skipping to change at page 184, line 19
CONNECT method 72 CONNECT method 72
Canonical Root URI 100 Canonical Root URI 100
Content-Encoding header field 49 Content-Encoding header field 49
Content-Language header field 50 Content-Language header field 50
Content-Length header field 50 Content-Length header field 50
Content-Location header field 52 Content-Location header field 52
Content-MD5 header field 163 Content-MD5 header field 163
Content-Range header field 55 Content-Range header field 55
Content-Type header field 48 Content-Type header field 48
cache 14 cache 14
cacheable 14, 66 cacheable 14
captive portal 13 captive portal 13
client 10 client 10
compress (Coding Format) 43 compress (Coding Format) 43
compress (content coding) 42 compress (content coding) 42
conditional request 80 conditional request 80
connection 10 connection 10
content coding 42 content coding 42
content negotiation 8 content negotiation 8
D D
 End of changes. 14 change blocks. 
20 lines changed or deleted 31 lines changed or added

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