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 hostname.
If the "port" element would not be there, TR would have done the right
thing.
(DeliveryService.java::getFailureHttpResponse())
So digging into the TO code (UI/Topology.pm::gen_crconfig_json()) , I see
that when the "Bypass FQDN" has ':' in it, it is split and the latter part
is used as the port number being put into the CR config. Otherwise, 80 is
used.
However, there are two problems with the combined effect of the TR and TO
code:
1. It does not make sense to redirect HTTP requests to http://bypass.com
and HTTPS requests to https:bypass.com:80 . The server cannot listen for
both HTTP and HTTPS requests on the same port. So the fact that there is a
single port in the CR config, and this port is being forced into the
generated URL for the bypass, seem like a bug to me (Given that a DS can be
both HTTP and HTTPS).
2. The TO UI does not let you enter a string with ':' in it into the
"Bypass FQDN" field, anyway.
Currently, my temporary solution is to change the TO code to remove the
'port' field from CR config, which results in "natural" redirect.
This means commenting-out a single line of code :-)
I believe a proper solution would be to do this only for DSs which are of
protocol 'http and https'. Such DSs would assume that the bypass server
also support both protocols, on the standard ports.
A more wide solution would be to allow specifying separate ports for HTTP
and for HTTPS in the cr config. But, is there a real-world need for this ?
Comments are welcome :-)
(And yes, I will create an issue in github soon).
Oren.
On Wed, Nov 1, 2017 at 2:01 PM, Oren Shemesh <[email protected]> wrote:
> 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 the https request to https://bypass.videos.xxx.com:80/...
>
> (I replaced some strings with 'xxx' and 'yyy' for my privacy :-0)
>
> To me it looks like a bug, who does TR specify port 80 for an HTTPS
> transaction, without any explicit configuration to do so ?
>
> Note that when there are caches available, the redirect to the cache
> happens without the :80, as it should be.
> Also note, in case it is relevant, that the origin URL for this DS is:
> https://<something>
>
> Any comments on this would be welcome.
>
>
> When no cache is available:
>
> orens@cq-rd09:~$ curl -sk -D - -o /dev/null https://tr.xxx.stage-cdn.yyy/
> AAA
> HTTP/1.1 302 Moved Temporarily
> Server: Apache-Coyote/1.1
> Location: https://bypass.videos.xxx.com:80/AAA
> Content-Length: 0
> Date: Wed, 01 Nov 2017 10:31:29 GMT
>
> When a cache is available:
>
> orens@cq-rd09:~$ curl -sk -D - -o /dev/null https://tr.xxx.stage-cdn.yyy/
> AAA
> HTTP/1.1 302 Moved Temporarily
> Server: Apache-Coyote/1.1
> Location: https://p39-edge-lab.xxx.stage-cdn.yyy/AAA
> Content-Length: 0
> Date: Wed, 01 Nov 2017 10:56:11 GMT
>
>
> Thanks, Oren.
>
> --
>
> *Oren Shemesh*
> Qwilt | Work: +972-72-2221637 <+972%2072-222-1637>| Mobile:
> +972-50-2281168 <+972%2050-228-1168> | [email protected] <[email protected]>
>
--
*Oren Shemesh*
Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | [email protected]
<[email protected]>
