Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[gateway] API gateway is not forwarding HTTP/1.1 error code statustext in response header #2381
I have created a small test setup for this issue so it's easier to follow. In my test scenario i have a Apache/php endpoint microservice and a simple java-script Ajax frontend who calls it via the API gateway. We use HTTP error codes+status text to create a fast error reporting back to the client/frontend so that we don't have to send any body content. So if the microservice is fine it will return JSON body content, if it fails it will only return a response header with a HTTP error code and custom error text.
Let's say we are looking up customer data but the customer ID was not found, then we use code 404 but we have multiple use cases for 404 so we also rely on the status text for that 404.
So etc if Customer ID was not found we would return the following from PHP.
So etc if Customer Email was not found we would return the following from PHP.
This works fine if we are talking directly to the endpoint via our frontend java-script calls.
What we see when going though the Gravitee API gateway is that it somehow sanitizes or changes the response header error message.
We are sending: HTTP/1.1 404 Customer ID not found
This will cripple our frontend as we now can't distinct between error messages for when queries are not found etc.
Have a toggle switch to disable "sanitation" of HTTP error codes ?
Steps to Reproduce (for bugs)
Sadly i can't provide live examples as our gateway is on the internal network.
But a simple way to reproduce is to setup a Apache/php endpoint with one file and one line in it.
It affect us in the way that we can't create stateless fast error replies via our endpoints with custom error messages. We don't want overhead that's why we don't send body content when doing error reporting, but you are still allowed to change the HTTP/1.1 custom error text. This is a normal use case scenario. So it's unfortunately that the API gateway is stopping this behavior.
It's running in a Openshift environment.