-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Client auto Host header should omit the port if it is default #2407
Comments
It turns out, the AWS client only appends the port if you force it to do so - still I'd argue, the behavior should be along the sepc and other implementations... |
Yea, I believe the intent is to just use the value the user provided as-is. I agree that the client should repair some things, but is this one that is worth changing for a user? |
Let's put the AWS client aside for a second - my point is "using the value to user provided" is wrong. At least curl, FF and chrome remove the value even if provided by the user. Still, the spec itself (https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.23) is a bit vaque. Hoewever, I'd recommend maintianing compatibility to the big players ;-) |
Alright, seems fair. Since this is an automatic host header generation, we can try following the pack, and if the user already provided a |
The HTTP spec states that the "host" header should only include the port if it isn't the standard port.
However, if an URL like
https://my-lovely-bucket.s3-eu-central-1.amazonaws.com:443
is accessed (as generated by the AWS SDK), a port header likehost: s3-eu-central-1.amazonaws.com:443
instead ofhost: s3-eu-central-1.amazonaws.com
is submitted. This will break the computed signature of the S3 request.Note that both (modern browsers - checked with latest FF and chrome) as well as good old curl both strip the port number for standard ports.
I'd say this has to be fixed in client.rs:240 - I'd be happy to provide a PR if this helps.
The text was updated successfully, but these errors were encountered: