Spec Support for 103 Early Hints and other informational response types

[Ramblurr]

Currently, the Ring spec focuses on final response statuses (200–599) and doesn’t explicitly cover informational responses (1xx), such as 103 Early Hints RFC 8297, MDN.

This issue is to open a discussion on how (or whether) the Ring spec should accommodate informational response types, particularly for use cases like Early Hints that can improve performance in certain server setups.

Of all the 1xx status codes, I think only 103 Early Hints is worth considering for standardization in ring.

Jetty has support for this via the CompletableFuture<Void> writeInterim(int status, HttpFields headers) method

[Ramblurr]

I'd add that I am particularly interested in a solution for synchronous handlers. I can easily imagine a (respond..) based solution for async handlers, but in this new virtual thread world, I think synchronous handlers are much easier to use.

[weavejester]

Thanks for opening the discussion on this. To manage expectations, this may take a while to find its way into the spec, if at all. Spec changes are something that needs to be carefully considered.

As you point out, a respond based solution is fairly obvious: we just call respond multiple times. This means it's at least possible that the synchronous version could be implemented via middleware for any adapter that supports the asynchronous version.

As for what the synchronous version might look like, perhaps we add a key that takes a deref-able promise or future.

(defn handler [request]
  {:status 103
   :headers {"Link" "</style.css>; rel=preload; as=style"}
   :ring.response/next
   (future {:status 200
            :headers {...}
            :body ...})})

My suggestion on the way forward is that the asynchronous version be developed first, followed by experimental (alpha) middleware that implements a synchronous solution. This means that the adapters don't have to care about the implementation of the synchronous solution, and we can iterate more quickly.

[Ramblurr]

Thanks for the reply.

I like the look of your proposed synchronous version.

My suggestion on the way forward is that the asynchronous version be developed first, followed by experimental (alpha) middleware that implements a synchronous solution.

Should this happen as a PR to this repo?