8000 Fix support for non-localhost endpoint targets by danegsta · Pull Request #9977 · dotnet/aspire · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Fix support for non-localhost endpoint targets #9977

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

danegsta
Copy link
Member
@danegsta danegsta commented Jun 20, 2025

Description

TargetHost wasn't being plumbed through properly to all endpoint/service resources, which was preventing us from binding properly to addresses other than localhost. This ensures that containers, executables, and service proxies bind to the configured address for an endpoint. For addresses bound to 0.0.0.0 or [::] (all network interfaces), the current machine hostname is used as the allocated endpoint address. For Asp.NET addresses using +, *, etc. to indicate all interfaces, we default to IPv4 0.0.0.0 unless it isn't supported on any network interfaces (in which case we'll try to bind to [::]).

Effectively this means:

TargetHost = "localhost" => service listens on localhost, URLs use localhost

TargetHost = "0.0.0.0" => service listens on all IPv4 interfaces, URLs use hostname

TargetHost = "[::]" => service listens on all IPv6 interfaces, URLs use hostname

ASPNETCORE_URLS="https://+:" => service listens on all IPv4 interfaces if supported, all IPv6 interfaces otherwise; URLs use the hostname

Fixes #9853
Fixes #9085

Checklist

  • Is this feature complete?
    • Yes. Ready to ship.
    • No. Follow-up changes expected.
  • Are you including unit tests for the changes and scenario tests if relevant?
    • Yes
    • No
  • Did you add public API?
    • Yes
      • If yes, did you have an API Review for it?
        • Yes
        • No
      • Did you add <remarks /> and <code /> elements on your triple slash comments?
        • Yes
        • No
    • No
  • Does the change make any security assumptions or guarantees?
    • Yes
      • If yes, have you done a threat model and had a security review?
        • Yes
        • No
    • No
  • Does the change require an update in our Aspire docs?

@github-actions github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Jun 20, 2025
Copy link
Contributor
@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR fixes issues with endpoint binding by ensuring that the TargetHost value is correctly used instead of defaulting to "localhost".

  • Removed conditional logic that forced proxied endpoints to use "localhost" in ProjectResourceBuilderExtensions.
  • Updated DcpExecutor to correctly use TargetHost for service endpoints and container port specifications.

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
src/Aspire.Hosting/ProjectResourceBuilderExtensions.cs Removed redundant logic condition and updated URL construction to use TargetHost directly.
src/Aspire.Hosting/Dcp/DcpExecutor.cs Replaced hardcoded "localhost" with TargetHost for allocated endpoints and updated service producer annotations.
Comments suppressed due to low confidence (1)

src/Aspire.Hosting/ProjectResourceBuilderExtensions.cs:759

  • The comment at this line is now outdated since the logic for forcing 'localhost' has been removed. Consider updating or removing the comment to avoid confusion.
                    processedHttpsPort = true;

@danegsta
Copy link
Member Author
danegsta commented Jun 21, 2025

Looks like there’s still some issue with + and other Asp.NET alternatives to 0.0.0.0 in launch settings; I’ll figure out where they’re making it into the endpoints un-normalized.

@danegsta danegsta requested a review from mitchdenny as a code owner June 23, 2025 19:27
Copy link
Member
@karolz-ms karolz-ms left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just a couple things to consider, not blocking the merge IMO

Copy link
Member
@davidfowl davidfowl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure about this change yet. I've love to know what happens when dns is broken?

@dotnet-policy-service dotnet-policy-service bot added needs-author-action An issue or pull request that requires more info or actions from the author. and removed needs-author-action An issue or pull request that requires more info or actions from the author. labels Jun 23, 2025
@danegsta
Copy link
Member Author

Not sure about this change yet. I've love to know what happens when dns is broken?

Current design falls back to "localhost" if we can't resolve a hostname for the machine. Looking at the runtime, it seems that at least in some situations, Dns.GetHostName() falls back to Environment.MachineName, which is suitable for local network addressing and doesn't require any DNS resolution to retrieve.

@danegsta
Copy link
Member Author

The biggest design choice is that I'm actively selecting IPv4 for Asp.NET specific any address syntax (+, *, etc.) where Asp.NET seems to default to IPv6. The headache is that there seems to be cases where IPv6 is technically present, but there isn't a "public" address the hostname can resolve to. In the rare event that IPv4 isn't supported at all, we'll fall back to IPv6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Persistent sql server not accessible via loopback network device Binding container to non-localhost or 0.0.0.0 does not work
3 participants
0