HTTP/2 Extended SETTINGS ExtensionMicrosoftmichael.bishop@microsoft.com
General
HTTPInternet-DraftHTTP/2 defines the SETTINGS frame to contain a single 32-bit value per
setting. While this is sufficient to convey everything used in the core
HTTP/2 specification, some protocols will require more complex values,
such as arrays of code-points or strings.For such protocols, this extension defines a parallel to the SETTINGS
frame, EXTENDED_SETTINGS, where the value of a setting is not a 32-bit
value, but a variable-length opaque data blob whose interpretation is
subject entirely to the definition of the protocol using it.In , values
for which IANA registries already exist must be communicated between
two HTTP/2 implementations. Since the SETTINGS frame constrains
setting values to a 32-bit value, the existing version of that
draft divides the 32-bit value into halves and dedicates bits
to each currently-known value. This requires the creation
of two duplicative IANA registries, and enormously constrains
future extensibility since each future supported value will consume
one of only sixteen bits. It also causes divergence from other
places in the protocol where a bitmask is not required and a
more sensible value can be used., likewise, defines a very limited bitmap in the 32-bit
value – two bits are defined, all others are reserved (and not useful).
The setting fits easily in a single byte, and need not consume a four-byte
value every time it is transferred. With minor changes to semantics,
a simple flag would have been sufficient – the primary requirement is
communication to the remote endpoint that an extension is supported.Alternately, a number of recent and in-progress HTTP/2 extensions
describe properties of the connection that are informative to the peer
(, ). These can be viewed as
connection properties that do not fit into a 32-bit value and therefore
have new frame types defined to carry them instead.Each extension could define its own SETTINGS-equivalent frame to carry
this data, as some extensions already have, but to do so every time
a new extension might require such a capability seems similarly
wasteful, given the limited frame type space (also an IANA registry).Instead, this draft proposes a unified EXTENDED_SETTINGS frame (and
accompanying settings synchronization logic) which permits values of
lengths other than 32 bits. These values are interpreted as defined by
the specification defining them, operate under similar semantics to the
original SETTINGS frame, and should make development of future
extensions much simpler.An HTTP/2 peer that supports the EXTENDED_SETTINGS frame indicates this
using the HTTP/2 SETTINGS_EXTENDED_SETTINGS (0xSETTING-TBD) setting.The initial value for the SETTINGS_EXTENDED_SETTINGS setting is 0
(0x00), indicating that the peer does not support the EXTENDED_SETTINGS
frame. A peer that is able to parse the EXTENDED_SETTINGS frame MUST set
this value to 1 (0x01).This setting MUST be sent before any of the frame types in
are sent, but those frames MAY be sent before the setting is
acknowledged and MAY be sent regardless of whether the peer has sent
this setting.The EXTENDED_SETTINGS frame (type=0xFRAME-TBD1) conveys configuration
parameters that affect how endpoints communicate, such as preferences
and constraints on peer behavior which occur in a form other than a
32-bit value. Individually, an EXTENDED_SETTINGS parameter can also be
referred to as a “setting”.EXTENDED_SETTINGS parameters are not negotiated; they describe
characteristics of the sending peer, which are used by the receiving
peer. However, a negotiation can be implied by the use of
EXTENDED_SETTINGS – a peer uses EXTENDED_SETTINGS to advertise a set of
supported values. The recipient can then choose which entries from this
list are also acceptable and proceed with the value it has chosen. (This
choice could be announced in a field of an extension frame, or in a
different setting.)Different values for the same parameter can be advertised by each peer.
For example, a server might support many different signing algorithms,
while a resource constrained client has only one or two that it can
validate.An EXTENDED_SETTINGS frame MAY be sent at any time by either endpoint
over the lifetime of the connection.Each parameter in an EXTENDED_SETTINGS frame replaces any existing value
for that parameter. Parameters are processed in the order in which they
appear, and a receiver of an EXTENDED_SETTINGS frame does not need to
maintain any state other than the current value of its parameters.
Therefore, the value of a EXTENDED_SETTINGS parameter is the last value
that is seen by a receiver.EXTENDED_SETTINGS parameters can request acknowledgement by the
receiving peer. To enable this, the EXTENDED_SETTINGS frame defines the
following flag:
When set, bit 0 indicates that this frame contains values which the
sender wants to know were understood and applied. For more information,
see .Like SETTINGS frames, EXTENDED_SETTINGS frames always apply to a
connection, never a single stream. The stream identifier for an
EXTENDED_SETTINGS frame MUST be zero (0x0). If an endpoint receives an
EXTENDED_SETTINGS frame whose stream identifier field is anything other
than 0x0, the endpoint MUST respond with a connection error (,
section 5.4.1) of type PROTOCOL_ERROR.The EXTENDED_SETTINGS frame affects connection state. A badly formed or
incomplete EXTENDED_SETTINGS frame MUST be treated as a connection error
(, section 5.4.1) of type PROTOCOL_ERROR.The payload of an EXTENDED_SETTINGS frame consists of zero or more
parameters, each consisting of an unsigned 16-bit setting identifier and
a length-prefixed binary value.In some cases (e.g. indications of feature support), the presence and
acknowledgement of a setting may be sufficient, and a value superfluous.
In order to accomodate such cases, implementations MUST track
identifiers with zero-length values differently from never-seen
identifiers. The initial value of each setting is “never-seen.”An implementation MUST ignore the contents for any EXTENDED_SETTINGS
identifier it does not understand.The EXTENDED_SETTINGS_ACK frame (type=0xFRAME-TBD2) acknowledges receipt
and application of specific values in the peer’s SETTINGS frame. It
contains a list of EXTENDED_SETTINGS identifiers which the sender has
understood and applied. This list MAY be empty.Any EXTENDED_SETTINGS_ACK frame whose length is not a multiple of two
bytes MUST be treated as a connection error ( section 5.4.1) of
type FRAME_SIZE_ERROR.Some values in EXTENDED_SETTINGS benefit from or require an
understanding of when the peer has received and applied the changed
parameter values. In order to provide such synchronization timepoints,
the recipient of a EXTENDED_SETTINGS frame MUST apply the updated
parameters as soon as possible upon receipt. The values in the
EXTENDED_SETTINGS frame MUST be processed in the order they appear, with
no other frame processing between values. Unsupported parameters MUST be
ignored.Once all values have been processed, if the REQUEST_ACK flag was set,
the recipient MUST immediately emit a EXTENDED_SETTINGS_ACK frame
listing the identifiers whose values were understood and applied. (If
none of the values were understood, the EXTENDED_SETTINGS_ACK frame will
be empty, but MUST still be sent.) Upon receiving an
EXTENDED_SETTINGS_ACK frame, the sender of the altered parameters can
know which settings were understood and can rely on that subset having
been applied.If the sender of an EXTENDED_SETTINGS frame with the REQUEST_ACK flag
set does not receive an acknowledgement from a peer that has sent the
SETTINGS_EXTENDED_SETTINGS setting within a reasonable amount of time,
it MAY issue a connection error ( Section 5.4.1) of type
SETTINGS_TIMEOUT. This error MUST NOT be sent if the peer has not
previously advertised support for EXTENDED_SETTINGS.Because these frames can be used to request that peers retain potentially-large
state, implementations need to use caution in their retention policies. Values
which are not understood MUST be discarded in order to protect against increased
memory usage. Specifications which make use of EXTENDED_SETTINGS MUST include details
about how the contents can be parsed and stored, and SHOULD include details about
how the information can be compressed and when it can safely be discarded.This draft establishes one new registry and add three entries across two
existing registries.A registry for Extended Settings identifiers is created in
. Two frame types are registered in
. The HTTP/2 SETTINGS_EXTENDED_SETTINGS setting is
registered in .This document establishes a registry for HTTP/2 extended settings. The
“HTTP/2 Extended Settings” registry manages a 16-bit space. The “HTTP/2
Extended Settings” registry operates under the “Expert Review” policy
for values in the range from 0x0000 to 0xefff, with values
between and 0xf000 and 0xffff being reserved for Experimental Use.New registrations are advised to provide the following information:
A symbolic name for the setting. Specifying a setting name is
optional.
The 16-bit code assigned to the setting.Specification: An optional reference to a specification that
describes the use of the setting.No entries are registered by this document.Two new frame types are registered in the “HTTP/2 Frame Types” registry
established in . The entries in the following table are
registered by this document.The SETTINGS_EXTENDED_SETTINGS setting is registered in the “HTTP/2
Settings” registry established in .
SETTINGS_EXTENDED_SETTINGS
0xSETTING-TBD
0
This document.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.Guidelines for Writing an IANA Considerations Section in RFCsMany protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.Secondary Certificate Authentication in HTTP/2TLS provides fundamental mutual authentication services for HTTP, supporting up to one server certificate and up to one client certificate associated to the session to prove client and server identities as necessary. This draft provides mechanisms for providing additional such certificates at the HTTP layer when these constraints are not sufficient. Many HTTP servers host content from several origins. HTTP/2 [RFC7540] permits clients to reuse an existing HTTP connection to a server provided that the secondary origin is also in the certificate provided during the TLS [I-D.ietf-tls-tls13] handshake. In many cases, servers will wish to maintain separate certificates for different origins but still desire the benefits of a shared HTTP connection. Similarly, servers may require clients to present authentication, but have different requirements based on the content the client is attempting to access. This document describes a how such certificates can be provided at the HTTP layer to support both scenarios.Hypertext Transfer Protocol Version 2 (HTTP/2) ExtensionMicrosoft CorporationHTTP Alternative ServicesThis document specifies "Alternative Services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.The ORIGIN HTTP/2 FrameThis document specifies the ORIGIN frame for HTTP/2, to indicate what origins are available on a given connection.