WebHost doesn't detect ASPNETCORE_HTTP_PORTS

[tmds]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

The .NET images for .NET 8 changed from using ASPNETCORE_URLS to using ASPNETCORE_HTTP_PORTS.

Older applications using the WebHost API don't seem to pick up the new environment variable.

Expected Behavior

Applications using the WebHost API should use the new environment variables.

Or this should be documented as a breaking change.

Steps To Reproduce

using Microsoft.AspNetCore ;

public class Program
{
    public static void Main(string[] args)
    {
        CreateWebHostBuilder(args).Build().Run();
    }

    public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
        WebHost.CreateDefaultBuilder(args)
            .UseStartup<Startup>();
}

class Startup
{
    public void Configure()
    { }
}

$ ASPNETCORE_HTTP_PORTS=8080 dotnet run --no-launch-profile
Hosting environment: Production
Content root path: /tmp/web2
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

As shown in the output, the application binds to port 5000 instead of port 8080 as set by the envvar.

Exceptions (if any)

No response

.NET Version

8.0.100-rc.1.23455.1

Anything else?

No response

[tmds]

cc @richlander @Tratcher

[Tratcher]

Correct, the legacy WebHost APIs do not support new features like ASPNETCORE_HTTP_PORTS.

[tmds]

Correct, the legacy WebHost APIs do not support new features like ASPNETCORE_HTTP_PORTS.

Probably the old API is still being used since it's still functional and not deprecated.

Since container images are now using the new envvar, do you think it's worth calling this out as part of the breaking changes? Perhaps include this in https://learn.microsoft.com/en-us/dotnet/core/compatibility/containers/8.0/aspnet-port?

cc @mthalman

[mthalman]

Correct, the legacy WebHost APIs do not support new features like ASPNETCORE_HTTP_PORTS.

Why not?

[tmds]

@Tratcher what can we do for .NET 8 GA?

[Tratcher]

Correct, the legacy WebHost APIs do not support new features like ASPNETCORE_HTTP_PORTS.

Why not?

Because it's twice as much work to implement new features in both places and in most cases, WebHost doesn't need the new features. We'd only consider this if it was going to cause a significant interop issue?

what can we do for .NET 8 GA?

Not much, .NET 8 is locking down and only taking servicing level fixes at this point. @adityamandaleeka?

[tmds]

Users reading https://learn.microsoft.com/en-us/dotnet/core/compatibility/containers/8.0/aspnet-port will assume their ASP.NET app will change to port 8080 when using Microsoft base images.

The WebHost based ASP.NET apps will instead be changing to port 5000. It would be good to cover this in the breaking change doc.

The WebHost based apps can either migrate to the new APIs or set ASPNETCORE_URLS to http://*:8080.

[amcasey]

Sorry, I'm getting a little mixed up because I think there's some implicit context in the problem discussion that I'm missing. Do I understand correctly that the dotnet container images were updated for 8.0 to start configuring aspnetcore via ASPNETCORE_HTTP_PORTS, rather than ASPNETCORE_URLS, and that this won't work for code using the older WebHost APIs? If so, which breaking change doc is being referenced? The one for the container images?

What would happen if the container image(s) set both environment variables? I'm assuming the newer one would win in any code path that supports both?

[tmds]

What would happen if the container image(s) set both environment variables? I'm assuming the newer one would win in any code path that supports both?

The newer envar was introduced to be more user-friendly.

When both are set, the new envvar gets ignored for backwards compatibility.

this won't work for code using the older WebHost APIs?

Yes. They don't know about the envvar that is set in the 8.0 container images.

It causes them to bind to port 5000.

which breaking change doc is being referenced?

There is no breaking change doc about the WebHost port yet.

There is one about the port changing from 80 to 8080: https://learn.microsoft.com/en-us/dotnet/core/compatibility/containers/8.0/aspnet-port.

[amcasey]

When both are set, the new envvar gets ignored for backwards compatibility.

What's the back compat issue? Consumers who were setting ASPNETCORE_HTTP_PORTS before aspnetcore started consuming it?

Edit: To be explicit, you're correct, it's just not immediately obvious to me why it was done that way.

[amcasey]

Do you remember why URLS beats HTTP_PORTS, @Tratcher? It looks like it was a pretty explicit decision.

[tmds]

The reason is backwards compatibility. If user was setting ASPNETCORE_URLS (in a derived image, a Kubernetes spec, ...) then the 8.0 image will still respect that setting.

[amcasey]

If I understand correctly, the scenario of concern is when the user has specified ASPNETCORE_URLS and the container tooling has specified ASPNETCORE_HTTP_PORTS. When that occurs, we want the user's setting to win. Is that right?

If so, how did the container tooling formerly handle the case where the user had specified ASPNETCORE_URLS? I'm guessing the user's setting was applied last and won?

And the reason the container tooling prefers not to continue using ASPNETCORE_URLS is that the user might begin using ASPNETCORE_HTTP_PORTS, which would then be clobbered by the tooling's setting?