F5 XC 503 upstream_reset_before_response_started{protocol_error}
Hello Community, I would like to share some additional information regarding the 503 response code in F5 XC. When the origin server sends a response to XC that is not compliant with HTTP RFC standards, the platform may return a 503. For example, if the origin server responds with a 204 status code but includes a message body, Envoy (the underlying data plane) will treat this as RFC non-compliant and therefore block the content. As a result, XC will return a 503 response to the client. 503 upstream_reset_before_response_started{protocol_error} Check if the http response headers from the origin-server have any invalid field names. Query the the origin-server directly via cURL or something equivalent. Usually indicates that XC is seeing an error in one of the http-headers of the response from the server. We would need to see the http headers that the origin-server is responding with to identify the issue. In one of the scenarios, it was seen that the origin-server may have a total of more than 100 headers (mostly duplicate headers), which XC will treat as failure parsing the response.
SOAP HTTPS redirects not working (Postman / SoapUI)
Hello, I am using the Postman application, as well as SoapUI, to test some SOAP requests to an application that is behind our F5 WAF. When I send SOAP HTTPS POST requests, the WAF handles the request perfectly and all tests pass. However, when I send these requests over HTTP, tests do not succeed and I get an HTTP 500 error. To be clear, I have the default F5 iRule attached to the virtual server to redirect HTTP requests to HTTPS, and it does work. If I make a request to the site through the browser over HTTP, it gets sent to HTTPS. As another side note of troubleshooting, I have seen old threads that mention the Postman Interceptor Chrome extension being necessary for some API testing. I have installed it, turned it on, and I still get the same issues. My next step was turning on HTTP Analytics logging and looking at some of these requests to see if I could spot a difference between where we force HTTPS and where we leave it as HTTP. From what I can tell, it looks like every HTTP 500 response shows that it was a GET request... which is wrong, because the tests are configured as an HTTP POST. So to me it seems like the WAF is redirecting the HTTP POST to an HTTPS GET, which is why we get the 500 response code. Does this sound like anything someone has seen before? Any insight as to why this is occurring is appreciated.