fix erroneous catching of protocol violation errors
When an API (wrongly) return a response body and a "204 No content" return code, a "500 protocol violation error" should be raised by APIM instance.
In fact it is the case, but the protocol violation error is raised as a response on the call folowing the erroneous "204" API, not the erroneous API itself. The error is raised only the following call (whatever API it is) that is implemented on the same backend of the "204" API AND if the folowing call is made in the same HTTP session (I mean during the http "keep alive" timeout).
This bug was confirmed by a support request but support team advised me to open an improvement subject since nothing could be do to corrrect the problem (the bug seems to be du to an embedded component of APIM).
Let me know if SR number would help.
Thank you for the feedback! We added this suggestion to the backlog and will update the item when we prioritize it for implementation.
We are facing the same issue.
do we have any solution for this
One of our TEST APIs is running on Azure Service Fabric. I am using Postman to call an API method using GET verb, and I get 200 Okay response. When I call the same method using HEAD verb, I get 405 Method Not Allowed error. If I call the method again using HEAD verb, I get 500 Internal Server Error. When HEAD verb is used for calling the API method, the reponse code keeps toggling between 405 and 500.
We are using Azure API management on our TEST environment. However I don't see anything in it which can cause this issue.
On my DEV environment when I call the same API method (Postman) using GET it returns 200 Okay response. Later when I call it using HEAD it consistently returns 405 Method Not Allowed response. We are NOT using APIM on DEV environment though the API is running on Azure Service Fabric.
Is Error code toggling due to the above mentioned Azure bug? Is there any plan to fix this anytime soon?