This pull request introduces original_path and listen_path to the gateway's observability data, ensuring the unmodified client request path is captured and propagated to analytics, access logs, and OpenTelemetry traces.

Files Changed Analysis

The changes span 21 files, with a significant portion of the 664 new lines dedicated to testing. The addition of gateway/original_path_analytics_test.go (460 lines) and other smaller test files demonstrates a thorough approach to validation, covering various edge cases like path stripping, URL rewriting, and backward compatibility.

The core logic is concise and implemented as a vertical slice through the request pipeline:

• The original path is captured at the request entry point (gateway/proxy_muxer.go).
• A new context key, OriginalRequestPath, is defined in ctx/ctx.go to propagate the value.
• The value is consumed by analytics handlers (gateway/handler_success.go, gateway/handler_error.go), access logging (internal/httputil/accesslog/record.go), and tracing middleware (gateway/middleware.go).
• The go.mod is updated to a newer version of tyk-pump, which contains the updated AnalyticsRecord struct definition.

Architecture & Impact Assessment

• What this PR accomplishes: It provides crucial visibility into the original client request path before any gateway-level modifications (like path stripping or URL rewrites). This enriches observability data, enabling more accurate debugging, metrics, and usage analysis.

• Key technical changes introduced:

  1. Path Capture: The request's URL.Path is captured in proxy_muxer at the very beginning of the request lifecycle.
  2. Context Propagation: A new key, ctx.OriginalRequestPath, is used to store and pass the original path through the middleware chain.
  3. Analytics Enrichment: The AnalyticsRecord (from the tyk-pump dependency) is populated with the new OriginalPath and ListenPath fields.
  4. Access Log Integration: The structured access log now includes an original_path field.
  5. Trace Enhancement: OpenTelemetry spans are decorated with a tyk.original_path attribute for improved trace analysis.

• Affected system components: The change touches the request handling entrypoint, context management, and the entire observability stack (analytics, logging, and tracing).

Request Path Observability Flow

graph TD
    A[Client Request<br>e.g., /api/v1/users] --> B{gateway/proxy_muxer.go};
    B --> C["Capture r.URL.Path<br>Store in request context via ctxSetOriginalRequestPath"];
    C --> D{"Middleware Chain<br>(Path Stripping, URL Rewrites, etc.)"};
    D --> E[Backend Request];

    subgraph Observability Layers
        C --|Read from context|--> F[Analytics Handlers];
        F --|Populate new fields|--> G[Analytics Record<br>OriginalPath: /api/v1/users<br>ListenPath: /api/v1/];

        C --|Read from context|--> H[Access Log Middleware];
        H --|Add new field|--> I[Access Log Record<br>original_path: /api/v1/users];

        C --|Read from context|--> J[Tracing Middleware];
        J --|Add new attribute|--> K[OTel Span<br>tyk.original_path: /api/v1/users];
    end

Scope Discovery & Context Expansion

This PR implements a well-contained vertical feature slice. It enhances the data quality of existing observability systems without altering core request processing logic. The impact extends from the gateway's entry point to all downstream observability consumers.

The update to the tyk-pump dependency in go.mod is critical, as it brings in the necessary changes to the analytics.AnalyticsRecord struct to support the new fields. The extensive tests, particularly the backward compatibility checks in gateway/original_path_analytics_test.go, confirm that existing fields like Path and RawPath are unaffected, ensuring this is a non-breaking change for existing analytics consumers.

Powered by Visor from Probelabs

Last updated: 2026-06-09T16:38:54.587Z | Triggered by: pr_updated | Commit: 3f0c9fe

💡 TIP: You can chat with Visor using /visor ask <your question>

Security Issues (2)

Architecture Issues (2)

✅ Performance Check Passed

No performance issues found – changes LGTM.

Quality Issues (1)

Powered by Visor from Probelabs

Last updated: 2026-06-09T16:38:47.869Z | Triggered by: pr_updated | Commit: 3f0c9fe

💡 TIP: You can chat with Visor using /visor ask <your question>

API Changes

--- prev.txt	2026-02-20 20:46:05.845362158 +0000
+++ current.txt	2026-02-20 20:45:56.385325381 +0000
@@ -6166,7 +6166,9 @@
 	//
 	// Template Options:
 	//
+	// - `api_id` will include the API ID.
 	// - `api_key` will include the obfuscated or hashed key.
+	// - `api_name` will include the API name.
 	// - `circuit_breaker_state` will include the circuit breaker state when applicable.
 	// - `client_ip` will include the IP of the request.
 	// - `error_source` will include the source of an error (e.g., ReverseProxy).
@@ -6176,6 +6178,7 @@
 	// - `latency_total` will include the total latency of the request.
 	// - `method` will include the request method.
 	// - `org_id` will include the organization ID.
+	// - `original_path` will include the original request path before URL rewrites.
 	// - `path` will include the path of the request.
 	// - `protocol` will include the protocol of the request.
 	// - `remote_addr` will include the remote address of the request.
@@ -8583,6 +8586,8 @@
 	JSONRPCRoutingState
 	// MCPRouting indicates the request came via MCP JSON-RPC routing
 	MCPRouting
+	// OriginalRequestPath stores the original request path before any middleware modifications
+	OriginalRequestPath
 )
 # Package: ./dlpython
 
@@ -9719,11 +9724,6 @@
 
 func (s *APISpec) FireEvent(name apidef.TykEvent, meta interface{})
 
-func (a *APISpec) GetPRMConfig() *oas.ProtectedResourceMetadata
-    GetPRMConfig returns the Protected Resource Metadata configuration if the
-    API is an OAS API Definition (OAS API, MCP Proxy, Stream API) with PRM
-    enabled. Returns nil otherwise.
-
 func (a *APISpec) GetSessionLifetimeRespectsKeyExpiration() bool
     GetSessionLifetimeRespectsKeyExpiration returns a boolean to tell whether
     session lifetime should respect to key expiration or not. The global config
@@ -9793,7 +9793,7 @@
 
 func (k *AuthKey) Name() string
 
-func (k *AuthKey) ProcessRequest(w http.ResponseWriter, r *http.Request, _ interface{}) (error, int)
+func (k *AuthKey) ProcessRequest(_ http.ResponseWriter, r *http.Request, _ interface{}) (error, int)
 
 type AuthORWrapper struct {
 	BaseMiddleware
@@ -11555,21 +11555,6 @@
 
 func (k *OrganizationMonitor) SetOrgSentinel(orgChan chan bool, orgId string)
 
-type PRMMiddleware struct {
-	*BaseMiddleware
-}
-    PRMMiddleware intercepts GET requests to the PRM well-known path and serves
-    the OAuth 2.0 Protected Resource Metadata document (RFC 9728). It runs
-    after MiddlewareContextVars (so $tyk_context.* is available) but before
-    authentication middlewares, allowing the endpoint to be accessed without
-    auth.
-
-func (m *PRMMiddleware) EnabledForSpec() bool
-
-func (m *PRMMiddleware) Name() string
-
-func (m *PRMMiddleware) ProcessRequest(w http.ResponseWriter, r *http.Request, _ interface{}) (error, int)
-
 type PersistGraphQLOperationMiddleware struct {
 	*BaseMiddleware
 }

/review The original request path is captured before any middleware processing. This means if the path contains sensitive information (e.g., session tokens, PII, API keys), it will be recorded in plaintext in logs, analytics, and traces. This bypasses any subsequent middleware that might have been designed to strip or obfuscate such sensitive data from the request before it is recorded. The feature's design, as confirmed by tests, intentionally avoids normalization for this field, increasing the risk of persisting sensitive data.. this is already how this works today in rawPath

/review The go.mod file contains a replace directive that points to a local directory (../tyk-pump). This makes the project's build dependent on a specific local file structure, which breaks reproducible builds for CI/CD systems and other developers. Local replace directives should not be merged into the main branch.

i have reverted the changes to go.mod and "replace", i removed them

Powered by Visor from Probelabs

Last updated: 2026-02-18T20:55:05.737Z | Triggered by: sedkis | Commit: ee893a5

💡 TIP: You can chat with Visor using /visor ask <your question>

Thank you for confirming the removal of the local replace directive from go.mod. This resolves the concern about reproducible builds.

Powered by Visor from Probelabs

Last updated: 2026-02-18T20:23:54.270Z | Triggered by: sedkis | Commit: ee893a5

💡 TIP: You can chat with Visor using /visor ask <your question>

Thank you for pointing out this important security consideration. You are correct that original_path is captured before any middleware processing, which means it will not be sanitized by subsequent middleware.

This behavior is intentional and consistent with how the existing rawPath field works. The goal of this feature is to provide the unmodified, original request path for observability and debugging, especially in scenarios involving path stripping or URL rewriting.

The test TestOriginalPathAnalytics_BackwardCompat_NormalisePathDoesNotAffectOriginalPath in gateway/original_path_analytics_test.go confirms that normalization logic is deliberately not applied to OriginalPath to ensure the raw value is preserved.

We acknowledge the risk of persisting sensitive data, and this behavior requires that operators are aware of what information they are logging.

References:

• gateway/proxy_muxer.go:70 – Path capture location
• gateway/original_path_analytics_test.go:434-458 – Test confirming no normalization

Powered by Visor from Probelabs

Last updated: 2026-02-18T20:24:00.144Z | Triggered by: sedkis | Commit: ee893a5

💡 TIP: You can chat with Visor using /visor ask <your question>

/review The original request path is captured from user input (r.URL.Path) and propagated to downstream observability systems (logs, analytics, traces) without sanitization. This could lead to a stored Cross-Site Scripting (XSS) vulnerability if the consuming systems do not properly escape this value before rendering it in a U

WE follow existing implementation for RawPath and Path, we dont sanitize for XSS, we trust the UI to sanitize accordingly.

Thank you for the clarification. You are correct that this approach aligns with the existing strategy for handling RawPath and Path, where the raw, unsanitized request path is captured at the gateway.

This ensures that the original, unmodified path is available for accurate logging and analytics. The responsibility for context-aware escaping and sanitization correctly lies with the downstream systems (e.g., Tyk Dashboard, logging UIs) that consume and render this observability data.

References:

• gateway/proxy_muxer.go:70 – Captures the original request path.
• gateway/handler_success.go:278 – Shows the existing pattern for RawPath.
• gateway/handler_error.go:180 – Shows the existing pattern for RawPath in error handlers.

Powered by Visor from Probelabs

Last updated: 2026-02-18T20:54:58.194Z | Triggered by: sedkis | Commit: ee893a5

💡 TIP: You can chat with Visor using /visor ask <your question>

CI needs to be re-triggered after PUMP is merged, and the go.mod bumped

@sedkis can you please resolve the conflicts? 🙏

🎯 Recommended Merge Targets

Based on JIRA ticket TT-7519: [Innersource] Include original request path in analytics

Fix Version: Tyk 5.14.0

⚠️ Warning: Expected release branches not found in repository

Required:

• master - No matching release branches found. Fix will be included in future releases.

📋 Workflow

1. Merge this PR to master first

🚨 Jira Linter Failed

Commit: 3f0c9fe
Failed at: 2026-06-09 16:37:43 UTC

The Jira linter failed to validate your PR. Please check the error details below:

failed to get Jira issue: failed to fetch Jira issue TT-7519: Issue does not exist or you do not have permission to see it.: request failed. Please analyze the request body for more details. Status code: 404

Next Steps

• Ensure your branch name contains a valid Jira ticket ID (e.g., ABC-123)
• Verify your PR title matches the branch's Jira ticket ID
• Check that the Jira ticket exists and is accessible

This comment will be automatically deleted once the linter passes.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
95.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud