-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add HeaderKind to enable setting request headers #165
Conversation
Signed-off-by: Adam Cattermole <[email protected]>
response_headers_to_add: Option<Headers>, | ||
request_headers_to_add: Option<Headers>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These have been renamed and are Option
that is initialised once and extended until it is taken. Crucially if this is None
it can no longer be initialised, we have added the headers and we are no longer in the correct phase
Signed-off-by: Adam Cattermole <[email protected]>
Signed-off-by: Adam Cattermole <[email protected]>
2f3b542
to
b709fda
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🍸
In the wasm-shim refactor the request vs response headers that was fixed prior (#143) was missed. I've introduced an enum called
HeaderKind
which explicitly differentiates theRequest
vsResponse
types for the specific actions, and have enforced that these can only be added at the correct phase.I've updated the authconfig to add request headers, so this is verifiable as follows:
See
My-Header
in the echoed request:Resolves #164