Add API for Emitting Informational Responses (1xx), for Example 103 Early Hints

[tpeczek]

Is your feature request related to a problem? Please describe.

Chrome developers have expressed intent to remove server push and at the same time pointed to 103 Early Hints as an alternative implementation suggestion. It would be nice to have this capability in ASP.NET Core.

Describe the solution you'd like

A generic approach to provide support for 103 Early Hints could be an API which allows emitting informational responses. Similar to current HTTP Trailers implementation, it could support only HTTP/2 as any modern HTTP/2 clients should ignore unsupported information response, while HTTP/1.x clients can misbehave.

Additional context

As @Tratcher pointed out there might be no way for this API to provide support in all hosting scenario as in case of IIS/Http.Sys it requires work in Http.Sys at the OS level.

[ghost]

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

[p-ob]

With Chrome 103, the Early Hints/HTTP 103 feature was launched: https://developer.chrome.com/blog/new-in-chrome-103/#http103.

Initial performance benefits look quite good: https://blog.cloudflare.com/early-hints-performance/#performance-improvement-with-early-hints

[p-ob]

Firefox will be shipping early hints support in v120: https://groups.google.com/a/mozilla.org/g/dev-platform/c/RBv4SMie9gA/m/pRokpmIwAAAJ.

Safari shipped early hints in v17: https://developer.apple.com/documentation/safari-release-notes/safari-17-release-notes

So now all browsers have shipped or will ship this feature.

[smatsson]

Late to the party here but anyway... I needed support for 104 Upload Resumption Supported in tusdotnet when implementing the Resumable Uploads For Http spec and put together a class that allows me to send 1xx responses. As stated previously in this thread it does not work on http.sys/IIS due to lack of support. It does however work perfectly when running directly on Kestrel or using e.g. nginx as a reverse proxy.

It's currently hard coded to the 104 response but should be easily changed to support 103 Early Hints. https://github.com/tusdotnet/tusdotnet/blob/POC/tus2/Source/tusdotnet/Tus2/InformationalResponseSender.cs#L16

Just wanted to share in case someone has a need for it.

[OnurGumus]

I don't understand how is this marked with affecting-very-few? Can't speak for http push but 103 early hints is a major performance improvement.

[cyraid]

Any progress on this?

[OnurGumus]

@Tratcher could you please re-triage this?

[Tratcher]

RFC 8297 is still experimental. It's unlikely to be implemented in the framework until the spec is finalized.

[cyraid]

The mainline browsers currently support it. Is it policy to implement everything when standards are finished?

[Tratcher]

Yes, because it's hard to change the APIs later if the standard changes.

You're welcome to submit an API proposal to at least get the process started. https://github.com/dotnet/aspnetcore/issues/new?assignees=&labels=api-suggestion&projects=&template=30_api_proposal.md&title=

[OnurGumus]

Hi @Tratcher,
I understand your stance, however current triage label affected-very-few is simply not correct and not relevant RFC being experimental as stated mainline browsers do support it.

[circleupx]

Not implementing this until the RFC is finalized is the correct call, even if the browsers support a version of it.

[Tratcher]

Hi @Tratcher, I understand your stance, however current triage label affected-very-few is simply not correct and not relevant RFC being experimental as stated mainline browsers do support it.

You're talking about the potential long term use, not the current interest. Even if it was supported it would still be a manual process to use and I don't anticipate many people putting in that effort. It's also only an optimization, not new functionality.

+Blocked due to RFC.

[Benjiiim]

Not sure if this is the right thing to do but I'm commenting to show that the "very few" cohort of people interested is growing. :-)

[GerardSmit]

In the meantime, the RFC has been changed from experimental to standard:

RFC 8297, defining 103 Early Hints was published in 2017 by the HTTPBIS WG as
an experimental RFC. In the last couple of years, we have seen uptake and
deployment on client and server sides. In light of that, we propose that RFC
8297 gets promoted to Proposed Standard.

Source: https://datatracker.ietf.org/doc/status-change-early-hints-to-proposed-standard/

So, I think this is not a blocker anymore?

[GerardSmit]

@smatsson
It's currently hard coded to the 104 response but should be easily changed to support 103 Early Hints. tusdotnet/tusdotnet@POC/tus2/Source/tusdotnet/Tus2/InformationalResponseSender.cs#L16

Thanks for the starting point. I've created an extension method for the 103 Early Hints:
https://github.com/WebFormsCore/WebFormsCore/blob/8e9c0d52bb57fd6d682ff43b6ab43554416dc00b/src/WebFormsCore/Utils/KestrelEarlyHints.cs

For the HTTP/2 implementation I had to add .FlushAsync, otherwise the headers wouldn't send until the full response was sent.
In the implementation I've used the full Type.GetType for NativeAOT/trimming support.

I've tested the implementation in ASP.NET Core 2.3 (.NET FX), 8.0 and 9.0 in the browsers Firefox (works with HTTP/1 and HTTP/2) and in Chrome (HTTP/2 only):

With nghttp I've validated the early hints got sent:

$ nghttp https://192.168.178.103:7091/ -nv -H'user-agent: Chrome/134.0.0.0' -H'accept: text/html'

...
[  1.448] recv (stream_id=13) :status: 103
[  1.448] recv (stream_id=13) link: </js/form.min.js>; rel=preload; as=script, </bootstrap.min.css>; rel=preload; as=style, </js/choices.min.js>; rel=preload; as=script
[  1.448] recv HEADERS frame <length=145, flags=0x04, stream_id=13>
          ; END_HEADERS
          (padlen=0)
          ; First response header
[  1.451] recv (stream_id=13) :status: 200
[  1.451] recv (stream_id=13) content-type: text/html; charset=utf-8
...

Where I call the extension, I also validate if the browser supports early hints and the accept-header includes text/html, so custom clients, API's, files and websockets don't get any early hints.