-
Notifications
You must be signed in to change notification settings - Fork 647
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
base: main
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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;
Looks like there’s still some issue with |
There was a problem hiding this 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
There was a problem hiding this 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?
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, |
The biggest design choice is that I'm actively selecting IPv4 for Asp.NET specific any address syntax ( |
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
<remarks />
and<code />
elements on your triple slash comments?doc-idea
templatebreaking-change
templatediagnostic
template