Skip to content
By using AWS re:Post, you agree to the AWS re:Post Terms of Use
AWS re:Postre:Post
About re:Post

502 error from ALB for some APIs only..

0

In the ALB, we have HTTP2 configured and we know that the target group supports HTTP1.1. So, we expect automatic negotiation with target. However, we are seeing one kind of API consistently fail with 502 error while all other APIs pass. The failure is observed in a POST API call without any body and the expected response also is a 204. Other POST & PUT calls with body and GET calls are successful. What does this indicate ? Is there a known issue with ALB with HTTP2 ?

The headers captured of a successful call are below. This responds with 201 which is expected and Content-Length:0 in response header

PUT https://<url1> h2
ML-Agent-ID: java
Authorization: Basic <BASE64>
Content-Type: application/json
Transfer-Encoding: chunked
Host: <deleted>
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/4.11.0

The headers captured from a failed call are below. (basically same, but this has no body). This responds with 502, but expected is a 204 and Content-Length:0

POST https://<url2> h2
ML-Agent-ID: java
Authorization: Basic <BASE64>
Transfer-Encoding: chunked
Host: <deleted>
Connection: Keep-Alive
Accept-Encoding: gzip
User-Agent: okhttp/4.11.0

A related post was found in [https://repost.aws/questions/QUGQaTng98SV-70vUa2DzNLg/is-it-possible-for-alb-listener-to-support-both-http2-and-http1-1]

Topics
Networking & Content Delivery
Tags
Elastic Load Balancing
Language
English
asked 9 months ago68 views
1 Answer
0

AWS ALB supports HTTP/2 for clients, but by default it communicates with the target group using HTTP/1.1. HTTP/2 does not require a Content-Length: 0 header for empty bodies, but HTTP/1.1 does require it.

Therefore, can you try explicitly set the Content Length to 0 when it is 0. Alternatively, set the protocol version of the ALB to allow HTTP/2.

EXPERT
answered 9 months ago
  • BG
    9 months ago

    The problem is we are not building the API, but using a Java Client and some APIs exposed by it. The Java Client is using okhttp as the client. The Java API's behavior is to add Transfer-Encoding:chunked to the header even though the request body is zero-length. The problem is happening only on APIs with *Transfer-Encoding:chunked + zero-length body. * Below are working fine

    •       Content-Length:0 + zero-length body 
     Content-Lengh:<calculated> + non-zero length body
     Transfer-Encoding:chunked + non-zero length body

    The problem got resolved when ALB was updated to HTTP1.1 (ie. HTTP1.1 communication end-to-end). Alternatively, set the protocol version of the ALB to allow HTTP/2. --> Not sure whether I get it. If the suggestion is to set HTTP/2 from ALB to backend, my backend is not ready for HTTP/2. If the suggestion is to allow HTTP/2 from client to ALB, that was the case when the problem appeared. It got resolved when we made HTTP1.1 from client to ALB.

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Relevant content