upstream sent too big header while reading response header from upstream, client:

While working on a project that involved connecting with LinkedIn’s oauth login this afternoon with a PHP fast-cgi, nginx, rails, passenger setup, I encountered an error that took a bit of trial and error to fix.

upstream sent too big header while reading response header from upstream, client:

I tried following a few people’s advice from various forums and blogs of setting proxy buffer size as shown below and a few other params that didn’t lead me anywhere.

proxy_busy_buffers_size 256k;
proxy_buffers 8 256k;

I started to try everything and finally realized maybe the data that I’m getting back and am trying to store in a session was too large. I had originally had thought the error was from the amount of data LinkedIn was sending back. So instead of doing the below:

session["devise.linked_in_data"] = env["omniauth.auth"]

I simply just only set the data that I really need in the session.

Facebook iOS SDK

In one of my current projects, I’m working on an iPhone app that requires basic Facebook Connect integration. I ran into a little trouble with getting fbDidLogin, the delegate function to be called. My setup was a little different than the Facebook sample project so it was debugging time. I tried checking the basic things like making sure delegate was set to the right class and other minor things with no luck. My next step was to turn to Google which usually never fails and after about 10 minutes of trying a few techniques other fellow developers recommended, I came across Brett Spurrier on Google Groups which recommended a simple change to the Facebook.m code:

[self authorizeWithFBAppAuth:YES safariAuth:YES];

[self authorizeWithFBAppAuth:NO safariAuth:NO];

And what do you know, that was the solution! Thank you Brett for your post on Google Groups!


One of my clients that I just started doing work was complaining about images not showing up on his site recently. I checked it out and what happened was the folder had a .htaccess file created there that restricted everyone but a few IPs. I thought that was kind of odd. I poked around more and saw that 3 PHP scripts were somehow uploaded into the folder that wrote the .htaccess file. The scripts were pretty creative and encrypted everything using hexadecimals along with a key. Fortunately, the key they used was the user agent, so I did a quick grep of the server logs and saw what user agent the script was being called was using and decoded the script.

It turns out that the scripts were basically DDOS scripts that could be triggered remotely based on parameters being sent in when calling the script.

Next step after getting rid of those and reading the code was trying to figure out how the scripts got in there in the first place. I didn’t have to look too far and saw that the folder was CHMOD 777. Obviously if a hacker wants to get in, they will find a way in, but CHMOD 777 is almost inviting them in with milk and cookies. I haven’t found out how the file was uploaded, but it’s possible they used a hole since the site was using an outdated open source software solution.

Moral of the story, don’t CHMOD 777 your folders when you don’t need to.