Better handle redirects to https in ping#2225
Merged
jonjohnsonjr merged 1 commit intogoogle:mainfrom Mar 2, 2026
Merged
Conversation
When we pass --insecure into crane, we permit http responses for any host, which means we do this fun little happy eyeballs race between https and http for hosts-that-we-expect-to-be-served-over-https. A common thing for web servers to do is to redirect http to https. Our little happy eyeballs race assumes that if we ping http and get a successful response, that we should use http going forward. This is naive in the case where the reason we received a happy response is that the server redirected us to the https version (and we followed it). This happens rarely (when the https reponse takes longer than the fallback delay) so we don't often see it, but if that does happen we end up failing to attach credentials, which isn't great. To fix this, we can just look the scheme we used in the (sometimes redirected) request URL rather than the scheme we used for the original request. Signed-off-by: Jon Johnson <jon.johnson@chainguard.dev>
941499f to
23aec82
Compare
Codecov Report✅ All modified and coverable lines are covered by tests.
Additional details and impacted files@@ Coverage Diff @@
## main #2225 +/- ##
===========================================
- Coverage 71.67% 53.17% -18.51%
===========================================
Files 123 164 +41
Lines 9935 10977 +1042
===========================================
- Hits 7121 5837 -1284
- Misses 2115 4433 +2318
- Partials 699 707 +8 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
imjasonh
approved these changes
Mar 2, 2026
mattmoor
approved these changes
Mar 2, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When we pass --insecure into crane, we permit http responses for any host, which means we do this fun little happy eyeballs race between https and http for hosts-that-we-expect-to-be-served-over-https.
A common thing for web servers to do is to redirect http to https.
Our little happy eyeballs race assumes that if we ping http and get a successful response, that we should use http going forward. This is naive in the case where the reason we received a happy response is that the server redirected us to the https version (and we followed it).
This happens rarely (when the https reponse takes longer than the fallback delay) so we don't often see it, but if that does happen we end up failing to attach credentials, which isn't great.
To fix this, we can just look the scheme we used in the (sometimes redirected) request URL rather than the scheme we used for the original request.