-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Response headers too big when using Chrome PHP handler #172
Comments
There is nothing we can do here IMO. the issue is the way ChromePHP works, getting all log messages in a single header. The way Firephp works (using 1 header per log message) avoids getting too big headers. |
We can stop appending to the header once it reached the max size of chrome (once that is known). Better have incomplete logs than a broken page IMO. |
Researched it a bit and I patched it, chrome seems to have a limit of 256KB across all headers, so splitting it like firephp wouldn't help. Anyway if someone can confirm it works fine it'd be nice. |
…283, #1387) Set server.stream-response-body = 1 or server.stream-response-body = 2 to have lighttpd stream response body to client as it arrives from the backend (CGI, FastCGI, SCGI, proxy). default: buffer entire response body before sending response to client. (This preserves existing behavior for now, but may in the future be changed to stream response to client, which is the behavior more commonly expected.) x-ref: "fastcgi, cgi, flush, php5 problem." https://redmine.lighttpd.net/issues/949 "Random crashing on FreeBSD 6.1" https://redmine.lighttpd.net/issues/760 "Memory usage increases when proxy+ssl+large file" https://redmine.lighttpd.net/issues/1283 "lighttpd+fastcgi memory problem" https://redmine.lighttpd.net/issues/1387
I just found a problem with the chrome php logger that is now enabled by default in symfony.
When the response headers get too big, chrome will simply show an error page.
Tthis seems to happen pretty fast, e.g. when using sonata admin.
Eeven curl raises an error when the headers are too big.
So the handler should probably limit it automatically, so the page does not get unusable.
About the limit: According to curl: "avoided giant realloc for header (max is 102400)"
Don't know the exact limit for Chrome.
The text was updated successfully, but these errors were encountered: