Application Load Balancer does not always send back header
I have my application load balancer configured to pass back the Strict-Transport-Security header. I can see this working when my API returns content with a 200 Http status code. However, sometimes my API sends back a 409. In this instance my API processed the transaction successfully (from a technical standpoint) but the client simply sent up data which conflicts with data already on the server. Thus, I send back the Http status 409 - conflict, along with a response body detailing the error. But in this case, the load-balancer is not sending back the Strict-Transport-Security header, as I've configured it. As far as I can see, there is nothing in the spec which restricts this header to a transaction which returns Http 200. So why is this not being sent?
- Newest
- Most votes
- Most comments
The behavior you're experiencing with the Application Load Balancer (ALB) not sending the Strict-Transport-Security header for 409 responses is a known limitation of the ALB's header modification feature. By default, ALB only adds custom headers to successful responses, which typically include 2xx and 3xx status codes.
This limitation is not related to the HTTP specification, as you correctly pointed out. The Strict-Transport-Security header can indeed be sent with any HTTP status code. However, the ALB's implementation currently restricts the addition of custom headers to successful responses only.
To address this issue, you have a few options:
-
Handle CORS and security headers at the application level: Implement the header addition logic in your API code. This ensures that all responses, regardless of status code, include the necessary headers.
-
Use AWS CloudFront in front of your ALB: CloudFront allows you to add custom headers to all responses, including error responses. You can configure CloudFront to add the Strict-Transport-Security header to all responses, regardless of the status code.
-
Use a custom error page: Configure your ALB to use a custom error page for non-2xx responses. This custom error page can include the necessary security headers.
-
Consider using a Lambda@Edge function with CloudFront: This approach gives you more flexibility in managing headers for all types of responses.
While these workarounds can help, it's worth noting that AWS periodically updates its services. You may want to keep an eye on AWS announcements or reach out to AWS support to inquire about potential future enhancements to the ALB's header modification capabilities for non-2xx responses.
Sources
ALB Listener Attributes: Headers Missing in Non-2XX Responses | AWS re:Post
HTTP header modification for your Application Load Balancer - Elastic Load Balancing
