trafficserver-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Peach <jpe...@apache.org>
Subject Re: Remap/regex_remap consolidation
Date Tue, 25 Mar 2014 22:54:17 GMT
On Mar 25, 2014, at 3:28 PM, Leif Hedstrom <zwoop@apache.org> wrote:

> 
> On Mar 25, 2014, at 4:08 PM, James Peach <jpeach@apache.org> wrote:
> 
>> On Mar 25, 2014, at 1:50 PM, Thomas Jackson <jacksontj.89@gmail.com> 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