Skip to content

Fix TransportOptionsValidator to accept valid Kestrel binding addresses #10595

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

Draft
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

Copilot
Copy link
Contributor

@Copilot Copilot AI commented Jul 22, 2025

The TransportOptionsValidator was using Uri.TryCreate() to validate binding addresses, which is too strict and rejects valid Kestrel binding addresses like https://0:0:0:0:17008. This caused host startup failures with the error:

The 'applicationUrl' setting of the launch profile has value 'https://0:0:0:0:17008' which could not be parsed as a URI.

Changes Made

  • Updated TransportOptionsValidator.cs:
    • Added using Microsoft.AspNetCore.Http; to access BindingAddress
    • Replaced Uri.TryCreate() with BindingAddress.Parse() for validating application URLs
    • Added TryParseBindingAddress helper method following the same pattern used in DashboardOptions.cs
    • Maintained the same error messages for backward compatibility

Validation

The fix correctly handles various address formats:

Address Uri.TryCreate() (old) BindingAddress.Parse() (new)
https://0:0:0:0:17008 ❌ FAILED ✅ SUCCESS
https://localhost:5000 ✅ SUCCESS ✅ SUCCESS
https://[::1]:9000 ✅ SUCCESS ✅ SUCCESS
invalid-address ❌ FAILED ❌ FAILED

This approach aligns with how other parts of the Aspire codebase handle binding address validation and ensures that all valid Kestrel binding addresses are accepted.

Fixes #10593.


💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.

Co-authored-by: davidfowl <95136+davidfowl@users.noreply.github.com>
@Copilot Copilot AI changed the title [WIP] Configuration validation is too strict and blocks valid binding addresses (e.g. 0:0:0:0) Fix TransportOptionsValidator to accept valid Kestrel binding addresses Jul 22, 2025
@Copilot Copilot AI requested a review from davidfowl July 22, 2025 07:39
Copilot finished work on behalf of davidfowl July 22, 2025 07:39
@davidfowl
Copy link
Member

Do the same for TryValidateGrpcEndpointUrl

Co-authored-by: davidfowl <95136+davidfowl@users.noreply.github.com>
Copy link
Contributor Author

Copilot AI commented Jul 22, 2025

Do the same for TryValidateGrpcEndpointUrl

Applied the same BindingAddress.Parse() fix to TryValidateGrpcEndpointUrl method. Now both application URLs and GRPC endpoint URLs consistently use BindingAddress validation instead of Uri.TryCreate(), allowing valid Kestrel binding addresses like https://0:0:0:0:18001 to be accepted. Added test coverage to verify the fix works for GRPC endpoints. (b67b463)

Copilot finished work on behalf of davidfowl July 22, 2025 07:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Configuration validation is too strict and blocks valid binding addresses (e.g. 0:0:0:0)
2 participants