Performing HTTP -> HTTPS Redirects using regex_redirect

[Daniel Carraro <da...@blinkmobile.com.au>]

Hi,

I have ATS setup behind an Amazon Web Services Elastic Load Balancer. I
currently have the following regex_map rules:

regex_map http://(.*).blinkm.io/ http://$
0.s3-website-ap-southeast-2.amazonaws.com
regex_map https://(.*).blinkm.io/ http://$
0.s3-website-ap-southeast-2.amazonaws.com

Basically, if a request comes in to a specific subdomain, route it to an
AWS S3 bucket of the same name.

However, I'm wondering if it's possible for ATS to perform HTTP -> HTTPS
Redirections. So, a request to http://test.blinkm.io would get redirected
to https://test.blinkm.io

Ideally, I'd like to set my ELB up so that it performs SSL Termination, and
I don't have to worry about storing certificates on the instances
themselves. This means that the instance would be listening on two ports:
80 for HTTP requests, and 8888 for HTTPS requests (which have been
"converted" into HTTP by the ELB).

With that approach in mind, I was thinking of having the following rules:

regex_redirect http://(.*).blinkm.io/ https://$1.blinkm.io/
# which is a new request that goes through the ELB
# and gets converted from https to http on port 8888
regex_map http://(.*).blinkm.io:8888/ http://$
0.s3-website-ap-southeast-2.amazonaws.com

I'm having issues with this (404 from proxy after CONNECT, even when the
URL should be working), but I don't want to overload this email with log
snippets. I'll happily provide them if needed though.

Is this the best way to go about doing such redirections? Are HTTP -> HTTPS
redirections even possible with ATS? I've tried going through the
documentation but haven't found anything on doing such redirections, so if
anyone has example rules that would be great.

Any help would be greatly appreciated.

Thanks,
Daniel

Re: Performing HTTP -> HTTPS Redirects using regex_redirect

[James Peach <ja...@me.com>]

> On Jun 7, 2016, at 12:42 AM, Daniel Carraro <da...@blinkmobile.com.au> wrote:
> 
> Hi,
> 
> I have ATS setup behind an Amazon Web Services Elastic Load Balancer. I currently have the following regex_map rules:
> 
> regex_map http://(.*).blinkm.io/ http://$0.s3-website-ap-southeast-2.amazonaws.com
> regex_map https://(.*).blinkm.io/ http://$0.s3-website-ap-southeast-2.amazonaws.com
> 
> Basically, if a request comes in to a specific subdomain, route it to an AWS S3 bucket of the same name. 
> 
> However, I'm wondering if it's possible for ATS to perform HTTP -> HTTPS Redirections. So, a request to http://test.blinkm.io would get redirected to https://test.blinkm.io
> 
> Ideally, I'd like to set my ELB up so that it performs SSL Termination, and I don't have to worry about storing certificates on the instances themselves. This means that the instance would be listening on two ports: 80 for HTTP requests, and 8888 for HTTPS requests (which have been "converted" into HTTP by the ELB). 
> 
> With that approach in mind, I was thinking of having the following rules:
> 
> regex_redirect http://(.*).blinkm.io/ https://$1.blinkm.io/
> # which is a new request that goes through the ELB
> # and gets converted from https to http on port 8888
> regex_map http://(.*).blinkm.io:8888/ http://$0.s3-website-ap-southeast-2.amazonaws.com
> 
> I'm having issues with this (404 from proxy after CONNECT, even when the URL should be working), but I don't want to overload this email with log snippets. I'll happily provide them if needed though.

If you are getting a CONNECT method in ATS, I'm guessing you are using "curl -x"? CONNECT requests only match https rules, so you want the ELB layer to terminate the TLS session and send a non-TLS HTTP request to the ATS behind it. You can use "curl --resolve" to convince curl to not send a CONNECT.

> 
> Is this the best way to go about doing such redirections? Are HTTP -> HTTPS redirections even possible with ATS? I've tried going through the documentation but haven't found anything on doing such redirections, so if anyone has example rules that would be great.
> 
> Any help would be greatly appreciated.
> 
> Thanks,
> Daniel