[
https://issues.apache.org/jira/browse/TS-3120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14165319#comment-14165319
]
ASF subversion and git services commented on TS-3120:
-----------------------------------------------------
Commit 50520e7fe5dea63ace1df4a03cdcbf0029bd820d in trafficserver's branch
refs/heads/master from [~ffcai]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=50520e7 ]
TS-3120: overlapping remap rank when using .include directives
As described in the docs, we use line number for remap rule rank:
Once these rules are executed we pick the lowest line number as
the match (which replicates first-match-wins).
However, when we use .include directives to include some other remap
config files, there will be overlapping and conflict with the line
numbers in each other file.
*Examples*
remap.config
.include remap1.config
.include remap2.config
remap1.config
map /foo/ https://www.yahoo.com
remap2.config
map /foo/bar1 https://www.yahoo.com
map /foo/bar2 https://www.yahoo.com
When parsing remap1.config, first entry in remap1.config is inserted
with rank 0, second with rank 1. Then parsing remap2.config, the
single entry is inserted with rank 0 again. So the entry in
remap2.config is overlapped with first entry in remap1.config and
takes precedence with second entry. This would confuse customers.
I use count in UrlRewrite::_addToStore for rank. It is used to count
the number of each type of map rules(map, reverse_map,
map_with_referer...). When we insert a new url_mapping, it is stored
in a separate MappingsStore. So there would be no conflict with
each type's count.
> Overlapping rank in config.remap when using .include directives
> ---------------------------------------------------------------
>
> Key: TS-3120
> URL: https://issues.apache.org/jira/browse/TS-3120
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, Core
> Affects Versions: 5.0.0
> Reporter: Feifei Cai
> Assignee: James Peach
> Fix For: 5.2.0
>
> Attachments: TS-3120.diff
>
>
> As described in
> [docs|https://docs.trafficserver.apache.org/en/latest/reference/configuration/remap.config.en.html#precedence]
> {quote}
> Once these rules are executed we pick the lowest line number as the match
> (which replicates first-match-wins).
> {quote}
> In fact, we use line number for rank for now.
> ([Github|https://github.com/apache/trafficserver/blob/master/proxy/http/remap/RemapConfig.cc#L987])
> However, when we use .include directives to include some other remap config
> files, there will be overlapping and conflict with the line numbers in each
> other file.
> *Examples*
> remap.config
> {noformat}
> .include remap1.config
> .include remap2.config
> {noformat}
> remap1.config
> {noformat}
> map /foo/ https://www.yahoo.com
> {noformat}
> remap2.config
> {noformat}
> map /foo/bar1 https://www.yahoo.com
> map /foo/bar2 https://www.yahoo.com
> {noformat}
> *Test Results*
> {noformat}
> $ curl "`hostname`/foo/" -I | grep HTTP
> HTTP/1.1 200 OK
> $ curl "`hostname`/foo/bar1" -I | grep HTTP
> HTTP/1.1 200 OK
> $ curl "`hostname`/foo/bar2" -I | grep HTTP
> HTTP/1.1 404 Not Found
> {noformat}
> When parsing remap1.config, first entry in remap1.config is inserted with
> rank 0, second with rank 1. Then parsing remap2.config, the single entry is
> inserted with rank 0 again. So the entry in remap2.config is overlapped with
> first entry in remap1.config and takes precedence with second entry. This
> would confuse customers.
> I'm considering using a global line number to count each entry, and follow
> the "first-match-wins" rules. I test with my local environment and it works.
> However, we are using the line number for debugging
> output([Github|https://github.com/apache/trafficserver/blob/master/proxy/http/remap/RemapConfig.cc#L938]),
> so the current count variant _cln_ is still needed. This would mess up the
> code. Appreciate for any suggestions to this issue.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
