Add HTTP 103 Early Hints support

[otbutz]

RFC 8297 is only a draft, but is now supported by Chrome 103:

https://caniuse.com/mdn-http_status_103

and Mozilla also intends to support it:

https://bugzilla.mozilla.org/show_bug.cgi?id=1407355

Apache already implements it: https://httpd.apache.org/docs/2.4/howto/http2.html#earlyhints

It would be nice if caddy would add (experimental) support for it. Following the RFC recommendations, this should only be added for HTTP/2 and HTTP/3:

Therefore, a server might refrain from sending 103 (Early Hints) responses over HTTP/1.1 unless the client is known to handle informational responses correctly.

[otbutz]

The very first step would be to make sure that caddy processes HTTP 103 properly while acting as a reverse proxy. That may already be the case.

[francislavoie]

@dunglas has been working on adding support for early hints to the Go stdlib, I'm sure he'll follow up soon to make sure Caddy supports it sufficiently.

[dunglas]

Indeed it's on my todo list. We'll have to wait for Go 1.19 first.

[bt90]

@dunglas does this also add support for HTTP3 based connections?

[dunglas]

@bt90 yes! I also patched the HTTP/3 library: quic-go/quic-go#3047

[pc-erin]

Is there any documentation on how use this feature now that it's implemented?

If we do respond 103 does that send hints but still maintain the connection for the main response?

[mholt]

@pc-erin HTTP 103 is for applications to emit. The only "application" Caddy really offers (at least, built-in) is the static file server; I have been considering building a feature that will parse HTML and send 103 responses accordingly (like for CSS, JS, and image resources), but maybe at a future date.

For now, this relays 103s from proxy backends down to the client.

What's your use case?

[bt90]

Using it in a reverse proxy scenario might also be neat. Add a matcher for the main page and tell the clients to also load files X, Y and Z.

[pc-erin]

I was working on a PHP application (which apparently doesn't support 103) and also buffers the full output, so no streaming the html head down first.

To mitigate this I thought it would be convenient to manually put some 103 hints in path handlers so that browsers could start downloading resources while PHP is building the response.

Something like:

{
  respond 103 {
    hint </css/common-styles.css>; rel=preload; as=style; nopush
    hint </js/common-scripts.js>; rel=preload; as=script; nopush
  }

  handle /page1 {
    respond 103 {
      hint </css/page1-styles.css>; rel=preload; as=style; nopush
      hint </js/page1-scripts.js>; rel=preload; as=script; nopush
    }
  }

  php_fastcgi...
}

[mholt]

Proposal opened at #5005

[mholt]

Proposal implemented in #5006 -- @pc-erin and @bt90 you may want to try it out!

[xfalcox]

Hey @mholt,

When using 103 hints in a more conventional way, with caddy being a reverse proxy to an application that sends those responses, one useful feature is caching the 103 responses from previous requests and replying with those learned cached behaviors in newer requests. At the moment, AFAIK only Cloudflare implements this, but it can be very useful for Caddy to have something like this.

Example:

1. User requests /index
2. Caddy receives the request and proxies it to underlying app
3. Underlying app runs some fast logic and responds with 103. This takes 100ms
4. Underlying finishes building the full response. This takes 300ms

If Caddy "learns" that requests to /index get a certain 103 response, it could reply with that ASAP on step 2, making this response happen 100ms earlier, which will result in a faster browsing experience if the resources in 103 are necessary for website interactivity.

Cloudflare goes one step further, and even "learns" to 103 subsequent requests from Link headers in plain 200 responses:

Now: Turning 200 OK Link: headers into 103 Early Hints

To avoid requiring origins to emit 103 responses from their origins directly, we settled on an approach that takes advantage of something many customers already used to indicate which assets an HTML page depends on, the Link: response header.

1. When Cloudflare gets a response from the origin, we will parse it for Link headers with preload or preconnect rel types. These rel types indicate to the browser that the asset should be loaded as soon as possible (preload), or that a connection should be established to the specified origin but no bytes should be transferred (preconnect).

2. Cloudflare takes these headers and caches them at our edge, ready to be served as a 103 Early Hints payload.

3. When subsequent requests come for that asset, we immediately send the browser the cached Early Hints response
   while proxying the request to the origin server to generate the full response.

4. Cloudflare then proxies the full response from origin to the browser when it’s available.

5. When the full response is available, it will contain Link headers (that’s how we started this whole story). We will compare the Link headers in the 200 response with the cached version to make sure that they are the most up to date. If they have changed since they’ve been cached, we will automatically purge the out-of-date Early Hints and re-cache the new ones.

Curious about your opinions on this @mholt.

[mholt]

@xfalcox We could do that... would require a new directive to enable it, I think. Probably best for someone to implement it as a separate plugin for now and see how popular and useful it is!