ERR_RESPONSE_HEADERS_TOO_BIG

[sneakyvv]

Hi,

I'm using the newly released chromePHP class 3.0 which is adapted to work with Chrome 17, but I'm getting the ERR_RESPONSE_HEADERS_TOO_BIG error. In earlier versions there used to be a workaround for the 4kb cookie limit by writing to file instead of using cookies. Now ChromePhp is using header information instead of cookies, but there's no workaround for the header size limit, which is according to google 64kb... For most of our pages, there's no problem but sometimes we exceed the limit.

Is there going to be a workaround for this problem?

Many thanks!

[ccampbell]

Thanks for pointing this out. I was trying to simplify the entire thing since the cookie limitation was really the only reason I added the file logging support to begin with.

I will consider bringing it back in some form, but 64kb seems like quite a bit of data to log on a single request.

[sneakyvv]

It's indeed quite a bit of information :)

We're using it to log our database queries and I must admit that they can be quit a lot or long sometimes :-$

Thanks anyhow for considering to bring it back

[gudoy]

Have the same problem. Would'nt, like Firephp does, splitting the log data into several headers (X-ChromePhp-Data_1, X-ChromePhp-Data_2, and so on...) resolve this?

[ccampbell]

I'm going to have to try messing around with this. According to this:

http://stackoverflow.com/questions/3326210/can-http-headers-be-too-big-for-browsers

Note to Firefox: When sending data through multiple headers 100MB worked fine, just split up over 10'000 headers.

So Firefox looks to have a limit per header but not overall for all headers where as Chrome seems to have a limit for all headers together. In which case I don't believe what you proposed will work, but I can give it a shot.

[benf1977]

I've been hitting this too. Working with legacy code and SQL queries. If there is a fix / feature-add I'd be psyched.

[mnapoli]

I'm hitting the limit too, but because of Exception traces.

[aterrien]

Did you find a solution for ERR_RESPONSE_HEADERS_TOO_BIG ? chunk_split don't work because of the 256Kb limitation.

[peshi]

I'm also looking for a solution to this issue, any ideas?

[talisto]

+1, running into this here too.. maybe even just a failsafe to stop outputting any more data after the limit has been reached (possibly reserving a few bytes for a "limit reached" message)? partial output would be better than causing the browser to error entirely.

[oliverkierepka]

I also got the problem with ERR_RESPONSE_HEADERS_TOO_BIG Any suggestions how to solve that?

[hakre]

If there is a limit in chrome, then unless this class checks before reaching that limit and then refuses to add additional header-data, you will continue to see this warning in your browser.

This is actually how monolog did deal with this: Seldaek/monolog/issues/172

It's additionally hard to find out how much header-data has to be reserved for such a check.

So most easy would be perhaps if you allow your browser to accept larger header data as it does yet. There might be a setting that lets you configure this limit at compile time or even at runtime. Please contact the vendor of your browser for your support options if you want to learn more about that.

If you want to learn more, this is how Fire-PHP has dealt with such an issue: https://github.com/firephp/firephp-core/issues/10

[ghost]

I think try this ini_set('session.gc_maxlifetime', 3600);