Closed a2nt closed 1 year ago
Hopefully this commit https://github.com/lekoala/silverstripe-debugbar/commit/ba6d3970c7e7cdba20bf6bab73c4d65ec75d6418 will fix the issue
Depending on your webserver you might have to adjust the max_header_length option in the yml. I already halved the default value that was causing issues on most scenarios.
It won't fix the issue I have found out that max_header_length option limits headers size, but only if debugbar will be enabled at the CMS.
So following will break the CMS:
LeKoala\DebugBar\DebugBar:
enabled_in_admin: false
max_header_length: 2048 # that's default option and it's just for an example here
But it will work when it is enabled at the CMS, nginx server has 4k header limit by default so it's not a webserver issue either
i don't see why it would be like that. Headers are being sent by the middleware in the cms or if ajax option is enabled. What makes you think that setting "enabled_in_admin" to false would prevent the option to work as expected?
The only place we send headers is through sendDataInHeaders in the Middleware which always use the max_header_length setting.
well I have tried both values true and false and it breaks my CMS
I noticed a similar issue using nginx in the admin because of the amount of headers passed, for instance requirements that are not bundled and end up having very large headers.
obviously debugbar doesn't help in that regard because it adds a few more requirements which might be enough to make nginx complain, even if we limit the data sent in headers by the php debug bar itself.
that said, if you set enabled_in_admin to false, it should not even initialize in the admin so it is very strange! if you call DebugBar::whyDisabled() it doesn't say "In admin" if inside the /admin. Maybe there is something strange there.
I have noticed that the issue doesn't appears when: debugbar is disabled at the CMS and u haven't visited the CMS before; when u open the CMS for the first time with debugbar enabled;
With debugbar enabled u click to a CMS page it's being loaded using AJAX and when site tree at the left being updated u face to the issue. So u go to the configuration disable debugbar and flush SS cache and the CMS still has the issue. But if u will cleanup cookies the CMS will work with debugbar disabled.
So I guess there's 2 issues:
You have to take into account the debugbar is not the only one sending headers. The requirements api also does it and send in each request x-include-js and x-include-css. When including debugbar, x-include-js becomes a lot bigger, maybe to big for your webserver regardless of the setting controlling debugbar behaviour.
I don't think there is much to do here.
I would like to post my solution which might be helpful.
Basically, it should be the problem of proxy_buffer
size config of nginx according to the StackOverflow. This idea leads to my modifications.
The recommended config on official guide is:
location /index.php {
fastcgi_buffer_size 32k;
fastcgi_busy_buffers_size 64k;
fastcgi_buffers 4 32k;
...
}
I enlarge the buffer size then the site works
location ~ \.php$ {
fastcgi_buffer_size 1024k;
fastcgi_busy_buffers_size 2048k;
fastcgi_buffers 4 1024k;
...
}
I'm changing this to a documentation issue on the grounds that it's an nginx configuration issue rather than a code issue
Getting an error from nginx when debugbar enabled at the CMS