23

I've a REST API application running in two EC2 instance and was using AWS Classic Load Balancer for a long time. The clients of REST API rely on the response headers (e.g. such as Location).

I know that HTTP headers are case-insensitive by definition, however (unfortunately) some clients are ignoring this and checking the headers in a case-sensitive way (e.g. they expect Location to start with upper case).

Recently I've changed to AWS Application Load Balancer and now I see that it transforms all response headers to lower case, as a result clients are failing to handle the response properly.

I've couple of questions here.

  1. Is it expected behavior of Application Load Balancer?
  2. Is there a way to configure it to return headers as they have been built by the application?
vtor
  • 8,989
  • 7
  • 51
  • 67
  • "Recently I've changed to AWS Application Load Balancer and now I see that it transforms all response headers to lower case, as a result clients are failing to handle the response properly." This statement of yours helped me , I thought the load balancer was removing my headers but turned out they were making them lowercase...thanks – Nigel Fds Apr 09 '18 at 06:51

2 Answers2

21

It is an expected function of the ALB because HTTP/2 lowercases all headers and ALBs support HTTP/2. Unfortunately you can't modify how the headers are manipulated by the ALB.

Update: See the comments below. My statement that the ALB lowercases the request headers due to its support for HTTP/2 may not be accurate.

jzonthemtn
  • 3,344
  • 1
  • 21
  • 30
  • 7
    Testing indicates that this answer is partially incorrect or incomplete. When the request is being handled in HTTP/2 mode, ALB does indeed appear to coerce the headers to lowercase -- as it must -- but when the client isn't HTTP/2 capable, this coercion **does not** appear to happen... so it's not happening merely *because ALB supports* HTTP/2, but rather *because the client is using* HTTP/2. If a client is seeing lowercase headers, then it would appear that is necessarily the case that the client must be speaking HTTP/2 to the ALB... which means the client is broken if lowercase fails. – Michael - sqlbot Oct 05 '16 at 20:39
  • 1
    Does that indicate if the the REST clients are HTTP/1 then vtor's case-sensitive clients will function as expected? – jzonthemtn Oct 05 '16 at 20:51
  • 1
    It seems to indicate that, yes... so either the rest clients are HTTP/2 and have broken header interpretation, or the nature of the problem has been misidentified. – Michael - sqlbot Oct 05 '16 at 21:16
  • 1
    Thanks for looking so deep into it. – jzonthemtn Oct 05 '16 at 23:14
  • 1
    @Michael-sqlbot and jbird Thanks for the answers. The client indeed handles the headers in a wrong way (custom checks, etc) and they use HTTP2. – vtor Oct 06 '16 at 09:51
9

This was causing our broken clients to fail when we switched from TCP ELB to HTTPS ELB.

While we fix our clients, we temporarily disabled the new ELB HTTP/2 support, which comes enabled by default.

Disable HTTP/2 in the load balancer attributes

Bigger
  • 1,807
  • 3
  • 18
  • 28