Rewrite URL before all remap plugins run #4964
Conversation
|
[approve ci autest] |
|
We would need this for 8.x presumably ? |
|
@zwoop this is still an incompatible change similarly to the previous attempt to fix this problem in PR #4531. Although this PR hopes to make the plugin API more consistent from plugin developer's point of view ( Also marked |
SolidWallOfCode
left a comment
SolidWallOfCode
left a comment
There was a problem hiding this comment.
I this makes the API more consistent, in that each plugin sees the remap results of the previous one, and treats the core as the "first" remap plugin. Otherwise, as @gtenev points out, the first remap plugin is still special in not seeing any previous remapping occur. This is philosophically more consistent with other such modifications, e.g. TLS certificates. The core does its thing, then plugins can modify that result.
|
[approve ci] |
|
[approve ci] |
Rewriting the url *before* running all plugins instead of *after* which would guarantee that: - all plugins would get the same TSRemapRequestInfo::reqiestUrl (first plugin in the chain would not be special) - all plugins would treat TSRemapRequestInfo::reqiestUrl the same way consistently as a *remapped* URL which makes the first plugin really not different from the rest - there would be a remapped URL default in case the remap rule had no plugins OR none of the plugins modifed the mapped URL Also turning off url_sig and cookie_remap plugin unit-tests impacted by this not backwards compatible change.
|
@SolidWallOfCode would you reiterate your approval? Dismissed your previous approval by pushing changes to the PR branch, disabling unit-tests for |
|
This is an incompatible change and can't go into 8.x |
When the plugin does not use @pparam=pristineurl it should work with the remapped url. The code already does this but the unit-test still tests the signing of the pristine url in those specific use cases. This is related to a behavior change with v9.0 where the 1st plugin gets the remapped url as a remap API requestUrl regardless of its possition in the plugin chain (PR #4964).
4 participants
Rewriting the url before running all plugins instead of after
which would guarantee that:
TSRemapRequestInfo::reqiestUrl(first plugin in the chain would not be special)
TSRemapRequestInfo::reqiestUrlthe sameway consistently as a remapped URL which makes the first plugin
really not different from the rest
no plugins OR none of the plugins modifed the mapped URL