My backend is sensitive to the letter case of header names; does TR7 change them (Keep Header Names / HTTP 1.0 Header Compatibility)?

Short answer

Yes. TR7 forwards header names by converting them to lowercase; according to the HTTP standard, header names are case-insensitive, but some legacy applications expect a specific spelling. The Keep Header Names action preserves header names in the spelling they arrive in from the client and, for this, turns off HTTP/2 and HTTP/3 on the vService. The HTTP 1.0 Header Compatibility action, on the other hand, forwards the headers written in the Headers to Fix list in the spelling in that list and does not turn off HTTP/2; adding or removing this action, or changing its list, restarts the vService.

How Does It Work?

1. The client sends a request with the Content-Type: text/xml header.
2. While processing the request, TR7 keeps the header names in lowercase and forwards it to the Backend Service as content-type: text/xml; the headers in the response also return to the client in lowercase.
3. In HTTP/1.1 (RFC 9110 · 5.1) and HTTP/2, the header name is case-insensitive; applications that comply with the standards do not see this difference. In legacy applications that expect a specific spelling, one of the two actions is used:
   • Keep header names: The names are forwarded in the spelling they arrive in from the client. Since the spelling can be preserved only in HTTP/1.1, HTTP/2 and HTTP/3 of the vService and the HTTP/2 connection to the Backend Service are turned off.
   • HTTP 1.0 Header Compatibility: The headers in the list are forwarded in the spelling in the list, whatever spelling they arrive in from the client; it is applied on HTTP/1.x connections both in requests going to the Backend Service and in responses returning to the client.

Comparison

	Keep Header Names	HTTP 1.0 Header Compatibility
Source of the spelling	The form sent by the client	The form in the Headers to Fix list
Which headers	All headers	Only those in the list
Form field	None	Headers to Fix (comes filled with a ready list: Accept, Authorization, Content-Type…; one header per line)
HTTP/2 and HTTP/3	Turned off on the vService	Stay on; the correction is made on HTTP/1.x connections
Per vService	At most 1	No limit
When added / changed	Open connections are kept	The vService is restarted; open connections are dropped
vService type	HTTP	HTTP

Keep Header Names and HTTP 1.0 Header Compatibility in TR7

• Both actions are selected from the Action Type list with Load Balancer → Actions → Add (how to add); they take no condition or Execution level, and once added to the Actions field of the vService, they are applied to all traffic.
• When Keep Header Names is added, the protocols that are turned off are listed in the vService status information with the message Keep header names is active on this vService: … turned off (header-name case is only preserved on HTTP/1.1). If the Core Engine version of the vService does not support the feature, the action is not applied and this is indicated in the status information.
• The HTTP 1.0 Header Compatibility list is read only when the vService starts; for this reason, adding or removing the action and every change to the list restart the vService (When does a change I make take effect; does it go live as soon as I save it?). The change is made outside peak hours.
• In a cluster, the change is also sent to the peer device with the default auto-sync; if Manual Sync Mode is on, it is sent with Synchronize.
• The result is verified by turning on Debug on the vService and checking the spelling of the header names in the access log of the Backend Service or in the curl -v output.

Which One to Choose?

• HTTP 1.0 Header Compatibility if the Backend Service is sensitive to the spelling of only a few headers and HTTP/2 is to be kept.
• Keep Header Names if it is not known which headers are affected, or if all headers must be forwarded in the form sent by the client.

Common Misconceptions

• "HTTP 1.0 Header Compatibility is only for HTTP/1.0 clients." Despite its name, it also works on HTTP/1.1 connections.
• "Writing in lowercase in the list is enough." A header is forwarded in the form in which it was written in the list; if Content-Type is expected, Content-Type is written in the list.
• "Keep header names does not affect HTTP/2." On the vService to which the action is added, HTTP/2 and HTTP/3 are turned off; clients connect with HTTP/1.1.
• "A name written with Set HTTP header goes as is." Header names added with the action are also converted to lowercase; one of these two actions is needed to preserve the spelling.

How it is done in the documentation

• Keep Header Names · What Is the Keep Header Names Action?
• HTTP 1.0 Header Compatibility · Headers to Fix
• HTTP 1.0 Header Compatibility · How Does It Work?

Related questions

• Can I add, remove or change HTTP Headers in a request or response?
• When does a change I make take effect; does it go live as soon as I save it?
• Is HTTP/2 supported?