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.

Table of Contents

• 1. Introduction
• 1.1. PRELOAD Frame Overview
• 2. PRELOAD Frame Extension
• 2.1. Using Link Header
• 2.2. HTTP/2
• 2.2.1. Frame Format
• 2.3. HTTP/3
• 2.4. Padding
• 2.5. Error Code
• 3. Security Considerations
• 4. IANA Considerations
• 5. References
• 5.1. Normative References
• 5.2. Informative References
• Acknowledgements
• Author's Address

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:

   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 (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:

• Header Block: HTTP header represented by HPACK [RFC7541]

The PRELOAD frame does not define any flags.

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?

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.

• Frame Type: PRELOAD
• Code: TBD
• Specification: This draft

5. References

5.1. Normative References

5.2. Informative References

Acknowledgements

I appreciate Masaki Fujimoto and Oku Kazuho for valuable feedbacks.

Author's Address