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 to that port (Regardless of the request
protocol: HTTP vs. HTTPS), it is better to have no port in CR config than
to allow me to specify a non-standard one.
Maybe I did not explain it in enough detail:
1. Once CR config contains a port number, TR redirects to that port number
(Appending ":port" to the host name if the port number is not the standard
one for the current HTTP/HTTPS request).
2. When a DS supports both HTTP and HTTPS, the fact that CR config can
specify only a single port number, makes it impossible for TR to work
without a bug. If this port is 80, then HTTPS is broken. If this port is
443, HTTP is be broken.
3. An easy fix is to remove the port number from CR config, and put it in
there only if there is a ":port" at the end of the "Bypass FQDN" string.
This way, for single-protocol DSes, the user will be able to specify a
non-standard port that works.
4. In order to support DSs which are "http and https", the structure of the
CR config needs to be enhanced, and I am not sure if there is justification
for that.
If things are still not clear, lets continue this in the issue I will open,
for the sake of documenting it in a more proper location (?)
Oren.
On Wed, Nov 1, 2017 at 7:26 PM, Rawlin Peters <rawlin.pet...@gmail.com>
wrote:
> Hi Oren,
>
> Looking at the code in traffic_ops, it looks like at one point in time
> you could append a `:<port>` 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), but no one realized this broke the
> `:<port>` feature because it was never tested/infrequently used in
> that field.
>
> The API doesn't actually require that same validation, so I believe
> you should be able to fix the validation in the old UI so that the
> field can be `<valid hostname>[:<optional port number>]`. Then you
> should be able to append `:443` to your HTTP bypass FQDN to get it
> working over HTTPS. Or better yet, just use the new Traffic Portal
> which already allows this. :)
>
> Best,
> Rawlin
>
>
>
> On Wed, Nov 1, 2017 at 9:29 AM, Oren Shemesh <or...@qwilt.com> wrote:
> > 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 <or...@qwilt.com> 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> | or...@qwilt.com <y...@qwilt.com>
> >>
> >
> >
> >
> > --
> >
> > *Oren Shemesh*
> > Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | or...@qwilt.com
> > <y...@qwilt.com>
>
--
*Oren Shemesh*
Qwilt | Work: +972-72-2221637| Mobile: +972-50-2281168 | or...@qwilt.com
<y...@qwilt.com>
