Fix transform response context containing wrong rewrite path

[PatrickTaibel]

Description

Changes the path context variable set by the url rewrite middleware to the correct value.

Related Issue

• #3858

Motivation and Context

When using regex to match paths within the url rewrite middleware, the path provided to response transform middlewares is unusable. It should get the path before the url rewriting takes place but instead it is provided with the specified path value of the url rewrite middleware (which includes all specified regex symbols).To use it like that, one would need to build a regex for matching another regex pattern.

How This Has Been Tested

See below for the relevant parts of the config. In general, it's simply a url_rewrites section combined with a transform_response_headers section using regex for matching paths. After applying the fix this config works flawless.

extended_paths:

"extended_paths": {
    "transform_response_headers": [
      {
        "delete_headers": null,
        "add_headers": {
          "Server": "mock-server",
          "x-completely-new": "Hello World",
        },
        "path": "^/test-1/override",
        "method": "GET",
        "act_on": false
      },
      {
        "delete_headers": [
          "x-completely-new",
          "Server"
        ],
        "add_headers": null,
        "path": "^/test-1/delete",
        "method": "GET",
        "act_on": false
      },
      {
        "delete_headers": [
          "Server"
        ],
        "add_headers": {
          "Content-Type": "text/plain"
        },
        "path": "^/test-1/all",
        "method": "GET",
        "act_on": false
      }
    ],
    "url_rewrites": [
      {
        "path": "^/test-1",
        "method": "GET",
        "match_pattern": "^/API-SLUG/test-1/(.*)$",
        "rewrite_to": "http://mock-api/headers.php",
        "triggers": null
      }
    ]
  }

response_processors:

"response_processors":[{"name": "header_injector"}]

Screenshots (if appropriate)

Types of changes

• [x] Bug fix (non-breaking change which fixes an issue)
• [ ] New feature (non-breaking change which adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to change)
• [ ] Refactoring or add test (improvements in base code or adds test coverage to functionality)

Checklist

• [x] Make sure you are requesting to pull a topic/feature/bugfix branch (right side). If pulling from your own fork, don't request your master!
• [x] Make sure you are making a pull request against the master branch (left side). Also, you should start your branch off our latest master.
• [ ] My change requires a change to the documentation.
  • [ ] If you've changed APIs, describe what needs to be updated in the documentation.
  • [ ] If new config option added, ensure that it can be set via ENV variable
• [ ] I have updated the documentation accordingly.
• [ ] Modules and vendor dependencies have been updated; run go mod tidy && go mod vendor
• [ ] When updating library version must provide reason/explanation for this update.
• [ ] I have added tests to cover my changes.
• [ ] All new and existing tests passed.
• [ ] Check your code additions will not fail linting checks:
  • [ ] go fmt -s
  • [ ] go vet

[buger]

Appologies we missed this PR somehow!

If you can add test case for this will be great. You can take inspiration from the examples which I posted to your another PRs (you rock!), plus this is how to initialize API with a complex Extended paths in tests: https://github.com/TykTechnologies/tyk/blob/master/gateway/mw_validate_json_test.go#L35

Thanks!

[PatrickTaibel]

I've adjusted the existing tests for the HeaderInjector response middleware to include this kind of url rewriting too. Additionally, I've added a check for the urlRewritePath context in the TestRewriter to ensure the correct handling in the url rewrite middleware.