A way to load different resources depending on the browser's support for various HTTP versions

[Atulin]

Current state and proposed change

Currently, resources linked via <link> elements can be loaded conditionally using the same parameters that a CSS media query would take, for example

<link media="prefers-color-scheme: dark" rel="stylesheet" href="/css/dark.css">
<link media="prefers-color-scheme: light" rel="stylesheet" href="/css/light.css">

What this issue proposes is a way to load different resources depending on the browser's support for various HTTP versions, and also support for <script> tags, for example like so:

<!-- If the browser only supports HTTP/1.0 or HTTP/1.1 load whole bundles -->
<link http="1.*" rel="stylesheet" href="/css/full.css">
<script http="1.*" src="/js/main.js"></script>
<!-- If the browser supports HTTP/2 or above, load only necessary files -->
<link http=">=2" rel="stylesheet" href="/css/main.css">
<link http=">=2" rel="stylesheet" href="/css/form.css">
<link http=">=2" rel="stylesheet" href="/css/navbar.css">
<script http=">=2" src="/js/form.js"></script>
<script http=">=2" src="/js/navbar.js"></script>

Reasoning

If the user's browser supports HTTP/2, then serving multiple resource files would provide better experience, especially if only the necessary ones are being referenced.

With only HTTP/1.* support, meanwhile, the better experience would be to serve a single file that contains everything needed for the site to function. If a site is optimized for HTTP/2, serving it to a HTTP/1 browser would provide much worse experience due to the lack of multiplexing support.

It also serves as future-proofing. Perhaps some future HTTP/5 standard will bring a new concept of partial resource streams where only the necessary CSS classes are being requested, which might use its own <res http="5"> tag or something in that vein.

This proposal ensures that no matter the changes, user experience can be progressively enhanced depending on the highest version of HTTP protocol the client supports.

TBD

The exact syntax.

Constraints can be as simple as http="2", but then what about HTTP/3 that also supports muxing? Should the elements be copy-pasted just with a different version?

Thus, some sort of a constraint is needed. The proposal includes 1.* for "major version 1 and any minor version" and >=2 for "any version higher than 2.0", but perhaps constraints like 2-3 or ^2 can be used instead.

Another way would be to allow multiple http parameters, for example

<link http="2" http="3" rel="stylesheet" href="/css/main.css">

or delimited values, be it by space or by a comma:

<link http="2 3" rel="stylesheet" href="/css/main.css">
<link http="2,3" rel="stylesheet" href="/css/main.css">

Another thing to be discussed about syntax is the attribute itself. The proposal above uses http, but it could very well be protocol, http-version, or it can even be merged into the media attribute. The latter, however, would probably also require adding support for all media parameters on <script> tags, however, which is besides the scope of this issue.

[annevk]

Most browsers will soon support H/3. The real problem is not browser support, but middleware, and while the browser is somewhat aware of what ends up being negotiated, it's unclear we want to expose that to servers.

[Atulin]

The real problem is not browser support, but middleware

If by "middleware" you mean reverse proxies and servers like Nginx, Apache, Caddy, etc. then I fail to see an issue there. When the server doesn't support HTTP/2, for example, the browser that supports even HTTP/3 can still request resources via HTTP/1.1. The request can gracefully fall back to an older standard.

Problem lies with the browser support. Since it will request any resources it encounters, no matter the HTTP version it supports. Sure, you can figure it out from the headers sent by the browser server-side, but it won't allow you to make a choice to send an entire bundle for HTTP/1 or separate files for HTTP/2, since the browser requests one specific file.

Most browsers will soon support H/3

Internet Explorer doesn't even support HTTP/2 and won't. HTTP/3 is supported somewhat in the most recent version of Safari and no other browser. Some other desktop browsers have support under a flag, sure, but no mobile browser does. And what of HTTP/4 or any future versions?

The example of HTTP/5 in the proposal might be a little bit out there, but it shows that it's also a matter of future-proofing against any future HTTP standards.

and while the browser is somewhat aware of what ends up being negotiated

I might be misunderstanding what you mean here, but neither the browser nor the server needs any information about the connection here. The browser just needs to be aware of what is the highest HTTP version it supports, and only fetch resources accordingly.

it's unclear we want to expose that to servers.

Again, apologies if I misunderstand anything, but isn't the browser HTTP version and user agent exposed to the server?

[abhijitbavdhankar]

SOLUTION //////////////////////////

CHECK HTTP VERSION 1.0/2.0/3.0 DYNAMICALLY BEFORE LANDING HTML PAGE ON CHROME BROWSER.

`<HTML HTTP=

1. HTTP/1.0
2. HTTP/1.1
3. HTTP/2.0
4. HTTP/3.0

/>`

[Atulin]

I have absolutely no clue what your comment proposes