This change broke the cookie_remap plugin and so I am fixing it.
Should I use the pristine URL to get the HTTP headers or the remapped url
(rri)?
Since now the remapped url is the 'before' url I think they would always
yield identical results.
I am curious what's the recommended way?
On Tue, Feb 1
Seems reasonable to me.
On Wed, Feb 13, 2019 at 12:42 PM Souza, Dylan (Contractor) <
dylan_so...@comcast.com> wrote:
> I would agree with this proposal. I am currently writing a plugin in which
> I am running into the exact issues outlined here.
>
> On 2019/02/11 21:05:40, "Zelkowitz, Evan" e...
I would agree with this proposal. I am currently writing a plugin in which I am
running into the exact issues outlined here.
On 2019/02/11 21:05:40, "Zelkowitz, Evan"
mailto:e...@comcast.com>> wrote:
> Id agree with this. Its easy enough to always get the pristine url by just
> making the api c
Id agree with this. Its easy enough to always get the pristine url by just
making the api call. However getting the remapped url is not as easy. So it
makes sense that the remapped becomes the default and if any plugin needs the
pristine then it can get it anyway
On 2/11/19, 1:42 PM, "Gancho
I looked into the issues #4929, #4026, #2877 and PR #4531 which are all related
to this proposal about TSRemapRequestInfo::requestUrl (requestUrl for short)
and plugin ordering and I would like to revive the thread. (links to issues,
PRs, IRC logs referenced at the end of this email)
I definit
This came up again on IRC. The effect of the PR is
Before:
If the first remap plugin does not do a remap, then the URL is remapped to
the "from" URL in the remap rule, then the rest of the remap plugins run.
After:
All remap plugins are run, and if *none* of them remap, then the "from" URL
from t
Thank you. This is exactly what I want to fix.
2018/12/02 21:59 に、"宋辰伟" <616955...@qq.com> を書き込みました:
Actually there is a problem that URL is only overwritten in first plugin in
current logic. That means the request_url is overwritten in first plugin(which
return NO_REMAP ) and never chan
Actually there is a problem that URL is only overwritten in first plugin in
current logic. That means the request_url is overwritten in first plugin(which
return NO_REMAP ) and never changed even if the remain plugin set map_to or
map_form, except you set request_url directly. If my understandi
I don’t normally comment, but feel like I need to chime in here.
I agree in keeping with the stack behavior. This change has the potential to
break a lot of plugin logic and will cause a lot of work across many dev teams
that maintain many plugins. The pristine URL should be used in subsequent
I’d like to take a little step back ask about what is the root causing about
this change:
in the origin design
1, the remap plugin works in ordered, which means you can stop(consider it
done) remapping at any plugin if you want, and the following plugins will not
run after.
2, the remap plu
We had a discussion on the IRC about this and we agree that treating the first
plugin special is not a good idea and is confusing. I looked at the code and
approved the PR. I would like to get someone else to look at it too before
merging it, since it is an important change to the code.
Thank
Hi,
I’d like to propose a change about the timing that ATS runs remap plugins.
Currently, we configure remap.config like the following snippet,
and each plugins use `rri->requestUrl`,
the behavior of a remap plugin as the first plugin is different from that as
the second plugin.
```
map http://
12 matches
Mail list logo
