draft-ietf-httpbis-early-hints-01.txt   draft-ietf-httpbis-early-hints-02.txt 
HTTP Working Group K. Oku HTTP Working Group K. Oku
Internet-Draft DeNA Co., Ltd. Internet-Draft DeNA Co., Ltd.
Intended status: Experimental March 29, 2017 Intended status: Experimental May 16, 2017
Expires: September 30, 2017 Expires: November 17, 2017
An HTTP Status Code for Indicating Hints An HTTP Status Code for Indicating Hints
draft-ietf-httpbis-early-hints-01 draft-ietf-httpbis-early-hints-02
Abstract Abstract
This memo introduces an informational status code for HTTP that can This memo introduces an informational HTTP status code that can be
be used for indicating hints to help a client start making used to convey hints that help a client make preparations for
preparations for processing the final response. processing the final response.
Note to Readers Note to Readers
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.github.io/ ; Working Group information can be found at https://httpwg.github.io/ ;
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-extensions/labels/early-hints . https://github.com/httpwg/http-extensions/labels/early-hints .
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 30, 2017. This Internet-Draft will expire on November 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 24 skipping to change at page 2, line 24
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. 103 Early Hints . . . . . . . . . . . . . . . . . . . . . . . 3 2. 103 Early Hints . . . . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4 3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4
6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
6.1. Since draft-ietf-httpbis-early-hints-00 . . . . . . . . . 4 6.1. Since draft-ietf-httpbis-early-hints-01 . . . . . . . . . 4
6.2. Since draft-ietf-httpbis-early-hints-00 . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5
7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5
7.2. Informative References . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 5
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
Most if not all of the web pages processed by a web browser contain It is common for HTTP responses to contain links to external
links to external resources that need to be fetched prior to resources that need to be fetched prior to their use; for example,
rendering the documents. Therefore, it is beneficial to send such rendering HTML by a Web browser. Having such links available to the
links as early as possible in order to minimize the time spent until client as early as possible helps to minimize perceived latency.
the browser becomes possible to render the document. Link header of
type "preload" ([Preload]) can be used to indicate such links within
the response headers of an HTTP response.
However, it is not always possible for an origin server to send a The "preload" ([Preload]) link relation can be used to convey such
response immediately after receiving a request. In fact, it is often links in the Link header field of an HTTP response. However, it is
the contrary. There are many deployments in which an origin server not always possible for an origin server to generate a response
needs to query a database before generating a response. It is also header block immediately after receiving a request. For example, the
not unusual for an origin server to delegate a request to an upstream origin server might need to query a database before generating a
HTTP server running at a distant location. response, or it might delegate a request to an upstream HTTP server
running at a distant location.
The dilemma here is that even though it is preferable for an origin The dilemma here is that even though it is preferable for an origin
server to send some headers as soon as it receives a request, it server to send some headers as soon as it receives a request, it
cannot do so until the status code and the headers of the final HTTP cannot do so until the status code and the full headers of the final
response is determined. HTTP response are determined.
HTTP/2 ([RFC7540]) push can be used as a solution to the issue, but HTTP/2 ([RFC7540]) server push can be used as a solution to this
has its own limitations. The resources that can be pushed using issue, but has its own limitations. The responses that can be pushed
HTTP/2 are limited to those belonging to the same origin. Also, it using HTTP/2 are limited to those belonging to the same origin.
is impossible to send only the links of the resources using HTTP/2 Also, it is impossible to send only the links using server push.
push. Sending HTTP responses for every resource is an inefficient Finally, sending HTTP responses for every resource is an inefficient
way of using bandwidth, especially when a caching server exists as an way of using bandwidth, especially when a caching server exists as an
intermediary. intermediary.
This memo defines a status code for sending an informational response This memo defines a status code for sending an informational response
([RFC7231], section 6.2) that contains headers that are likely to be ([RFC7231], section 6.2) that contains headers that are likely to be
included in the final response. A server can send the informational included in the final response. A server can send the informational
response containing some of the headers to help the client start response containing some of the headers to help the client start
making preparations for processing the final response, and then run making preparations for processing the final response, and then run
time-consuming operations to generate the final response. The time-consuming operations to generate the final response. The
informational response can also be used by an origin server to informational response can also be used by an origin server to
trigger HTTP/2 push at an caching intermediary. trigger HTTP/2 server push at a caching intermediary.
1.1. Notational Conventions 1.1. Notational Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. 103 Early Hints 2. 103 Early Hints
This informational status code indicates the client that the server The 103 (Early Hints) informational status code indicates the client
is likely to send a final response with the headers included in the that the server is likely to send a final response with the headers
informational response. included in the informational response.
A server MUST NOT include Content-Length, Transfer-Encoding, or any A server MUST NOT include Content-Length, Transfer-Encoding, or any
hop-by-hop headers ([RFC7230], section 6.1) in the informational hop-by-hop header fields ([RFC7230], section 6.1) in a 103 (Early
response using the status code. Hints) response.
A client MAY speculatively evaluate the headers included in the A client MAY speculatively evaluate the headers included in a 103
informational response while waiting for the final response. For (Early Hints) response while waiting for the final response. For
example, a client may recognize the link header of type preload and example, a client might recognize a Link header field value
start fetching the resource. However, the evaluation MUST NOT affect containing the relation type "preload" and start fetching the target
how the final response is processed; the client must behave as if it resource.
had not seen the informational response. A client MUST NOT process
the headers included in the response as if they belonged to the However, this MUST NOT affect how the final response is processed;
informational response. when handling it, the client MUST behave as if it had not seen the
informational response. In particular, a client MUST NOT process the
headers included in the final response as if they belonged to the
informational response, or vice versa.
An intermediary MAY drop the informational response. It MAY send An intermediary MAY drop the informational response. It MAY send
HTTP/2 ([RFC7540]) push responses using the information found in the HTTP/2 ([RFC7540]) server pushes using the information found in the
informational response. 103 (Early Hints) response.
3. Security Considerations 3. Security Considerations
Clients may have issues handling Early Hints, since informational Some clients may have issues handling 103 (Early Hints), since
response is rarely used for requests not including an Expect header informational responses are rarely used in reply to requests not
([RFC7231], section 5.1.1). including an Expect header ([RFC7231], section 5.1.1).
An HTTP/1.1 client that mishandles the informational response as a In particular, an HTTP/1.1 client that mishandles an informational
final response is likely to consider all the responses to the response as a final response is likely to consider all responses to
succeeding requests sent over the same connection to be part of the the succeeding requests sent over the same connection to be part of
final response. Such behavior may constitute a cross-origin the final response. Such behavior may constitute a cross-origin
information disclosure vulnerability in case the client multiplexes information disclosure vulnerability in case the client multiplexes
requests to different origins onto a single persistent connection. requests to different origins onto a single persistent connection.
Therefore, a server might refrain from sending Early Hints over Therefore, a server might refrain from sending Early Hints over
HTTP/1.1 unless when the client is known to handle informational HTTP/1.1 unless when the client is known to handle informational
responses correctly. responses correctly.
HTTP/2 clients are less likely to suffer from incorrect framing since HTTP/2 clients are less likely to suffer from incorrect framing since
handling of the response headers does not affect how the end of the handling of the response headers does not affect how the end of the
response body is determined. response body is determined.
4. IANA Considerations 4. IANA Considerations
If Early Hints is standardized, the HTTP Status Codes Registry should The HTTP Status Codes Registry will be updated with the following
be updated with the following entries: entry:
o Code: 103 o Code: 103
o Description: Early Hints o Description: Early Hints
o Specification: this document o Specification: [this document]
5. Acknowledgements 5. Acknowledgements
Thanks to Tatsuhiro Tsujikawa for coming up with the idea of sending Thanks to Tatsuhiro Tsujikawa for coming up with the idea of sending
the link headers using an informational response. the link headers using an informational response.
6. Changes 6. Changes
6.1. Since draft-ietf-httpbis-early-hints-00 6.1. Since draft-ietf-httpbis-early-hints-01
o Editorial changes.
6.2. Since draft-ietf-httpbis-early-hints-00
o Forbid processing the headers of a 103 response as part of the o Forbid processing the headers of a 103 response as part of the
informational response. informational response.
7. References 7. References
7.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
 End of changes. 19 change blocks. 
55 lines changed or deleted 61 lines changed or added

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