Bug: 502 bad gateway on 3.10

[Matthijs]

The new update got installed with composer update. But I got a strange 502 bad gateway error for my ajax requests.

I couldn't figure out the problem at first, so I tried to rollback some composer updates and it looks like that the problem is gone when I rolled back to the previous 3.9.3 version.

The strange thing is that normal (none-ajax) request are doing fine.

This is my dispatcher with the used middleware. Please let me know if you need more information.

$relay = new RelayBuilder();

$dispatcher = $relay->newInstance([

    Middleware::FormatNegotiator(),

    //Adds the php debug bar
    Middleware::debugBar($debugbar),

    Middleware::LeagueRoute()
        ->router($router) //The RouteCollection instance
]);

$response = $dispatcher(ServerRequestFactory::fromGlobals(), new Response());

(new Zend\Diactoros\Response\SapiEmitter)->emit($response);

[Óscar Otero]

Thank you. I suspect the problem is in debugBar (in 3.10 the data is sent in the http headers in ajax requests, as explained here http://phpdebugbar.com/docs/ajax-and-stack.html#ajax ) but I'll take a look.

[Óscar Otero]

Hi, I've released a new version (3.10.1). Can you test it and telme if it works fine?
Thanks.

[Matthijs]

Thank you for the fix. But I still get the same error.

When I disable the debugbar middleware it's working again.

I tried to disable the collector but that isn't working either.

this is my code for the initialization of the debugbar

   $debugbar = new \DebugBar\StandardDebugBar();

// tried this as a solution but wasn't working
//  if ($_SERVER['REQUEST_METHOD'] != 'GET')
//      $debugbar->sendDataInHeaders();

    $debugbar->addCollector(new \DebugBar\Bridge\MonologCollector(Log::getLogger()));

   $twig = new DebugBar\Bridge\Twig\TraceableTwigEnvironment($twig);
   $debugbar->addCollector(new DebugBar\Bridge\Twig\TwigCollector($twig));

[Óscar Otero]

I guess this is a problem with the data send in headers. I have to provide an option to disable this feature, but I'd like to know the origin of this problem. Maybe is because there's too much data? Or because a specific collector? Can you check the response receives by the browser and see the body and headers send?

[Matthijs]

I don't think there is to much data because it seems to happen with every ajax request.

For one of the requests this is the header for version 3.9.3 (response header)

HTTP/1.1 200 OK
Server: nginx/1.8.0
Date: Tue, 29 Dec 2015 20:34:26 GMT
Content-Type: application/json; charset=utf-8
Connection: keep-alive
X-Powered-By: PHP/5.5.9-1ubuntu4.14
Expires: -1
Cache-Control: no-cache, no-store, max-age=0
Pragma: no-cache
Set-Cookie: sso_PorSi_c=1; path=/admin/
Set-Cookie: sso_PorSi_s=zC0PRCJjuTRJXlH49JNTrTxOZu2fJQDmrVgf2IAIn8aD0Pxpv-X8CEGCA_s9dV3TqpCFjIJPU2snuKXzCoaiAT6oB8S-04VoHc43bJpgJlu_YiIKkO69cp7JchZg8lzXki19iLaYwoi-153S7KQ7gvr-ZFV_PY8sNooxg2vUJfnOzQutN-qqGI635jU81M6cVUpNN-4YKkNTeOfV3dc09w; path=/admin/; HttpOnly
Set-Cookie: sso_PorSi_v=Ktk0M8t74SKpayVIKamJETFeeYU; path=/admin/; HttpOnly
Vary: Accept-Encoding
Access-Control-Allow-Origin: *
Content-Length: 1724

Indeed when I enable sendDataInHeader(); for none GET request types I get the same 502 error.

When I set a storage the problem seems to be gone.

So it looks like that indeed there is to much data. So I searched on Google and found this: http://shiki.me/blog/firephp-on-nginx-502-bad-gateway/ and my server is also on nginx.

It would be nice if we could indeed disable this feature, or disable debugbar completely for ajax requests maybe?

[Óscar Otero]

Ok, the version 3.10.2 has this feature disabled by default but you can enable it with captureAjax() option.

I'm intrigued with this issue, so if you find a way to solve it, please, let me know.
(For example, by default, the max lenght of each header is 4Mb, maybe too much.)

[Matthijs]

Yes it's working now. Thanks!

I already tried to find a fix, but didn't find anything useful. But I will let you know if I found something!

[Jadon Brown]

Disabling capture_ajax fixed all my 502 problems.