Mailing-List: contact users-help@trafficserver.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@trafficserver.apache.org
MIME-Version: 1.0
Date: Tue, 13 Oct 2015 15:57:40 -0500
Message-ID: 
 <CAEkTh3Hhs09BcdPOdMfPJrXqX2jXSshp8kzWrSSCyPpVEFV3yQ@mail.gmail.com>
Subject: Following Origin Redirect
From: Jeremy Payne <jp557198@gmail.com>
To: users@trafficserver.apache.org
Content-Type: multipart/alternative; boundary=089e01229c145963c5052202b2af

--089e01229c145963c5052202b2af
Content-Type: text/plain; charset=UTF-8

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.

--089e01229c145963c5052202b2af
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>Version - ATS 5.3.2<br></div><div>Mode - Reverse=
 Proxy<br><br></div><div>Anyone have any pointers on configuring ATS to fol=
low HTTP redirects(301/302) handed by the origin server ?<br></div><div>The=
 goal here is to have ATS follow the redirect on behalf of the client, inst=
ead of sending the redirect back downstream.<br><br></div><div>This seems d=
oable in Lua(via luacurl .. ts.fetch not available in 5.3.2), but I cant se=
em to &#39;restart&#39; the transaction after reading the origin response h=
eaders. <br>Another issue I see here is being able to stream the final(afte=
r the redirect) response immediately back to the end user(read_while_writer=
).<br></div><div>In this current implementation(or with my limited understa=
nding), it seems I would have to first store the final response before I co=
uld send back downstream.<br><br>I have seen similar approaches with varnis=
h and nginx however implementation is very hacky.. which is to be expected =
as this is very unconventional and probably against spec.<br><br></div><div=
>Thanks in advance.<br><br><br></div><div><br></div><br></div></div>

--089e01229c145963c5052202b2af--