Jeremy Evans

> I want to find a way to move forward here but I have a hard time accepting this interface because even if not initially apparent, it does introduce a...

> I'm only slightly more positive towards provisional responses, but at least it's the actual semantic model that's exposed at the protocol level. I don't agree with your YAGNI assessment....

> > Can you provide a single use case for a provisional response other than early hints? If not, YAGNI (not yet, at least). > > "100 Continue" That's a...

> 100 continue can be used to inform the client that authorisation header was successful and they can continue to upload the request body. I'll give you that that is...

> Just for my own edification I was reading https://blog.cloudflare.com/early-hints/ and felt it summarised some key issues nicely: > > > Standards like Early Hints often don’t get off the...

@ioquatix I'm not sure if you are aware, but it looks like your quote is from February 2021, when they were at the testing/evaluation stage (https://groups.google.com/a/chromium.org/g/blink-dev/c/DAgWIczGtG0/m/gSXvjYn-AwAJ). Your quote does not...

> I was referring to this page: https://chromestatus.com/feature/5207422375297024 Considering the language is the same as the February 2021 blog post, it is likely stale. This was tested in Origin trails...

As @tenderlove, @rafaelfranca, and I are in favor of this, I plan on merging this in a couple days. I think this and `rack.response_finished` (#1802) are the last features planned...

> Are you also happy with adding a spec for an optional `rack.provisional_response` and/or `rack.push_promise`? Not at present.

One difference between `rack.early_hints` and `rack.after_reply`/`rack.response_finished` is that `rack.early_hints`, in addition to being supported by multiple popular web servers, is also already supported by popular frameworks (at least Rails, Roda,...