/dev and the white screen of OK death

[drzax]

For quite a while now, I've been having intermittent issues in our development environment where any call to /dev/build or just plain old /dev would result in an empty 200 OK response (and no errors of any kind in logs). I've finally tracked down the issue, but before I charge off on a solution, I think it needs some discussion.

The root of the problem seems to be that if the Content-Length header is 0 my Apache install doesn't bother sending any content (even if it exists). Here's the workflow:

1. DevelopmentAdmin->index() gets called by Director::handleRequest
2. DevelopmentAdmin->index() creates a DebugView and generates echo output (which then sits around in the output buffer wating to be sent) and returns and empty result to Director
3. The empty result is added as the body of an SS_HTTPResponse object (which sets the Content-Length:0 header) by Controller->handleRequest 
4. This empty SS_HTTPResponse eventually makes its way back to Director::direct where SS_HTTPResponse->output is called sending a 200 OK header along with the Content-Length: 0 header back to the browser at which point Apache seems to discard the content sitting in the output buffer.

The quick and (very) dirty fix for this is to put an exit statement at the end of DevelopmentAdmin->index(). The slightly less dirty fix is to add return ob_get_clean(); to DevelopmentAdmin->index() for non-CLI output. However this only solves this one instance of the problem, and a more comprehensive solution is really required.

Cheers,

Simon

[drzax]

Also, there's a bug report for this which I only just found: http://open.silverstripe.org/ticket/7564

[Sam Minnée]

Hi Simon,

A few points:

1) The fact that DevelopmentAdmin uses "echo" rather than "return" is bad coding style and it would be good to refactor that to return strings and/or SS_HTTPResponse objects.  However, "bad style" doesn't mean "it's okay that it breaks"

2) It's not clear is how output buffering is getting enabled.  Apart from a few points in tests, output buffering isn't used by SilverStripe.  It's also not needed in most cases because of the way SilverStripe generates a SS_HTTPResponse object rather than calling echo.  Are you enabling output buffering in your php.ini, and if so, why?

As for solutions:

3) Maybe the use case for output buffering is "output buffering would let echos behave like SS_HTTPResponse objects".  Director could start output buffering, capture all output, and include it in the generated SS_HTTPResponse object.  Maybe this is a 

4) Or maybe we should have Director (or SS_HTTPResponse) detect where output buffering is enabled, and if so, respond accordingly.  This would be similar to the solution in (3) but it we wouldn't have the framework enable output buffering.

5) I'm curious as to what Marmitizz's problem with just putting "ob_flush()" in there was.

[Simon Elvery]

Hey Sam,

Point 1 - It's DebugView rather than DevelopmentAdmin that's doing the echoing.

Point 2 - It is turned on in config somewhere, but in any case SS shouldn't break just because OB is turned on.

Point 3 - I did consider that as an idea, only I think that will break (or drastically change the behaviour of) Debug::dump (and similar)

Point 4 - Same concern as above

Point 5 - That does seem to fix the issue, but it does stop the framework adding HTTP headers which might have unintended consequences. 

--
You received this message because you are subscribed to the Google Groups "SilverStripe Core Development" group.

To view this discussion on the web visit https://groups.google.com/d/msg/silverstripe-dev/-/dHhnyXQoi1wJ.

To post to this group, send email to silverst...@googlegroups.com.
To unsubscribe from this group, send email to silverstripe-d...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/silverstripe-dev?hl=en.

[Martine Bloem]

This is not an Solely an Apache issue - I had this on Lighttpd as well :) Disabling output buffering in php.ini does solve the problem and I've not had any other specific issues after doing that, but that doesn't say everything :)

The ticket followed a discussion on the forums: http://www.silverstripe.org/general-questions/show/20062?start=0

> 5) I'm curious as to what Marmitizz's problem with just putting "ob_flush()" in there was.
>

Oops - That has been a while, so I'm not sure, I'll search my notes. But it should be easy to replay

Martine

[Martimiz]

OK guys, I replayed this on Lighttpd, by setting output_buffering = 4096 in php.ini, and tried it on a couple of installs I still had hanging around. The older installs still display the whitescreen, so the problem still exists at least on this server. The last version I installed from 3.0 at GitHub doesn't seem to be affected anymore. Dating from 16-10-2012:

silverstripe-silverstripe-cms-3.0.2-36-g0a92c81.tar.gz
silverstripe-sapphire-3.0.2-170-g574c53d.tar.gz

Could be that somewhere in between this got fixed?

Martine

[drzax]

Okay, well that was a lot of bug hunting yesterday for something that was already squashed. I can confirm it was fixed here: https://github.com/silverstripe/sapphire/commit/356a367eb5d05bea3dfa2edaeabc52a2496b93b2

On the up side, it gave me a proper reason to use git bisect.

Cheers,

Simon

[James Pluck]

Hi all,

I've just installed a new SS 3.0.5 install from the stable tarball and this bug is back.  I had a look at the Director and HTTPResponse files and the fixes outlined in drzax's message below are not present.  I've manually fixed my site install but it seems the fix has been left out of the 3.0.5 stable build.

Cheers
James.

[James Pluck]

Is there any progress on reintegrating this patch into stable?  I've looked through the changelog for 3.1.0-rc1 and there is no mention of it that I can find?  I am still having to manually include this patch on new builds in order to avoid the white screens on /dev

J