Hey guys, thanks for your efforts on this great framework!
We encountered a known bug in Nginx 1.8.1 when responses are already sent back before the complete request was received. (See more info below.)
Can this behavior be triggered with using ServiceStack in version 4.0.50?
E.g. with having a global request filter which validates headers and sends responses directly.
When using upstream keepalive connections and the upstream server sends an error response while nginx is still transmitting the request body (of a request with a Content-Length header), nginx eventually stops transmitting the body (which may be before the full body has been transmitted) but continue to reuse the connection for further requests.
This in turn causes the next request on that connection to get “stuck” since the upstream server is seeing it as just more data for the prior request.
If it is possible to encounter this bug using ServiceStack then we may have to try upgrading to nginx 1.9.10+ which we would like to prevent for the time being.
Keep Alives / HTTP Connection pooling isn’t handled within ServiceStack (or other high-level Web Frameworks), it’s handled by the underlying HTTP Server implementation, e.g. mono’s ASP.NET / HttpListener impl which could be further impacted by how your hosting your App with nginx, e.g. if you’re using reverse proxying or using FastCGI or HyperFastCGI.
I couldn’t give you a definitive answer if your combination is impacted by this issue, you would need to test it to find out.
I have to be more precise: The request which is triggering the erroneous behaviour of nginx is basically leading to a timeout sent to the client, because nginx stops request/response handling. We’re seeing this timeout in our client, and are looking for a possible root cause, which could be the issue above.
The base question is: Is there any scenario where ServiceStack would send a response to a request whose body has not been read/received completely?
If yes, could it be configured not to do so?
If no, I guess we have to debug deep into this, with e.g. tcdump or similar, to find out how the request/response process looks like in case of the timeout errors we’re experiencing. Would you suggest other ways of debugging this?
(Before I just update to nginx 1.9.10 I want to be sure that this was the real issue).
For Services the body is normally always read in order to populate the Request DTO, however you can skip the body from being read by registering a Custom Request Converter or by telling ServiceStack to skip deserializing the Request body on Request DTO’s with IRequiresRequestStream.
You can also send requests with Request bodies to resources which aren’t services like Razor Views where if you didn’t specify a typed model, i.e. you’re using Pages with dynamic View Models then the Request body wouldn’t be read there either.