Correcting use of httpsPort instead of secure.port

[mikeV02]

I was trying to change the TrafficRouter SecurePort value to other than 443, and tried to use the parameter secure.port added to the server.xml on the CCR profile in Traffic Portal. But noticed, that TcOps/TcMon, do not add that parameter to the CrCronfig.json.

I digged into the code and fount that the use of secure.port was added to TrafficRouter on the following commit: 8ff9006 However, no counter part was added to TcOps to actually state the value secure.port from the TrafficPortal paramenters. The value that TcOps adds to the CrConfig.json is the httpsPort, from the server configuration itself on TrafficPortal, but that parameter is not used anywhere by Traffic Router (from what I saw).

I see that it would require just two lines edits on traffic_router/core/src/main/java/org/apache/traffic_control/traffic_router/core/util/LanguidState.java to make use of httpsPort and not the unexisting secure.port.

Basically, edit lines 86 and 87 of the file, and replace secure.port for httpsPort

---

Which Traffic Control components are affected by this PR?

• Traffic Router

What is the best way to verify this PR?

Try adding the secure.port parameter to the CCR profile on Traffic Portal. It does not matter if you add it to server.xml or CrConfig,json, Traffic Ops never assigns secure.port to the traffic routers under that profile. Applying the change on the file on this PR, makes TR use the httpsPort configured under the server configuration un Traffic Portal.

If this is a bugfix, which Traffic Control versions contained the bug?

All

PR submission checklist

• This PR has a CHANGELOG.md entry
• This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

[rawlinp]

Also, I just want to point out that if you use a non-standard httpsPort for your TRs, all the delivery service example URLs for https will be wrong, since they'll be missing TR's non-standard https port suffix. There's not much we can do to fix that, but it shouldn't really matter as long as the clients are given the correct URL with the non-standard https port. If we were to make secure.port a real per-CDN TR profile parameter, we could fix the example URLs for the delivery services.

[rawlinp]

This looks good, but there are merge conflicts to resolve (most likely in CHANGELOG.md).