1 of 8

Alt-Svc-bis Candidates

HTTP WG Interim

June 2021

​

Erik Nygren, <erik+ietf@nygren.org>

Mike Bishop <mbishop@evequefou.be>

2 of 8

Intro

  • RFC7838 published in April 2016
    • “This 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.”
  • Primary mechanism for upgrade to HTTP/3 (at least prior to HTTPS RRs)
  • For the WG:
    • Which of these scope items are of interest?
    • Which direction should we take on some key design points?
    • What are preferred ways to work through design issues?

​

3 of 8

Why a “-bis” now?

  • Clarifications (incorporate errata, “dont-be-clear”[1], etc)
  • Fix issues identified with implementation experience
    • Some major implementations can’t/won’t implement as-specified
  • Align and update relative to related proposed standards:
    • QUIC and HTTP/3, ORIGIN frame (RFC 8336), SVCB/HTTPS RR
  • New features?
    • Fix/replace Alt-Used
    • Negotiation (Accept-Alt-Svc)
    • Synchronous Alt-Svc redirect (new 3xx code)
    • Path-scoped Alt-Svc (relies on Negotiation and Synchronous to be useful

​

[1] draft-pardue-httpbis-dont-be-clear-00.txt

4 of 8

General areas to fix/address

  • Alt-Svc max lifetime and hijacking concerns
  • Clients unable to implement “persist”
  • ALPN handling ambiguity
    • Proposal: incorporate text from HTTPS/SVCB RR
  • Alignment with HTTPS/SVCB RR and handling of ECH
    • Some text will be included in -06 of draft-ietf-dnsop-svcb-https-06, but it is non-prescriptive
    • HTTPS/SVCB RR draft nearing IETF LC: final review and feedback encouraged!

​

​

5 of 8

Fixing Alt-Used

  • Problems / Opportunities:
    • Not consistently implemented by clients, resulting in problems for servers
    • Does not convey information from Alt-Svc record used
    • Unclear interaction with SVCB/HTTPS RR

​

  • Challenge: balance privacy / anti-tracking, ability to implement, and usefulness for servers

​

  • Many different design options...

6 of 8

Decision needed: QUIC ALTSVC frame

Options:

1. Define a QUIC ALTSVC frame

2. Deprecate HTTP/2 ALTSVC frame

  • Only the Alt-Svc header would remain
  • Simplifies!

​

​

7 of 8

New features?

  • Accept-Alt-Svc to enable extensions requiring client opt-in
  • New 3xx redirect for synchronous Alt-Used
  • Path-scoped Alt-Svc (as a separate draft?)
  • Illustration of potential:

To www.example.com:

​

GET /foo/bar.mp4

Accept-Alt-Svc: sync, path, altused2

Host: www.example.com

​

HTTP/1.1 3xx Alternative Server

Alt-Svc: h2="foo.example.net:443"; ma=7200; sync; path=”/foo/”

​

To foo.example.net:

GET /foo/bar.mp4

Accept-Alt-Svc: path, altused2

Host: www.example.com

Alt-Used-v2: alt-svc;h2="foo.example.net:443";path

​

​

8 of 8

Where next?

​