-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
fix port when fall back to http #43620
Conversation
@@ -80,6 +80,7 @@ private static void FallbackToHttp(HttpRequestMessage request) | |||
{ | |||
var uriBuilder = new UriBuilder(request.RequestUri!); | |||
uriBuilder.Scheme = "http"; | |||
uriBuilder.Port = 80; |
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.
This will explicitly set the port to 80 (i.e. http://whatever:80
) - is that what's intended, or in that scenario would you want the implied default port (i.e. http://whatever
)? If the latter, then you can set it to -1
.
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.
Thanks for your review.
Maybe I should change the port only when the port is 443, as the user's registry may specified the port.
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.
I tested, If user specified a http port. the publish command will result an error:
Uploading layer 'sha256:28d4f52c4a876bde6af159c1e53d159d94edfab99bfdc6eda8b53be82ee29eb1' to 'dockerhub.shengguanda.com:80'
C:\Program Files\dotnet\sdk\8.0.401\Containers\build\Microsoft.NET.Build.Containers.targets(242,5): error CONTAINER1013: Failed to push to the output registry: The SSL connection could not be established, see inner excepti
on.
So there is no way to specify a http port. It is another issue.
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.
I think that we should defer to the user's registry configuration here:
- if the registry url had a port, then we should use it
- if the registry url did not have a port, then we should set
-1
here, because per the docs
If the Port property is set to a value of -1, this indicates that the default port value for the protocol scheme will be used to connect to the host.
So the 'default' value of the http
protocol would be used in this case.
if(uriBuilder.Port == 443) // default https port, change to http default port
uriBuilder.Port = 80; if if the code is if(uriBuilder.Port == 443) // default https port, change to http default port
uriBuilder.Port = -1; It looks weird. 443 is related to 80, not -1; |
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.
@dameng324 please change to use the approach described here - explicitly setting to port 80 may not 'look weird' to you, but it is not a sufficient solution for all of the use cases identified.
I checked the The only way is introducing a The change has been committed. Thanks for your patients, Please check again. |
BTW, I'm glad to test the package before releasing to avoid this bug. I add insecure registry support in #39840, but saddly it's broken when 8.0.40x released. To avoid this happenning again, I can test this feature before dotnet team releasing it if needed. |
@dameng324 I think we have enough information already in the When the original registry name (possibly including a port) is converted to a Uri, the > let reg = "localhost:5000";;
val reg: string = "localhost:5000"
> let regUri = Uri $"https://{reg}";;
val regUri: Uri = https://localhost:5000/
> regUri.Port, regUri.IsDefaultPort;;
val it: int * bool = (5000, false) Similarly, if the registry data doesn't contain port information, we get that data as well: > let reg = "registry.mycorp.com";;
val reg: string = "registry.mycorp.com"
> let regUri = Uri $"https://{reg}";;
val regUri: Uri = https://registry.mycorp.com/
> regUri.Port, regUri.IsDefaultPort;;
val it: int * bool = (443, true) This data persists across usage of the UriBuilder: > let reg = "registry.mycorp.com";;
val reg: string = "registry.mycorp.com"
> let regUri = Uri $"https://{reg}";;
val regUri: Uri = https://registry.mycorp.com/
> regUri.Port, regUri.IsDefaultPort;;
val it: int * bool = (443, true)
> let builder = UriBuilder regUri;;
val builder: UriBuilder = https://registry.mycorp.com:443/
> builder.Scheme <- "http";;
val it: unit = ()
> builder.Uri.Port, builder.Uri.IsDefaultPort;;
val it: int * bool = (443, false)
> builder.Port <- -1;;
val it: unit = ()
> builder.Uri.Port, builder.Uri.IsDefaultPort;;
val it: int * bool = (80, true) Note that in this last example, setting the Port to the Therefore, I think in this Fallback message handler, we can accurately detect if a Port was explicitly set by the user's registry domain and only 'reset' the port for the new |
@baronfel Thanks for your explain. I changed |
@dotnet/product-construction had to rerun this PR due to the sdk-unified-build leg, I was told to ping you as this happens. |
I don't think
These are functionally the same. |
@tmds this is a great and very depressing point. |
Actually, |
We also have the |
@dameng324 you should be able to |
I'm a little unclear on where we are with this PR - @dameng324 can you summarize quickly what you see any remaining issues being (if any?) |
@dameng324 no rush, enjoy your vacation! We're locking down the SDK for 9.0.1xx quite soon, but this fix could be backported to the December servicing release as soon as it's merged, no problem at all. |
When fallback to http,the port should fallback to 80, if don't the port will be 443.
Already tested on my local machine.
Fixed: #43618 , dotnet/sdk-container-builds#588