Describe the bug
If the incoming request to the content scanner includes Authorization header but the config file also has a hardcoded one (using additional_headers option) or it is being asked to forward (using headers_to_forward) then the header gets added to the upstream request multiple times making it fail, without any clear trace
To Reproduce
Steps to reproduce the behavior:
- Configure a hardcoded
Authorization header in config with additional_headers.
- Send a request to content scanner with
Authorization header.
or
- Configure the
Authorization header in config to be forwarded with headers_to_forward.
- Send a request to content scanner with
Authorization header.
Expected behavior
At all times, use at most one copy of the Authorization header in the upstream request. If there is a hardcoded one in the config (additional_headers), use this one instead of one in the incoming request - and indicate that in the logs.
Actual behavior
The request fails, there is nothing in the logs which could help you to debug the issue.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
- OS: [e.g. iOS]
- Browser [e.g. chrome, safari]
- Version [e.g. 22]
Smartphone (please complete the following information):
- Device: [e.g. iPhone6]
- OS: [e.g. iOS8.1]
- Browser [e.g. stock browser, safari]
- Version [e.g. 22]
Additional context
Add any other context about the problem here.
Describe the bug
If the incoming request to the content scanner includes
Authorizationheader but the config file also has a hardcoded one (usingadditional_headersoption) or it is being asked to forward (usingheaders_to_forward) then the header gets added to the upstream request multiple times making it fail, without any clear traceTo Reproduce
Steps to reproduce the behavior:
Authorizationheader in config withadditional_headers.Authorizationheader.or
Authorizationheader in config to be forwarded withheaders_to_forward.Authorizationheader.Expected behavior
At all times, use at most one copy of the
Authorizationheader in the upstream request. If there is a hardcoded one in the config (additional_headers), use this one instead of one in the incoming request - and indicate that in the logs.Actual behavior
The request fails, there is nothing in the logs which could help you to debug the issue.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):
Smartphone (please complete the following information):
Additional context
Add any other context about the problem here.