Replies inline On Thu, Nov 2, 2017 at 2:13 AM, Oren Shemesh <[email protected]> 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 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.
Ok, I'd be +1 on this easy fix. Existing delivery services shouldn't be affected because currently they're already forced to using port 80 on the bypass server if no port is specified. This change would allow HTTPS for bypass servers to actually work in general, because I really doubt that operators have jumped through the Traffic Control hoops to have their bypass servers do HTTPS on port 80. > 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. I agree; that sounds like it would be going overboard. Bypass servers should be using standard ports if they accept both HTTP and HTTPS. - Rawlin
