Fix cache config for https origins #6091
Merged
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.
Fixes cache config for https origins.
There was a bug, that https origins would result in edge remap targets of
https://...
and corresponding edge parent lines of port=443 and corresponding mid remap sources ofhttps:// ... 443
.Except that Edge-Mid communication has always been HTTP, and the Mid parents are :80, and Mids are listening on 80, and Mids don't have the certificates necessary to serve HTTPS.
So that config resulted in Edges making TLS HTTPS requests to the Mid's port 80. Which should fail, but seems to sometimes succeed, possibly due to Keep-Alives from other requests.
This fixes HTTPS Origins to properly use
http://...:80
remaps everywhere. We would like to add internal HTTPS support in the future, but that's a much larger feature. Today, ATC doesn't support that. Moreover, that shouldn't depend on whether the Origin is HTTPS.The correct bug fix here is to use http and 80 for internal cache communication, regardless of the origin protocol.
Which this fix does.
Includes tests.
Includes changelog.
No docs, no interface change.
Which Traffic Control components are affected by this PR?
What is the best way to verify this PR?
Run tests. Generate config with an HTTPS Origin on a Delivery Service that uses mids, verify config is generated to properly use http and port 80 for all internal edge-mid communication.
If this is a bugfix, which Traffic Control versions contained the bug?
Probably all of them.
PR submission checklist