Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Rails server returning HTTP status 0

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:

  • Rails 4.2.5
  • Ruby 2.2.3
  • Puma 3.4.0
  • We are reverse proxying with nginx, but I dont think is effecting it since the request is received by rack at least.

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.

like image 990
Brad Avatar asked Feb 09 '17 16:02

Brad


People also ask

What does HTTP Status 0 mean?

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").

Is 0 a valid HTTP status code?

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.

What status code is returned by a Web site when the browser request is S?

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.


1 Answers

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

like image 128
Brad Avatar answered Oct 03 '22 17:10

Brad