Skip to content
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

ERR_RESPONSE_HEADERS_TOO_BIG #12

Open
sneakyvv opened this issue Feb 9, 2012 · 12 comments
Open

ERR_RESPONSE_HEADERS_TOO_BIG #12

sneakyvv opened this issue Feb 9, 2012 · 12 comments

Comments

@sneakyvv
Copy link

sneakyvv commented Feb 9, 2012

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
Copy link
Owner

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
Copy link
Author

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
Copy link

gudoy commented Feb 23, 2012

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
Copy link
Owner

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
Copy link

benf1977 commented Jun 7, 2012

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
Copy link

mnapoli commented Jun 22, 2012

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

@aterrien
Copy link

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

@peshi
Copy link

peshi commented Feb 11, 2013

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

@talisto
Copy link

talisto commented Apr 29, 2013

+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
Copy link

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

@hakre
Copy link

hakre commented Sep 14, 2014

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: firephp/firephp-core#10

@ghost
Copy link

ghost commented Apr 23, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

10 participants