Internet DRAFT - draft-goto-httpbis-preload-frame
draft-goto-httpbis-preload-frame
Network Working Group H. Goto
Internet-Draft GREE, inc
Expires: July 12, 2019 January 08, 2019
The PRELOAD Frame Extension
draft-goto-httpbis-preload-frame-01
Abstract
A server can send application data before a client sends data if they
are using HTTP/2 with TLS1.3 or HTTP/3. Indicating loading of
necessary resources without waiting for the first request from the
client may improve page loading performance. This document defines
the PRELOAD frame, which is a new extension frame that allows the
server to notify of preload information.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
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 https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 12, 2019.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Goto Expires July 12, 2019 [Page 1]
Internet-Draft PRELOAD Frame January 2019
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. PRELOAD Frame Overview . . . . . . . . . . . . . . . . . 2
2. PRELOAD Frame Extension . . . . . . . . . . . . . . . . . . . 3
2.1. Using Link Header . . . . . . . . . . . . . . . . . . . . 4
2.2. HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2.1. Frame Format . . . . . . . . . . . . . . . . . . . . 4
2.3. HTTP/3 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Padding . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.5. Error Code . . . . . . . . . . . . . . . . . . . . . . . 5
3. Security Considerations . . . . . . . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. Normative References . . . . . . . . . . . . . . . . . . 6
5.2. Informative References . . . . . . . . . . . . . . . . . 6
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 7
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
A server can send application data before a client sends application
data if they are using HTTP/2[RFC7540] with TLS1.3[RFC8446] or
HTTP/3[HTTP3]. But in HTTP/2 [RFC7540] the server only sends a
SETTINGS frame as the server connection preface. After that, it can
send an HTTP response (including a 103 status code [RFC8297]) or
server push only after receiving a request from the client.
Indicating loading of necessary resources without waiting for the
first request from the client may improve page loading performance.
In order to make effective use of opportunities for the server to
transmit application data for the first time, this document defines a
PRELOAD frame; a new extension frame which enables the server to
notify preload [Preload] information from the server.
1.1. PRELOAD Frame Overview
A PRELOAD frame can be sent with the application data that the server
first transmits after the TLS 1.3 handshake. The motivation of the
PRELOAD frame is to make effective use of that transmission
opportunity.
The flow is as follows:
Goto Expires July 12, 2019 [Page 2]
Internet-Draft PRELOAD Frame January 2019
Client Server
ClientHello -------->
ServerHello
{EncryptedExtensions}
{CertificateRequest*}
{Certificate*}
{CertificateVerify*}
{Finished}
<-------- [Application Data*]
- SETTINGS
(as Connection Preface)
- PRELOAD
{Finished} -------->
[Application Data] -------->
- Connection Preface
- SETTINGS
- SETTINGS(ACK)
- HEADERS
'-' Indicates HTTP/2 messages in Application Data.
Figure 1: OverView in HTTP/2 with TLS1.3
After sending ServerHello of the TLS 1.3 handshake, the server sends
a SETTINGS frame which is the server connection preface as TLS
Application Data. Subsequently, The server uses the SNI to identify
the domain which the client wants to send an HTTP request. The
server can indicate preload in the PRELOAD frame for resources
commonly used in that domain. The client parses the PRELOAD frame
and fetches the resource if it does not have cache for that resource.
The semantics are the same as those defined in Preload[Preload]. If
the client does not support a PRELOAD frame, it is simply ignored.
2. PRELOAD Frame Extension
Preload Frame Extension does not define a new format to convey
preload information. It uses the already defined Link HTTP header.
However, it is not an HTTP response carried in this frame, and it is
not associated with an HTTP request to an authority. Therefore, the
server MUST store only information about Preload[Preload] in this
frame to avoid confusion in the implementation.
Open Question: In the above, the PRELOAD frame is allowed to carry
only information about Preload[Preload]. However, adapting security
policies such as HSTS more quickly improves security. But it is not
associated with any specific request. It is possible to indicate the
domain to which the policy applies by specifying the target domain
Goto Expires July 12, 2019 [Page 3]
Internet-Draft PRELOAD Frame January 2019
(matching with SNI's HostName) in the PRELOAD frame. Does this
introduce any semantics or security issues?
Since this frame does not represent an HTTP response, it does not
have a context for header compression, is not possible to use a
dynamic table for encoding or decoding HTTP responses. Since the
Preload[Preload] frame may be ignored by the received endpoint the
dynamic header table MUST NOT be updated.
Open Question: Would it benefit if PRELOAD frames could use separate
dynamic header tables?
This document defines extensions for HTTP/2 and HTTP/3 separately.
2.1. Using Link Header
In preload using Link header [RFC8288], resources can be specified by
relative path. However, the PRELOAD frame is not associated with an
HTTP request to a particular authority. Therefore, the server SHOULD
specify a complete URI for the specification of resources within the
Preload.
Link: <https://example.com/app/script.js>; rel=preload; as=script
Figure 2: Link preload type example
2.2. HTTP/2
2.2.1. Frame Format
A PRELOAD frame (type=TBD) carries a Header Block containing Preload
information.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Block (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: PRELOAD frame payload
The payload of the PRELOAD frame contains the following fields:
o Header Block: HTTP header represented by HPACK [RFC7541]
The PRELOAD frame does not define any flags.
Goto Expires July 12, 2019 [Page 4]
Internet-Draft PRELOAD Frame January 2019
Endpoints that do not support this extension simply ignore reception
of this PRELOAD frame.
This PRELOAD frame can be sent only from the server on stream ID 0.
This frame MUST be ignored if the server receives this frame or if
the client receives this frame with a different stream ID. If a
client receives a PRELOAD frame that is too long, it SHOULD ignore
that.
A parse error of the Header Block in the PRELOAD frame MAY be treated
as COMPRESSION_ERROR, or MAY simply ignore this frame.
The server can send a PRELOAD frame before receiving
SETTINGS_MAX_HEADER_LIST_SIZE from the client. PRELOAD frames that
are too long should not be sent.
2.3. HTTP/3
The PRELOAD frames (type=TBD) can be used with HTTP/3. The format is
the same as described for Section 2.2.1, but the payload Header Block
uses QPACK [QPACK] instead of HPACK. This frame MUST NOT update the
dynamic header table.
The PRELOAD frame can only be sent from the server on the control
stream. This frame MUST be ignored if the server receives this frame
or if the client receives this frame with a different streams. If a
client receives a PRELOAD frame that is too long, it SHOULD ignore
that.
2.4. Padding
If the length of the PRELOAD frame changes depending on the SNI used,
observation the first application data to make the hostname inferable
on the path. This should be considered when encrypting SNI with
ENSI[TLS-ESNI].
(TBD) Use Padding
2.5. Error Code
(TBD)
Note: Should a new Error Code be defined?
Goto Expires July 12, 2019 [Page 5]
Internet-Draft PRELOAD Frame January 2019
3. Security Considerations
The server can consume client resources by sending a large PRELOAD
frame. Therefore, clients should ignore PRELOAD frames that are too
large.
4. IANA Considerations
This specification adds an entry to the "HTTP/2 Frame Type" registry.
o Frame Type: PRELOAD
o Code: TBD
o Specification: This draft
5. References
5.1. Normative References
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.
[RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints",
RFC 8297, DOI 10.17487/RFC8297, December 2017,
<https://www.rfc-editor.org/info/rfc8297>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
5.2. Informative References
[HTTP3] Bishop, M., Ed., "Hypertext Transfer Protocol Version 3
(HTTP/3)", draft-ietf-quic-http-latest (work in progress).
[Preload] Grigorik, I., "Preload", n.d.,
<https://w3c.github.io/preload/>.
Goto Expires July 12, 2019 [Page 6]
Internet-Draft PRELOAD Frame January 2019
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Header Compression for HTTP/3", draft-ietf-quic-qpack-
latest (work in progress).
[TLS-ESNI]
Rescorla, E., Oku, K., Sullivan, N., and C. Wood,
"Encrypted Server Name Indication for TLS 1.3", draft-
ietf-tls-esni-latest (work in progress), n.d..
Acknowledgements
I appreciate Masaki Fujimoto and Oku Kazuho for valuable feedbacks.
Author's Address
Hiroyuki Goto
GREE, inc
Email: hiroyuki.goto@gree.net
Goto Expires July 12, 2019 [Page 7]