Skip to content
This repository was archived by the owner on Jun 20, 2019. It is now read-only.

Kestrel config binder should understand * and localhost #136

Closed
muratg opened this issue Aug 18, 2017 · 13 comments
Closed

Kestrel config binder should understand * and localhost #136

muratg opened this issue Aug 18, 2017 · 13 comments
Labels

Comments

@muratg
Copy link
Contributor

muratg commented Aug 18, 2017

From @danroth27 on June 1, 2017 16:28

From @Tratcher on April 27, 2017 17:0

The templates are going to enable SSL via config in dev and production. They need to set up the rest of the endpoints when they do this. aspnet/MetaPackages#44 added the ability to bind to IPs and ports, but that makes for a poor user experience. In dev the templates want localhost, but will have to specify 127.0.0.1 (and ::1) if they want IPv6 support. In production they'll need to specify a public IP (0.0.0.0 and ::0).

Config should allow localhost that binds to 127.0.0.1 and ::1, and * that binds to 0.0.0.0 and ::0, using the same logic that kestrel applies to UseUrls values. Even better, implement this in Kestrel with a Listen that takes the string ip/host so you don't have to duplicate all of the logic.

Copied from original issue: aspnet/MetaPackages#73

Copied from original issue: aspnet/KestrelHttpServer#1879

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

From @danroth27 on June 1, 2017 16:28

From @Tratcher on April 27, 2017 17:14

@danroth27

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

From @danroth27 on June 1, 2017 16:28

@muratg @DamianEdwards @Eilon We chatted about this one and we think we need to get this into preview1. @muratg please assign.

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

From @danroth27 on June 1, 2017 16:28

We chatted even more and the fix is more complicated than we want to take right now. We'll have to tell folks to browse to localhost.

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

From @danroth27 on June 1, 2017 16:28

From @muratg on May 25, 2017 22:14

Assigning to @CesarBS for post preview2.

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

From @danroth27 on June 1, 2017 16:28

@glennc This issue is also the first in a series of issue that prevents enabling docker for out templates that use authentication.

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

From @danroth27 on June 1, 2017 16:28

From @Tratcher on June 1, 2017 16:15

Note this code is moving to Kestrel. aspnet/KestrelHttpServer#1878

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

From @pflannery on July 18, 2017 16:13

@glennc This issue is also the first in a series of issue that prevents enabling docker for out templates that use authentication.

I'm also seeing a port forwarding issue with the "dotnet new web" template and the current docker image "microsoft/dotnet"

I also see the warning with "Unable to bind to http://localhost:5000 on the IPv6 loopback interface: (Error -99 EADDRNOTAVAIL address not available)".

root@24cf43adf652:~# dotnet new web -o www
Content generation time: 74.6508 ms
The template "ASP.NET Core Empty" created successfully.
root@24cf43adf652:~# cd www/
root@24cf43adf652:~/www# dotnet restore
  Restoring packages for /root/www/www.csproj...
  Generating MSBuild file /root/www/obj/www.csproj.nuget.g.props.
  Generating MSBuild file /root/www/obj/www.csproj.nuget.g.targets.
  Writing lock file to disk. Path: /root/www/obj/project.assets.json
  Restore completed in 680.72 ms for /root/www/www.csproj.

  NuGet Config files used:
      /root/.nuget/NuGet/NuGet.Config

  Feeds used:
      https://api.nuget.org/v3/index.json
root@24cf43adf652:~/www# dotnet run
warn: Microsoft.AspNetCore.Server.Kestrel[0]
      Unable to bind to http://localhost:5000 on the IPv6 loopback interface: (Error -99 EADDRNOTAVAIL address not available)
Hosting environment: Production
Content root path: /root/www
Now listening on: http://localhost:5000
Application started. Press Ctrl+C to shut down.

My current solution is amending the Program.cs file to include .UseUrls("http://*:5000") which fixes port forwarding and removes the warning

public static void Main(string[] args)
{
    var host = new WebHostBuilder()
        .UseUrls("http://*:5000")
        .UseKestrel()
        .UseContentRoot(Directory.GetCurrentDirectory())
        .UseIISIntegration()
        .UseStartup<Startup>()
        .Build();

    host.Run();
}

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

From @natemcmaster on July 18, 2017 17:1

@pflannery try using the microsoft/aspnetcore image instead. This image is designed to host web apps, and contains settings, such as ASPNETCORE_URLS, that solve this issue for you.

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

From @pflannery on July 18, 2017 17:53

@natemcmaster Thanks. I just tried that and get blocked when running dotnet --info

root@29095298643c:~# dotnet --info
Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
  http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409

Following that link didnt seem to solve my issue so I tried to run through the linux debian sdk commands here https://www.microsoft.com/net/core#linuxdebian but still same problem.

Following https://www.microsoft.com/net/core#dockercmd gets me as far as the EADDRNOTAVAIL error I reported above.

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

From @natemcmaster on July 18, 2017 17:56

@pflannery If you need to build an app in the container, use microsoft/aspnetcore-build. Let's continue this discussion here https://github.com/aspnet/aspnet-docker as this is separate from the intent of this issue.

@halter73
Copy link
Member

@muratg I don't think this issue should be moved here. In triage we discussed whether ANCM could pick one of 127.0.0.1:{port} or [::1]:{port} to bind to instead of localhost:{port}. This could potentially lead to less warnings, confusion and even possibly bugs.

The issue that was moved here seems to be discussing supporting localhost with Kestrel new Listen() methods. This is something we don't want to do because it's a bit of a leaky abstraction.

@muratg
Copy link
Contributor Author

muratg commented Aug 18, 2017

@halter73 Could you file one that recommends that then? Closing this one.

@muratg muratg closed this as completed Aug 18, 2017
@halter73
Copy link
Member

#137

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants