You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Feifei Cai (JIRA)" <ji...@apache.org> on 2014/10/08 11:56:34 UTC
[jira] [Created] (TS-3120) Overlapping rank in config.remap when
using .include directives
Feifei Cai created TS-3120:
------------------------------
Summary: 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
Reporter: Feifei Cai
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)