Replies inline
On Thu, Nov 2, 2017 at 2:13 AM, Oren Shemesh wrote:
> Hi Eric, Rawlin
>
> (Good to talk to you ! :-)
>
> Like I wrote, the problem with just fixing the UI (Or using the API, or the
> new portal) is that the same DS can be used for both HTTP and HTTPS.
> So as long as there is a sin
Hi Eric, Rawlin
(Good to talk to you ! :-)
Like I wrote, the problem with just fixing the UI (Or using the API, or the
new portal) is that the same DS can be used for both HTTP and HTTPS.
So as long as there is a single port in CR config, and the presence of this
port causes TR to always redirect
Hi Oren,
Looking at the code in traffic_ops, it looks like at one point in time
you could append a `:` in the HTTP bypass FQDN field, and
`UI::Topology::gen_crconfig_json()` would split it and do the right
thing. My guess is that the field validation was added later (i.e.
must be a valid hostname)
Hmmm.
Further digging into TR code shows that this behaviour happens because CR
config contains this piece of JSON info for the DS:
"bypassDestination": {"HTTP": {
"port": "80",
"fqdn": "bypass.videos.xxx.com"
}},
The "port" field forces the TR to append :80 to the hos
Hey Oren-
I was just looking at this code yesterday for another reason. This decision
happens here:
https://github.com/apache/incubator-trafficcontrol/blob/d86d6b5a218431ff42445e0efefddd5378883d8f/traffic_router/core/src/main/java/com/comcast/cdn/traffic_control/traffic_router/core/ds/DeliverySe
Hello,
We have recently encountered some unexplained behaviour of TR, when there
are no caches available so it redirects to the configured 'Bypass FQDN'.
Below you can see a request to an HTTPS-only delivery service.
The 'Bypass FQDN' configured for this DS is : bypass.videos.xxx.com
TR redirects
