trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Geffon <bri...@apache.org>
Subject Re: Remap/regex_remap consolidation
Date Wed, 26 Mar 2014 01:42:17 GMT
I personally vote for regexing everything until we get around to finalizing
lua config, I also vote for this being the one who will end up writing the
code :)

Brian

On Tuesday, March 25, 2014, James Peach <jpeach@apache.org> wrote:

> On Mar 25, 2014, at 3:28 PM, Leif Hedstrom <zwoop@apache.org<javascript:;>>
> wrote:
>
> >
> > On Mar 25, 2014, at 4:08 PM, James Peach <jpeach@apache.org<javascript:;>>
> wrote:
> >
> >> On Mar 25, 2014, at 1:50 PM, Thomas Jackson <jacksontj.89@gmail.com<javascript:;>>
> wrote:
> >>
> >>> Here at LinkedIn we've been using regular remap.config for a while
> (with
> >>> all our map options). One thing we've been looking into recently is
> path
> >>> based regexes (which regex_remap supports). While looking into it we
> found
> >>> a few shortcomings of the plugin-- and decided it would probably be
> better
> >>> for everyone involved if we could come up with a way to consolidate
> this
> >>> into regular remap. This raises a few questions about how to
> consolidate,
> >>> so we figure we'd solicit some feedback from the community before we
> get
> >>> started. Since there are quite a few changes we're considering I've
> tried
> >>> to assemble examples for all the scenarios, but to start out I'll put
> some
> >>> examples of how remaps look today.
> >>
> >> Hi Thomas,
> >>
> >> I think there is a real need for something like this. I think that it
> is pretty common to follow a regex_map with a secondary set of regex_remap
> rules. One observation that I have is that the current system conflates
> matching and rewriting. I think that the is why you end up with a large set
> of alternative regex-based syntaxes below. Have you considered a system of
> simple, composable match and rewrite operators?
> >>
> >> A made-up example, to match https://*.example.com and rewrite it ...
> >>
> >> Old version:
> >>      regex_map https://.*.example.com/foo http://dest.example.com
> >>
> >> New version:
> >>      map @scheme @value=https @replace=http \
> >>              @host @match=*.example.com @replace=dest.example.com \
> >>              @path @match=/foo(.*) @replace=$0
> >>
> >> The new version is verbose, but extensible and more flexible than the
> fixed syntax. I haven't really thought this through very much ...
> >
> >
> > I agree that regex_map is not great. However, the above seems very
> involved, and something I believe ought to be part of the new Lua config
> format. I.e. lets focus on the Lua configuration stuff, instead of baking
> more crud into the current remap.config mess?
>
> Irrespective of ugly syntax, I think the fundamental issue here is the
> need to vary matching and URL rewriting independently. You could do it by
> having Lua blocks, you could do it by baking more crud into remap.config,
> or you could do it by regexing everything :)
>
> J

Mime
View raw message