Chrome: Error 325 (net::ERR_RESPONSE_HEADERS_TOO_BIG): Unknown error.

[PowerKiKi]

It looks like Chrome (used with FirePHP4Chrome) has the lowest limit for headers size according to StackOverflow of 256kb for all headers.

This can quickly be a problem when using $firephp->trace() where stacktrace dumps can get huge.

The obvious way to solve that, would be to detect the browser and truncate the size of headers, including a warning for developers at the end of logs.

But maybe it could be much cleaner to combine effort with https://github.com/aaronsaray/FirePHP4Chrome and @aaronsaray and introduce a new optional header sent from FirePHP4Chrome, which would trigger a limit on header size.

What would seem the best approach ?

Also see, similar issue (and how they solved it): Seldaek/monolog#172

[aaronsaray]

I would be open to implementing anything that FirePHP requires.

What would be really cool would be an additional x- header sent on request - of the maximum accepted size of headers in that browser. Perhaps even modify firephp to wait until deconstruct until headers are sent - call get_headers() to calculate the already sent headers, subtract that from the x- header limit, and then truncate? Just spit-balling :) Let me know what I can do to help.

[PowerKiKi]

What you describe is exactly what I imagined. It shouldn't be too much huge
work, it is flexible and don't mess with ugly browser detection.

I am willing to work on a pull request if the concept is validated by
firephp team.

[cadorn]

I am open to adding the detection of Chrome and limiting the data sent in the PHP library. The limit should be done via an option (like the other options) where the option is automatically set if Chrome is detected. If the option was set by the user it should not be changed. We can call the option maxCombinedHeaderSize.

[cadorn]

Just saw the other comments. If you want to look for a x-wf-option-max-combined-header-size header to set the option that would work as well. The size should be what the browser would accept as maximum and FirePHP can calculate the size of the existing headers minus say 200 characters that may be added by the webserver. We may need to tweak that.

[PowerKiKi]

So I pull requested patches for both FirePHP and FirePHP4Chrome. FirePHP new feature is covered by unit tests (tested with PHPUnit 3.7, PHP 5.4). Hope everyone will agree with my changes and that it will be merged :)

[cadorn]

I have commented on the PRs. This still needs some work.

[PowerKiKi]

I stumbled upon an issue and am waiting for advice to keep working on that PR. See https://github.com/firephp/firephp-core/pull/11/files#r4088176

[PowerKiKi]

Closing due to lack of interest from core developers.

[cadorn]

I am going to be looking at this later this year. Will be doing an update to FirePHP on server and client.

[markusp72]

+1

[PowerKiKi]

@markusp72, I wouldn't hold my breath if I were you and move on to another project.

This project has not seen any significant activity in the last 2 years (if not more), and this specific issue was solved in #11, more than 3 years ago, but the maintainers never considered it good enough to be merged. Even though the original code base is really not up to modern standards.

[cadorn]

I am working on a new Web Extension here: https://github.com/firephp/firephp-for-firefox-devtools

We can bring this functionality into the new extension and update FirePHPCore as things settle down.

I am charging ahead with FirePHP irrespective of other projects (like FirePHP4Chrome) now if that makes any difference.

@PowerKiKi I apologize for your frustrating experience (understandably so) contributing to FirePHP.

[aaronsaray]

Cool! Just to clarify - I did implement the feature we discussed above in FirePHP4Chrome - even though it was just a suggestion. If that particular implementation changes, I'm open to removing the code and applying a different solution. Just been waiting... glad to hear there's some movement here now :)

[cadorn]

Will be solved by: #57