Contact emails [email protected]
Specification https://www.w3.org/TR/webtransport/#dom-webtransportoptions-headers Summary Adds support for passing custom HTTP request headers via WebTransportOptions and inspecting server response headers through the WebTransport instance. This allows web applications to supply metadata, authentication tokens, and custom parameters during the initial CONNECT handshake and access server-provided headers once the connection is established. Blink component Blink>Network>WebTransport Web Feature ID webtransport Motivation The WebTransport constructor requires support for custom HTTP request headers to address several technical limitations in authentication, routing, and capability negotiation. Without custom headers, developers must pass authentication tokens in URL query strings, which exposes credentials in server logs and telemetry, or authenticate over an initial data stream, which adds an additional round trip before the connection is usable. Furthermore, API gateways and reverse proxies typically inspect HTTP headers at the CONNECT layer. Without custom headers, these intermediaries cannot authorize or route WebTransport sessions via existing pipelines, forcing servers to accept connections before verifying credentials. Finally, applications often need to negotiate capabilities, such as supported video codecs, during connection setup. Providing custom request headers in WebTransportOptions and a readable responseHeaders property on the WebTransport instance allows clients and servers to authenticate, route, and negotiate capabilities during the initial handshake. This eliminates the need for custom stream-level initialization protocols. Initial public proposal No information provided TAG review This is a small incremental addition to an existing feature which is already standardized. TAG review status Not applicable Goals for experimentation None Risks Interoperability and Compatibility Interoperability and compatibility risks are low. This is a purely additive API addition to WebTransportOptions and the WebTransport instance, posing no compatibility risk to existing web content. Interoperability risk is low as the feature was designed, discussed, and formally agreed upon within the W3C WebTransport Working Group (Issue #263, merged in PR #713) with active participation from Mozilla, Apple, and Google engineers. Gecko: No signal No official position, but Firefox developers were involved in standardisation of the feature. WebKit: In development (https://github.com/WebKit/WebKit/pull/61874) Not an official position, but WebKit has landed a change implementing the feature without flag guarding. Web developers: Positive (https://github.com/w3c/webtransport/issues/263) There was a lot of interest from developers on the original issue. There are no known negative opinions from developers. Other signals: Consensus to add this feature was achieved at the W3C TPAC conference in November 2025: https://www.w3.org/wiki/WebTransport/Meetings2023#2025_W3C_TPAC_Meeting_-_Kobe,_Japan Ergonomics Ergonomics risks are minimal. The feature integrates cleanly with existing web platform header paradigms (HeadersInit / Headers) and introduces no synchronous blocking or thread-affinity constraints. Request headers are supplied at constructor initialization and response headers become accessible asynchronously upon connection establishment via wt.ready, fitting naturally into existing WebTransport asynchronous workflows. Activation Activation risks are low. Developers can adopt the feature immediately using standard feature detection on the constructor options and prototype properties ('responseHeaders' in WebTransport.prototype). Because server frameworks, reverse proxies, and API gateways already support reading and writing standard HTTP CONNECT headers, server-side activation is straightforward, while clients targeting older browsers can temporarily retain fallback query parameters or application-layer handshakes. Security During the feature's design in the W3C WebTransport Working Group, participants evaluated whether sending developer-specified headers on cross-origin CONNECT requests posed cross-origin risks or necessitated a mandatory CORS preflight. The working group concluded that explicit server-level opt-in via HTTP/3 settings (SETTINGS_ENABLE_WEBTRANSPORT) protects non-WebTransport servers, avoiding the need for high-latency CORS preflights. To prevent header injection and user-agent spoofing, custom headers are filtered against Fetch specification forbidden header names (such as Host, Origin, and Sec-*) and forbidden request-body headers. WebTransport requests do not have credentials (cookies, HTTP auth, or client certificates) attached, helping to mitigate risks of attacks on servers that confuse the WebTransport handshake for an ordinary request. WebView application risks Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications? Low. This is a purely additive API adding custom request headers in WebTransportOptions and responseHeaders on the WebTransport instance, introducing no breaking changes or regressions for existing WebView applications. Debuggability Debuggability is supported via Chrome DevTools. Custom request headers passed to the WebTransport constructor and the server's returned response headers are surfaced for inspection in the DevTools Network panel alongside other WebTransport session metadata and stream events, matching existing network inspection tooling. Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)? No All Blink platforms supported. Implemented in cross-platform code. Is this feature fully tested by web-platform-tests? Yes https://wpt.fyi/results/webtransport/headers.https.any.html?label=experimental&label=master&aligned Flag name on about://flags enable-experimental-web-platform-features Finch feature name WebTransportHeaders Rollout plan Will ship enabled for all users Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/551850821 Availability expectation Feature is expected to be available across major browsers as part of the W3C WebTransport specification. Adoption expectation Feature is expected to be widely adopted for bearer authentication within 12 months of reaching Web Platform baseline. Adoption for use cases such as media metadata is likely to be slower. Adoption plan Adoption is expected to happen organically given the existing demand for this feature. Non-OSS dependencies Does the feature depend on any code or APIs outside the Chromium open source repository and its open-source dependencies to function? No. Estimated milestones Shipping on desktop 155 DevTrial on desktop 153 Shipping on Android 155 DevTrial on Android 153 Shipping on WebView 155 Anticipated spec changes Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, changing to naming or structure of the API in a non-backward-compatible way). None. The specification changes have been finalized and merged into the W3C WebTransport specification via PR #713. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5194104408506368?gate=5770753428553728 This intent message was generated by Chrome Platform Status. -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6a98324a.b5ef4c6f.265fb1.01fb.GAE%40google.com.
