Skip to main content

Client Hint Reliability
draft-davidben-http-client-hint-reliability-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Author David Benjamin
Last updated 2020-08-27
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-davidben-http-client-hint-reliability-01
HTTP                                                         D. Benjamin
Internet-Draft                                                Google LLC
Updates: ietf-httpbis-client-hints (if                   August 27, 2020
         approved)
Intended status: Experimental
Expires: February 28, 2021

                        Client Hint Reliability
             draft-davidben-http-client-hint-reliability-01

Abstract

   This document defines the Critical-CH HTTP response header, and the
   ACCEPT_CH HTTP/2 frame to allow HTTP servers to reliably specify
   their Client Hint preferences, with minimal performance overhead.

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 February 28, 2021.

Copyright Notice

   Copyright (c) 2020 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.

Benjamin                Expires February 28, 2021               [Page 1]
Internet-Draft           Client Hint Reliability             August 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Definitions . . . . . . . . . . . . . . . . .   2
   3.  The Critical-CH Response Header Field . . . . . . . . . . . .   3
     3.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  The ACCEPT_CH HTTP/2 Frame  . . . . . . . . . . . . . . . . .   5
     4.1.  Processing ACCEPT_CH Frames . . . . . . . . . . . . . . .   6
     4.2.  Interaction with Critical-CH  . . . . . . . . . . . . . .   7
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  10
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  10
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   [I-D.ietf-httpbis-client-hints] defines a response header, Accept-CH,
   for servers to advertise a set of request headers used for proactive
   content negotiation.  This allows user agents to send request headers
   only when used, improving their performance overhead as well as
   reducing passive fingerprinting surface.

   However, on the first HTTP request to a server, the user agent will
   not have received the Accept-CH header and may not take the server
   preferences into account.  More generally, the server's configuration
   may have changed since the most recent HTTP request to the server.
   This document defines a pair of mechanisms to resolve this:

   1.  an HTTP response header, Critical-CH, for the server to instruct
       the user agent to retry the request

   2.  an alternate delivery mechanism for Accept-CH in HTTP/2
       [RFC7540], which can avoid the performance hit of a retry in most
       cases

2.  Conventions and Definitions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
   14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document uses the Augmented Backus-Naur Form (ABNF) notation of
   [RFC5234].

Benjamin                Expires February 28, 2021               [Page 2]
Internet-Draft           Client Hint Reliability             August 2020

3.  The Critical-CH Response Header Field

   When a user agent requests a resource based on a missing or outdated
   Accept-CH value, it may not send a desired request header field.
   Neither user agent nor server has enough information to reliably and
   efficiently recover from this situation.  The server can observe that
   the header is missing, but the user agent may not have supported the
   header, or may have chosen not to send it.  Triggering a new request
   in these cases would risk an infinite loop or an unnecessary round-
   trip.

   Conversely, the user agent can observe that a request header appears
   in the Accept-CH (Section 3.1 of [I-D.ietf-httpbis-client-hints]) and
   Vary (Section 7.1.4 of [RFC7231]) response header fields.  However,
   retrying based on this information would waste resources if the
   resource only used the Client Hint as an optional optimization.

   This document introduces critical Client Hints.  These are the Client
   Hints which meaningfully change the resulting resource.  For example,
   a server may use the Device-Memory Client Hint [DEVICE-MEMORY] to
   select simple and complex variants of a resource to different user
   agents.  Such a resource should be fetched consistently across page
   loads to avoid jarring user-visible switches.

   The server specifies critical Client Hints with the Critical-CH
   response header field.  It is a Structured Header
   [I-D.ietf-httpbis-header-structure] whose value MUST be an sf-list
   (Section 3.1 of [I-D.ietf-httpbis-header-structure]) whose members
   are tokens (Section 3.3.4 of [I-D.ietf-httpbis-header-structure]).
   Its ABNF is:

     Critical-CH = sf-list

   For example:

     Critical-CH: Sec-CH-Example, Sec-CH-Example-2

   Each token listed in the Critical-CH header SHOULD additionally be
   present in the Accept-CH and Vary response headers.

   When a user agent receives an HTTP response containing a Critical-CH
   header, it first processes the Accept-CH header as described in
   Section 3.1 of [I-D.ietf-httpbis-client-hints].  It then performs the
   following steps:

   1.  If the request did not use a safe method (Section 4.2.1 of
       [RFC7231]), ignore the Critical-CH header and continue processing
       the response as usual.

Benjamin                Expires February 28, 2021               [Page 3]
Internet-Draft           Client Hint Reliability             August 2020

   2.  If the response was already the result of a retry, ignore the
       Critical-CH header and continue processing the response as usual.

   3.  Determine the Client Hints that would have been sent given the
       updated Accept-CH value, incorporating the user agent's local
       policy and user preferences.  See also Section 2.1 of
       [I-D.ietf-httpbis-client-hints].

   4.  Compare this result to the Client Hints which were sent.  If any
       Client Hint listed in the Critical-CH header was not previously
       sent and would now have been sent, retry the request with the new
       preferences.  Otherwise, continue processing the response as
       usual.

   Note this procedure does not cause the user agent to send Client
   Hints it would not otherwise send.

3.1.  Example

   For example, if the user agent loads https://example.com with no
   knowledge of the server's Accept-CH preferences, it may send the
   following response:

     GET / HTTP/1.1
     Host: example.com

     HTTP/1.1 200 OK
     Content-Type: text/html
     Accept-CH: Sec-CH-Example, Sec-CH-Example-2
     Vary: Sec-CH-Example
     Critical-CH: Sec-CH-Example

   In this example, the server, across the whole origin, uses both Sec-
   CH-Example and Sec-CH-Example-2 Client Hints.  However, this resource
   only uses Sec-CH-Example, which it considers critical.

   The user agent now processes the Accept-CH header and determines it
   would have sent both headers.  Sec-CH-Example is listed in Critical-
   CH, so the user agent retries the request, and receives a more
   specific response.

Benjamin                Expires February 28, 2021               [Page 4]
Internet-Draft           Client Hint Reliability             August 2020

     GET / HTTP/1.1
     Host: example.com
     Sec-CH-Example: 1
     Sec-CH-Example-2: 2

     HTTP/1.1 200 OK
     Content-Type: text/html
     Accept-CH: Sec-CH-Example, Sec-CH-Example-2
     Vary: Sec-CH-Example
     Critical-CH: Sec-CH-Example

4.  The ACCEPT_CH HTTP/2 Frame

   While Critical-CH header provides reliability, it requires a retry on
   some requests.  This document additionally introduces the ACCEPT_CH
   HTTP/2 frame as an optimization so the server's Client Hint
   preferences are usually available before the client's first request.

   [[TODO: Alternatively, is it time to revive draft-bishop-httpbis-
   extended-settings?]]

   The ACCEPT_CH frame type is TBD (decimal TBD) and contains one or
   more entries, each consisting of a pair of length-delimited strings:

   +-------------------------------+
   |         Origin-Len (16)       |
   +-------------------------------+-------------------------------+
   |         Origin                                              ...
   +-------------------------------+-------------------------------+
   |         Accept-CH-Len (16)    |
   +-------------------------------+-------------------------------+
   |         Accept-CH-Value                                     ...
   +---------------------------------------------------------------+

   The fields are defined as follows:

   Origin-Len:  An unsigned, 16-bit integer indicating the length, in
      octets, of the Origin field.

   Origin:  A sequence of characters containing the ASCII serialization
      of an origin (Section 6.2 of [RFC6454]) that the sender is
      providing an Accept-CH value for.

   Accept-CH-Len:  An unsigned, 16-bit integer indicating the length, in
      octets, of the Accept-CH-Value field.

   Accept-CH-Value:  A sequence of characters containing the Accept-CH
      value for the corresponding origin.  This value MUST satisfy the

Benjamin                Expires February 28, 2021               [Page 5]
Internet-Draft           Client Hint Reliability             August 2020

      Accept-CH ABNF defined in Section 3.1 of
      [I-D.ietf-httpbis-client-hints].

   HTTP/2 Servers which request Client Hints SHOULD send an ACCEPT_CH
   frame as early as possible.  Connections using TLS [RFC8446] which
   negotiate the Application Layer Protocol Settings (ALPS)
   [I-D.vvv-tls-alps] extension SHOULD include the ACCEPT_CH frame in
   the ALPS value as described in [I-D.vvv-httpbis-alps].  This ensures
   the information is available to the user agent when it makes the
   first request.

   User agents MUST NOT send ACCEPT_CH frames.  Servers which receive an
   ACCEPT_CH frame MUST respond with a connection error (Section 5.4.1
   of [RFC7540]) of type PROTOCOL_ERROR.

   ACCEPT_CH frames always apply to a single connection, never a single
   stream.  The identifier in the ACCEPT_CH frame MUST be zero.  The
   flags field of an ACCEPT_CH field is unused and MUST be zero.  If a
   user agent receives an ACCEPT_CH frame whose stream identifier or
   flags field is non-zero, it MUST respond with a connection error of
   type PROTOCOL_ERROR.

4.1.  Processing ACCEPT_CH Frames

   The user agent remembers the most recently received ACCEPT_CH frame
   for each connection.  When it receives a new ACCEPT_CH frame, either
   in application data or ALPS, it overwrites this value.  As this is an
   optimization, the user agent MAY bound the size and ignore or forget
   entries to reduce resource usage.

   When the user agent makes an HTTP request to a particular origin over
   an HTTP/2 connection, it looks up the origin in the remembered
   ACCEPT_CH, if any.  If it finds a match, it determines additional
   Client Hints to send, incorporating its local policy and user
   preferences.  See Section 2.1 of [I-D.ietf-httpbis-client-hints].

   If there are additional Client Hints, the user agent restarts the
   request with updated headers.  The connection has already been
   established, so this restart does not incur any additional network
   latency.  Note it may result in a different secondary HTTP cache key
   (see Section 4.1 of [RFC7234]) and select a different cached
   response.  If the new cached response does not need revalidation, it
   may not use the connection at all.

   User agents MUST NOT process Client Hint preferences in ACCEPT_CH
   frames corresponding to origins for which the connection is not
   authoritative.  Note the procedure above implicitly satisfies this by
   deferring processing to after the connection has been chosen for a

Benjamin                Expires February 28, 2021               [Page 6]
Internet-Draft           Client Hint Reliability             August 2020

   corresponding request.  Unauthoritative origins and other unmatched
   entries are ignored.

   [[TODO: Some variations on this behavior we could choose instead:

   o  Do new ACCEPT_CH frames override the whole set or implement some
      kind of update?  Overriding the whole set seems simplest and most
      consistent with an EXTENDED_SETTINGS variant.

   o  Should the user agent reject the ACCEPT_CH frame if there are
      unexpected origins in there?  Deferring avoids needing to worry
      about this, and ignoring the unused ones may interact better with
      secondary certs.

   o  Should ACCEPT_CH frames be deferred or just written to the cache
      when received?  Deferred simplifies reasoning about bad origins,
      predictive connections, etc., but means interactions between
      ACCEPT_CH and Accept-CH are more complex (see below).

   o  How should ACCEPT_CH and Accept-CH interact?  The document
      currently proposes unioning them, which is easy.  Accept-CH first
      would work, but unnecessarily ignore newer connection-level
      ACCEPT_CHs.  ACCEPT_CH would not; a stale connection-level
      preference would get stuck.  Whichever is received earlier would
      also work, but requires tracking timestamps if deferred (see
      above).]]

4.2.  Interaction with Critical-CH

   The ACCEPT_CH frame avoids a round-trip, so relying on it over
   Critical-CH would be preferable.  However, this is not always
   possible:

   o  The server may be running older software without support for
      ACCEPT_CH or ALPS.

   o  The server's Accept-CH preferences may change while existing
      connections are open.  Those connections will have outdated
      ACCEPT_CH frames.  While the server could send a new one, the
      frame may not arrive in time for the next request.  Moreover, if
      the HTTP serving frontend is an intermediary like a CDN, it may
      not be proactively notified of origin server changes.

   o  HTTP/2 allows connection reuse across multiple origins
      (Section 9.1.1 of [RFC7540]).  Some origins may not be listed in
      the ACCEPT_CH frame, particularly if the server used a wildcard
      X.509 certificate.

Benjamin                Expires February 28, 2021               [Page 7]
Internet-Draft           Client Hint Reliability             August 2020

   Thus this document defines both mechanisms.  Critical-CH provides
   reliable Client Hint delivery, while the ACCEPT_CH frame avoids the
   retry in most cases.

5.  Security Considerations

   Request header fields may expose sensitive information about the
   user's environment.  Section 4.1 of [I-D.ietf-httpbis-client-hints]
   discusses some of these considerations.  The document augments the
   capabilities of Client Hints, but does not change these
   considerations.  The procedure described in Section 3 does not result
   in the user agent sending request headers it otherwise would not
   have.

   The ACCEPT_CH frame does introduce a new way for HTTP/2 connections
   to make assertions about origins they are not authoritative for, but
   the procedure in Section 4.1 defers processing until after the user
   agent has decided to use the connection for a particular request
   (Section 9.1.1 of [RFC7540]).  The user agent will thus only
   information in an ACCEPT_CH frame if it considers the connection
   authoritative for the origin.

6.  IANA Considerations

   This specification adds an entry to the "HTTP/2 Frame Type" registry
   with the following parameters:

   o  Frame Type: ACCEPT_CH

   o  Code: TBD

   o  Allowed in ALPS: Yes

   o  Reference: [[this document]]

   [[TODO: As of writing, the HTTP/2 Frame Type registry does not
   include an Allowed in ALPS column.  [I-D.vvv-httpbis-alps], as of
   writing, will add it.  This document should be updated as that design
   evolves.]]

7.  References

7.1.  Normative References

   [I-D.ietf-httpbis-client-hints]
              Grigorik, I. and Y. Weiss, "HTTP Client Hints", draft-
              ietf-httpbis-client-hints-15 (work in progress), July
              2020.

Benjamin                Expires February 28, 2021               [Page 8]
Internet-Draft           Client Hint Reliability             August 2020

   [I-D.ietf-httpbis-header-structure]
              Nottingham, M. and P. Kamp, "Structured Field Values for
              HTTP", draft-ietf-httpbis-header-structure-19 (work in
              progress), June 2020.

   [I-D.vvv-httpbis-alps]
              Vasiliev, V., "Using TLS Application-Layer Protocol
              Settings (ALPS) in HTTP", draft-vvv-httpbis-alps-00 (work
              in progress), July 2020.

   [I-D.vvv-tls-alps]
              Vasiliev, V., "TLS Application-Layer Protocol Settings
              Extension", draft-vvv-tls-alps-00 (work in progress), June
              2020.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [RFC6454]  Barth, A., "The Web Origin Concept", RFC 6454,
              DOI 10.17487/RFC6454, December 2011,
              <https://www.rfc-editor.org/info/rfc6454>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <https://www.rfc-editor.org/info/rfc7231>.

   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
              RFC 7234, DOI 10.17487/RFC7234, June 2014,
              <https://www.rfc-editor.org/info/rfc7234>.

   [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>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

Benjamin                Expires February 28, 2021               [Page 9]
Internet-Draft           Client Hint Reliability             August 2020

   [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>.

7.2.  Informative References

   [DEVICE-MEMORY]
              Panicker, S., "Device Memory", n.d.,
              <https://w3c.github.io/device-memory/>.

Acknowledgments

   This document has benefited from contributions and suggestions from
   Ilya Grigorik, Nick Harper, Matt Menke, Aaron Tagliaboschi, Victor
   Vasiliev, Yoav Weiss, and others.

Author's Address

   David Benjamin
   Google LLC

   Email: davidben@google.com

Benjamin                Expires February 28, 2021              [Page 10]