Enable http/3 from docker containers

[mrgleba]

Is there an existing issue for this?

• I have searched the existing issues

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

Right now it's very hard to run aspnet core http/3 from within a docker container.

• the default docker images are missing libmsquic
• there is no easy way to specify a true external port for alt-svc header

Describe the solution you'd like

The docker image for aspnet core should include the current libmsquic

There should be a configuration option for an external port in the alt-svc header.

Additional context

No response

[Tratcher]

there is no easy way to specify a true external port for alt-svc header

You can provide your own alt-svc header like this:

app.Use((context, next) =>
{
    context.Response.Headers.AltSvc = "h3=\":443\"";
    return next(context);
});

the default docker images are missing libmsquic

Getting libmsquic into the images is a good idea. @ManickaP?

[mrgleba]

I've tried that but so far with no success.

As I understand the port supplied in the alt-svc is a UDP port? Is that correct?
Right now there is no way to specify the UDP port number - it has to be the same as TCP port for HTTPS HTTP/1.1 & HTTP/2 (it's taken from the IPEndPint.Port) ?
Using HTTP/3 in docker would now require 3 port redirections:

• TCP 80 (HTTP)
• TCP 443 (HTTPS)
• UDP from alt-svc (QUIC/HTTP3)

Is there any way to find out if libmsquic was successfuly found? I'm trying to diagnose my problem and this seems to be the case despite the library being installed manually (in mcr.microsoft.com/dotnet/aspnet:7.0 image)

[Tratcher]

As I understand the port supplied in the alt-svc is a UDP port? Is that correct?
Right now there is no way to specify the UDP port number - it has to be the same as TCP port for HTTPS HTTP/1.1 & HTTP/2 (it's taken from the IPEndPint.Port) ?

Correct.

Is there any way to find out if libmsquic was successfully found?

Try QuicListener.IsSupported

[ghost]

Hi @mrgleba. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[adityamandaleeka]

Related: #37311

[mrgleba]

I've finally managed to run http3 from the container.
I needed to change the port inside the container from 8443 to 443 (as it didn't work on that port, even with manual alt-svc).
I needed to use setcap 'cap_net_bind_service=+ep' /usr/share/dotnet/dotnet inside the container for dotnet to be able to bind to lower ports (we don't use root inside the container).
I needed to opt-in to preview featuser in .csproj

Using QuicListener.IsSupported requires opting-in to preview features. Is http/3 still in preview in 7.0?

[Tratcher]

Using QuicListener.IsSupported requires opting-in to preview features. Is http/3 still in preview in 7.0?

HTTP/3 is not in preview, but the lower level QUIC APIs are.

[MychellSantos]

I've finally managed to run http3 from the container. I needed to change the port inside the container from 8443 to 443 (as it didn't work on that port, even with manual alt-svc). I needed to use setcap 'cap_net_bind_service=+ep' /usr/share/dotnet/dotnet inside the container for dotnet to be able to bind to lower ports (we don't use root inside the container). I needed to opt-in to preview featuser in .csproj

Using QuicListener.IsSupported requires opting-in to preview features. Is http/3 still in preview in 7.0?
I'm trying to run inside a container but the connection is closed.
How was it possible to execute?

was it possible to perform overwrite with a self-signed certificate?

context;
.net 7
libmsquic 2.*
certificate self-sigend
config:

{
  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://+:443",
        "Protocols": "Http3"
      }
    }
 }

[Tratcher]

Browsers are very strict about self-signed certs and HTTP/3. See #41762

[MychellSantos]

I was in doubt if http3 needs a certificate inside the application in the container, because my certificates are in the proxy/nginx.
my application doesn't even know if it has a certificate or not.

[adityamandaleeka]

Marking this as answered since the discussion seems to have moved to dotnet/runtime#41762

[ManickaP]

Getting libmsquic into the images is a good idea. @ManickaP?

We have an issue for that: dotnet/dotnet-docker#4385.

Our previous experience with adding dependencies into official docker images led to push back due to the increased size, so we need more people caring about this scenario before we attempt to do this. Please upvote the issue if it's important for you!

[ghost]

This issue has been resolved and has not had any activity for 1 day. It will be closed for housekeeping purposes.

See our Issue Management Policies for more information.

[mattchidley]

Building on what @mrgleba has posted, I just want to confirm that this worked for me:

• libmsquic needs to be set and held at 1.9*
• the webserver running inside the container needs to be running on 443
• the Dockerfile needs to expose both TCP and UDP for the ports (EXPOSE 443/udp 443/tcp)
• the Docker run command needs to forward both TCP and UDP traffic to the exposed ports (publish --port 443:443/udp --port 443:443/tcp

These things did not work:

• if the webserver is running on a different port than 443, and you set the alt-svc header to be 443, HTTP/3 connections can be established but the browser will not negotiate connections using the h3 protocol (I don't know why).
• I did not need to setcap 'cap_net_bind_service=+ep' /usr/share/dotnet/dotnet in order to bind lower ports, but that could just be based on the privilege I'm running