Log Call Causes Error 500

[GuardianMajor]

It was originally reported here: https://github.com/ccampbell/chromelogger/issues/61

[jcrben]

What's the point in opening a duplicate issue with no additional information?

[ccampbell]

@GuardianMajor can you check your apache error logs. I suspect the issue is that you are logging too much data on a single http request. The maximum header size in apache is 8kb by default.

http://stackoverflow.com/questions/686217/maximum-on-http-header-values

I don't know if there is a way to know this limit from PHP to throw an error in this case

[ccampbell]

Just wanted to point out it is configurable in apache by changing

LimitRequestFieldSize 8190

To something bigger in your apache config

http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestfieldsize

[GuardianMajor]

@jcrben the point is that the developer asked the issue be moved here, so there is no duplication, just a reference back, do you have anything useful to add? There is no information to provide, as I said in the previous post, if there is an internal logging system that provides details that can be shared, I'd be happy to share it, otherwise just an error occurs and no traceback as to what or where caused it.

[GuardianMajor]

@ccampbell not sure the request limit is the issue as the test call is simply returning the result of a database connection, the sql_error value and that's hardly so big as to cause an issue. Unfortunately I don't see anything in the Apache logs for this issue that would provide specifics of the cause.

I checked and although the default of 8190 is sufficient and in fact recommended by Apache NOT to change, ours is set to 102400 (because of unrelated authentication requirements), I am going to try it again with a different piece of code and see if I can glean any ideas about what's going on.

Point of inquiry, we are using PHP 5.6 (I also tested it with 7.0) any known issues there relating to PHP version?

[ccampbell]

Hmm you are right 102400 definitely sounds like a lot. It is possible that it can be large tho cause the error probably will include the stack trace which could be pretty big.

Can you try commenting out this line in ChromePhp:

https://github.com/ccampbell/chromephp/blob/c3c297615d48ae5b2a86a82311152d1ed095fcef/ChromePhp.php#L394

Just want to confirm the 500 is definitely related to including the header with the data.

[GuardianMajor]

Sorry about the delay, I had some issues to deal with. I just tested it on a different project and did not get 500 but the only thing that shows up in response to log statements is simply "a" that's it, nothing else. Decided to test it on the other project and it broke as previous. So I commented out the line you said and it did "work" but with the same results as the other site, just get "a" in the console and only once, regardless of how many log statements you have. So this took a bit of a turn :)

[dm8mydog]

For anyone still looking for info about this: I was trying to investigate a Magento grid object (...well it's magento... so, yeah... they don't think small) and I got hit with server error 500s. Unfortunately my live on-site dev box can't be tampered on the httpd conf level but my local VM with a

LimitRequestFieldSize 262144

in an apache conf did the trick. (256Kbytes ~256 * 1024 = 262144) btw, the headers alone where over ~100 Kbytes ;)

[DanMan]

That's probably why FirePHP divides its data up into multiple headers. You can also get the headers smaller by doing a gzcompress() (or gzencode()) in PHP before you base64_encode() them. I was able to achieve a reduction to about 40% of the original data. Of course, the browser plugin didn't expect that, so it didn't actually work.

[g-barkin]

I don't know why this would make a difference, but I get this problem when my logging calls are inside a php function, and only then. If I comment them out, all works properly (but without any logging, obviously). This happens regardless of the amount of data being logged (e.g. an id value of "1") with the text "id value".