I understand that sometimes a client will show an HTTP request as returning a 0 status code when the request fails to connect, timesout, etc, but I have never seen a server logging 0 as what it is sending back to the client.
I am running a Rails 4.2, ruby 2.2.x API. I was analyzing our logs the other day and noticed that a non-trivial number of requests were being responded with an HTTP status code of 0 by our Rails API. I have been unable to figure out why.
In some cases, it appears the request never makes it to the rails app. I only see the log message which I believe is logged by rack as to the request path and status returned. In other cases, I can see one of the early log messages we log from our application controller.
Has anyone seen such a behavior? I am not sure how to debug further without beginning to modify the standard rack middlewares that rails provides. I am not able to reproduce the situation myself; I only see this sporadically in our logs.
A bit more about our stack:
I realize it would probably be impossible to answer what exactly is happening here, so I am hoping instead for suggestions on how best to troubleshoot this.
HTTP StatusCode=0 is associated with incomplete capture of a hit or page and often with a labeling of the hit as: request canceled ("ReqCancelled=Client" "ReqCancelled=Server" or "ReqCancelled=True").
A status code of 0 in an NSHTTPURLResponse object generally means there was no response, and can occur for various reasons. The server will never return a status of 0 as this is not a valid HTTP status code.
200s: Success codes returned when browser request was received, understood, and processed by the server. 300s: Redirection codes returned when a new resource has been substituted for the requested resource. 400s: Client error codes indicating that there was a problem with the request.
Found that this is an issue with our Rails logging setup. By correlating these logs to our nginx access logs, I can see that a 302 is actually being returned to the client. This was commonly happening when the CSRF protection failed.
It looks like this is caused by a lograge (gem) bug: https://github.com/roidrage/lograge/issues/67
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With