GCP HTTP(S) Load Balancers convert HTTP/1.1 header names to lowercase in the request and response directions. See: https://cloud.google.com/load-balancing/docs/https/#target-proxies and search for "lowercase".
The HTTP/1.1 specification states that header names are case-insensitive, so this behavior should not affect existing backend APIs. However, if your backend API does expect a case-sensitive header name (e.g. Authorization) you can work around this in Apigee by creating a simple Assign Message:
<AssignMessage async="false" continueOnError="false" enabled="true" name="AM-case-sensitive-authorization">
<DisplayName>AM-case-sensitive-authorization</DisplayName>
<AssignVariable>
<Name>save_auth</Name>
<Ref>request.header.authorization</Ref>
</AssignVariable>
<Remove>
<Headers>
<Header name="Authorization"/>
</Headers>
</Remove>
<Set>
<Headers>
<Header name="Authorization">{save_auth}</Header>
</Headers>
</Set>
</AssignMessage>
Note that just using Set Header does not work when the request already has an "authorization" header, as would be the case in a simple pass through proxy.
Hope this helps!
Kurt, this is a handy tip. Did you find a system that does not comply with the HTTP spec and expects case-sensitive headers? if so, can you tell us anything more about that target system? Is it built on a well-known and perhaps widely-used library or platform? Can you "name names"? Or is it a special one-off?
The target was Axway and it was discovered when a proxy was migrated from classic Edge to Apigee X. Not sure if it is due to a standard configuration or special handling. I didn't find anything stating case sensitivity in the Axway docs to validate access token.
User | Count |
---|---|
1 | |
1 | |
1 | |
1 | |
1 |