An HTTP Status Code for Indicating Hints
DeNA Co., Ltd.
kazuhooku@gmail.com
General
HTTP
Internet-Draft
This memo introduces an informational status code for HTTP that can be used for indicating hints to
help a client start making preparations for processing the final response.
Discussion of this draft takes place on the HTTP working group mailing list (ietf-http-wg@w3.org),
which is archived at https://lists.w3.org/Archives/Public/ietf-http-wg/.
Working Group information can be found at https://httpwg.github.io/; source code and issues list
for this draft can be found at https://github.com/httpwg/http-extensions/labels/early-hints.
Most if not all of the web pages processed by a web browser contain links to external resources
that need to be fetched prior to rendering the documents. Therefore, it is beneficial to send such
links as early as possible in order to minimize the time spent until the browser becomes possible
to render the document. Link header of type “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 response immediately after
receiving a request. In fact, it is often the contrary. There are many deployments in which an
origin server needs to query a database before generating a response. It is also not unusual for an
origin server to 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 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 response is determined.
HTTP/2 () push can be used as a solution to the issue, but has its own limitations. The
resources that can be pushed using HTTP/2 are limited to those belonging to the same origin. Also,
it is impossible to send only the links of the resources using HTTP/2 push. Sending HTTP responses
for every resource is an inefficient way of using bandwidth, especially when a caching server
exists as an intermediary.
This memo defines a status code for sending an informational response (, section 6.2) that
contains headers that are likely to be included in the final response. A server can send the
informational response containing some of the headers to help the client start making preparations
for processing the final response, and then run time-consuming operations to generate the final
response. The informational response can also be used by an origin server to trigger HTTP/2 push at
an caching intermediary.
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”,
“RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in
.
This informational status code indicates the client that the server is likely to send a final
response with the headers included in the informational response.
A server MUST NOT include Content-Length, Transfer-Encoding, or any hop-by-hop headers (,
section 6.1) in the informational response using the status code.
A client MAY speculatively evaluate the headers included in the informational response while
waiting for the final response. For example, a client may recognize the link header of type preload
and start fetching the resource. However, the evaluation MUST NOT affect how the final response is
processed; the client must behave as if it had not seen the informational response.
An intermediary MAY drop the informational response. It MAY send HTTP/2 () push responses
using the information found in the informational response.
Clients may have issues handling Early Hints, since informational response is rarely used for
requests not including an Expect header (, section 5.1.1).
An HTTP/1.1 client that mishandles the informational response as a final response is likely to
consider all the responses to the succeeding requests sent over the same connection to be part of
the final response. Such behavior may constitute a cross-origin information disclosure
vulnerability in case the client multiplexes requests to different origins onto a single persistent
connection.
Therefore, a server might refrain from sending Early Hints over HTTP/1.1 unless when the client is
known to handle informational responses correctly.
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 response body is determined.
If Early Hints is standardized, the HTTP Status Codes Registry should be updated with the following
entries:
Code: 103
Description: Early Hints
Specification: this document
Thanks to Tatsuhiro Tsujikawa for coming up with the idea of sending the link headers using an
informational response.
Key words for use in RFCs to Indicate Requirement Levels
In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations.
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
The Hypertext Transfer Protocol (HTTP) is a stateless \%application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.
Hypertext Transfer Protocol Version 2 (HTTP/2)
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients.This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
Preload