lekoala / silverstripe-debugbar

SilverStripe DebugBar module
MIT License
56 stars 27 forks source link

[BUG] too big header at the CMS #98

Closed a2nt closed 1 year ago

a2nt commented 6 years ago

Getting an error from nginx when debugbar enabled at the CMS

2018/05/29 00:14:35 [error] 15667#15667: *903 upstream sent too big header while reading response header from upstream, client: 127.0.0.1, server: *.run.local.pro, request: "GET /admin/pages/treeview HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.2-fpm.sock:", host: "run.local.pro", referrer: "http://run.local.pro/admin/pages/"
lekoala commented 6 years 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.

a2nt commented 6 years ago

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

lekoala commented 6 years ago

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.

a2nt commented 6 years ago

well I have tried both values true and false and it breaks my CMS

lekoala commented 6 years ago

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.

a2nt commented 6 years ago

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:

lekoala commented 6 years ago

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.

zzdjk6 commented 6 years ago

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;
    ...
  }
robbieaverill commented 6 years ago

I'm changing this to a documentation issue on the grounds that it's an nginx configuration issue rather than a code issue

lekoala commented 1 year ago

added to docs in https://github.com/lekoala/silverstripe-debugbar/commit/f55bde6ef9b67bb4d88c0ab73f693ed9a34996c7