The PRELOAD Frame ExtensionGREE, inchiroyuki.goto@gree.netInternet-DraftA 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.A server can send application data before a client sends application data if they are using HTTP/2 with TLS1.3 or HTTP/3. But in HTTP/2 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 ) 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 information from the server.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: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. If the client does not support a PRELOAD frame, it is simply ignored.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 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. 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 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 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.In preload using Link header , 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.A PRELOAD frame (type=TBD) carries a Header Block containing Preload information.The payload of the PRELOAD frame contains the following fields:Header Block: HTTP header represented by HPACK 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.The PRELOAD frames (type=TBD) can be used with HTTP/3. The format is the same as described for , but the payload Header Block uses 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. A server that has received this frame or received on a different stream MUST be treated as a connection error.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.(TBD) Use Padding(TBD)Note: Should a new Error Code be defined?The server can consume client resources by sending a large PRELOAD frame. Therefore, clients should ignore PRELOAD frames that are too large.This specification adds an entry to the “HTTP/2 Frame Type” registry.Frame Type: PRELOADCode: TBDSpecification: This draftHypertext 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.HPACK: Header Compression for HTTP/2This specification defines HPACK, a compression format for efficiently representing HTTP header fields, to be used in HTTP/2.An HTTP Status Code for Indicating HintsThis memo introduces an informational HTTP status code that can be used to convey hints that help a client make preparations for processing the final response.The Transport Layer Security (TLS) Protocol Version 1.3This document specifies version 1.3 of the Transport Layer Security (TLS) protocol. TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961. This document also specifies new requirements for TLS 1.2 implementations.Web LinkingThis specification defines a model for the relationships between resources on the Web ("links") and the type of those relationships ("link relation types").It also defines the serialisation of such links in HTTP headers with the Link header field.PreloadQPACK: Header Compression for HTTP/3Google, IncAkamai TechnologiesFacebookHypertext Transfer Protocol Version 3 (HTTP/3)Akamai TechnologiesEncrypted Server Name Indication for TLS 1.3RTFM, Inc.FastlyCloudflareApple, Inc.I appreciate Masaki Fujimoto and Oku Kazuho for valuable feedbacks.