ran some surface tests and looks to work as advertised. usual response is a redirect, but this time ATS handles the redirect and responds with a 200.

#traffic_ctl config get proxy.config.http.redirection_enabled
proxy.config.http.redirection_enabled: 1

#traffic_logcat squid.blog

1444778208.017 0 TCP_MISS_REDIRECT/301 0 GET - NONE/- text/html
1444778208.460 443 TCP_MISS/200 60276 GET http://www.cnn.com/ - DIRECT/www.cnn.com text/html

# curl -H HOST:cnn.com -o /dev/null -v
* About to connect() to port 8080 (#0)
*   Trying connected
* Connected to ( port 8080 (#0)
> GET / HTTP/1.1
> User-Agent: xyz
> Accept: */*
> HOST:cnn.com

< HTTP/1.1 200 OK
< Cache-Control: max-age=60
< X-XSS-Protection: 1; mode=block
< Content-Security-Policy: default-src 'self' http://*.cnn.com:* https://*.cnn.com:* *.cnn.net:* *.turner.com:* *.ugdturner.com:* *.vgtf.net:*; script-src 'unsafe-inline' 'unsafe-eval' 'self' *; style-src 'unsafe-inline' 'self' *; frame-src 'self' *; object-src 'self' *; img-src 'self' * data:; media-src 'self' *; font-src 'self' *; connect-src 'self' *;
< Content-Type: text/html; charset=utf-8
< Via: 1.1 varnish
< Content-Length: 59418
< Accept-Ranges: bytes
< Date: Wed, 14 Oct 2015 02:02:38 GMT

On Tue, Oct 13, 2015 at 4:13 PM, Sudheer Vinukonda <sudheerv@yahoo-inc.com> wrote:
Below are the settings you would need. Both these settings should be overridable on master (not sure, about 5.3.x).



Also, ATS should stream the final (after redirect) response to the end user immediately, in parallel to storing the response in cache (this is the default behavior of ATS).



On Tuesday, October 13, 2015 1:58 PM, Jeremy Payne <jp557198@gmail.com> wrote:

Version - ATS 5.3.2

Mode - Reverse Proxy

Anyone have any pointers on configuring ATS to follow HTTP redirects(301/302) handed by the origin server ?

The goal here is to have ATS follow the redirect on behalf of the client, instead of sending the redirect back downstream.

This seems doable in Lua(via luacurl .. ts.fetch not available in 5.3.2), but I cant seem to 'restart' the transaction after reading the origin response headers.
Another issue I see here is being able to stream the final(after the redirect) response immediately back to the end user(read_while_writer).

In this current implementation(or with my limited understanding), it seems I would have to first store the final response before I could send back downstream.

I have seen similar approaches with varnish and nginx however implementation is very hacky.. which is to be expected as this is very unconventional and probably against spec.

Thanks in advance.