You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@trafficserver.apache.org by Manjesh Nilange <ma...@gmail.com> on 2014/08/20 23:13:59 UTC

header-rewrite change

Hi all,

We have a feature to implement and are wondering if header-rewrite is the
right home for this feature. In a nutshell, when using ATS as a reverse
proxy, we want to redirect all http requests with a certain cookie to their
https counterparts but not using remap.config. The remap.config constraint
comes about because we already have a ton of existing rules and creating a
blanket rule is not feasible. We could either create a simple plugin to do
this or enhance one of the existing ones with header-rewrite being the
leading candidate.

But I feel this may not be right because the way it is implemented and
designed, header-rewrite only changes the headers and always continues the
transaction. To do the redirect outside a remap context, it would have to
error the transaction. So now it's also changing the control flow of the
transaction. And just adding a feature to our requirement ("switching" the
scheme) may not be very reusable/generic to others. A generic feature where
you could construct the redirect location using various components
(scheme/domain/path/query etc.) of the incoming URL is a fairly complex
feature.

On the flip side, creating a plugin just to switch schemes creates extra
deployment and maintenance overhead.

Any feedback would be much appreciated, thanks.

- Manjesh

Re: header-rewrite change

Posted by Shu Kit Chan <ch...@gmail.com>.
Yes. We have similar requirements than you, Manjesh. And we implemented our
own plugin, too. But we are considering to rewrite that in lua.


On Thu, Aug 21, 2014 at 12:35 PM, Leif Hedstrom <zw...@apache.org> wrote:

>
> On Aug 21, 2014, at 1:27 PM, Manjesh Nilange <ma...@gmail.com>
> wrote:
>
> > Anybody got $0.02? :-)
>
>
> Sounds similar to the cookie remap plugin at Yahoo. That one was riddle
> with Yahoo specific cookie extraction code though, making it difficult /
> useless to open source.
>
> It possibly sounds more of new feature for regex_remap? Or even better,
> Lua scripting ;).
>
> — Leif
>
>

Re: header-rewrite change

Posted by Leif Hedstrom <zw...@apache.org>.
On Aug 21, 2014, at 1:27 PM, Manjesh Nilange <ma...@gmail.com> wrote:

> Anybody got $0.02? :-)


Sounds similar to the cookie remap plugin at Yahoo. That one was riddle with Yahoo specific cookie extraction code though, making it difficult / useless to open source.

It possibly sounds more of new feature for regex_remap? Or even better, Lua scripting ;).

— Leif


Re: header-rewrite change

Posted by Manjesh Nilange <ma...@gmail.com>.
Anybody got $0.02? :-)

- Manjesh



On Wed, Aug 20, 2014 at 2:13 PM, Manjesh Nilange <ma...@gmail.com>
wrote:

> Hi all,
>
> We have a feature to implement and are wondering if header-rewrite is the
> right home for this feature. In a nutshell, when using ATS as a reverse
> proxy, we want to redirect all http requests with a certain cookie to their
> https counterparts but not using remap.config. The remap.config constraint
> comes about because we already have a ton of existing rules and creating a
> blanket rule is not feasible. We could either create a simple plugin to do
> this or enhance one of the existing ones with header-rewrite being the
> leading candidate.
>
> But I feel this may not be right because the way it is implemented and
> designed, header-rewrite only changes the headers and always continues the
> transaction. To do the redirect outside a remap context, it would have to
> error the transaction. So now it's also changing the control flow of the
> transaction. And just adding a feature to our requirement ("switching" the
> scheme) may not be very reusable/generic to others. A generic feature where
> you could construct the redirect location using various components
> (scheme/domain/path/query etc.) of the incoming URL is a fairly complex
> feature.
>
> On the flip side, creating a plugin just to switch schemes creates extra
> deployment and maintenance overhead.
>
> Any feedback would be much appreciated, thanks.
>
> - Manjesh
>
>