fix(proxy): restore header forwarding through redirects when byte-metering transport is active#6282
Conversation
…ering transport is active
|
I’m tempted to remove the metric, and set forward headers to
|
Hmm, I guess it comes down to what the correct thing (product-wise) is: should we or should we not forward headers on redirects? If so, I'd say keep it. |
This was originally added for Dayforce only. Since its not good to forward headers with redirects we added a metric to count the number of providers that need to use this so that when we flip the switch we can only define them in the providers config as |
There was a problem hiding this comment.
2 issues found across 3 files (changes from recent commits).
Prompt for AI agents (unresolved issues)
Check if these issues are valid — if so, understand the root cause of each and fix them. If appropriate, use sub-agents to investigate and fix each issue separately.
<file name="packages/server/lib/controllers/proxy/allProxy.ts">
<violation number="1" location="packages/server/lib/controllers/proxy/allProxy.ts:214">
P1: This drops the previous default for redirect header forwarding. When callers omit the header, existing proxy requests now fall back to `false`, so auth/custom headers stop being restored after redirects unless the provider config explicitly opts in.</violation>
</file>
Tip: Review your code locally with the cubic CLI to iterate faster.
Fix all with cubic | Re-trigger cubic
Describe the problem and your solution
beforeRedirectcallback into the metering transport so forwaded headers can be restored correctly across redirects, this is needed for providers like dayforce.