Welcome to Working With Rails

 

Discussion Forums

Discuss all things Ruby on Rails with perhaps the web's most vibrant group of Ruby on Rails enthusiasts.
redirect_to failing at Dreamhost
15 Posts
redirect_to failing at Dreamhost

I realise that I sound insane. It's driving me insane! :-)

Well, I've not setup any separate pages but I see no reason for not giving out my admin page. I have no content of any use at the moment on the site because of this problem so I'm not going to lose anything. The login page can be found at http://www.96methods.com/account/login. There is a dummy user with username of 'test' and password of 'password'.

Any help would be gratefully received.

Thanks

I realise that I sound insane. It's driving me insane! :-)

Well, I've not setup any separate pages but I see no reason for not giving out my admin page. I have no content of any use at the moment on the site because of this problem so I'm not going to lose anything. The login page can be found at http://www.96methods.com/account/login. There is a dummy user with username of 'test' and password of 'password'.

Any help would be gratefully received.

Thanks

Ok, it's definitely your (their) webserver that's broken. It's to do with the auto gzip encoding which the web server is doing with the content, and the Content-Length header.

Here's a pastie showing my wget sessions with your server: "http://pastie.org/392650":http://pastie.org/392650

Hopefully the comments in the pastie explain what the problem is, basically your server is reporting the original unzipped filesize as the @Content-Length@ when the gzipped length is much smaller, meaning that the browser is crapping out because it's expecting 1998 bytes and only getting 841. It's actually receiving the right content, whether gzipped or not, but the @Content-Length@ header that the server is sending is wrong.

Now for the bit which explains your insanity - web servers detect through some sort of black magic that I don't know about - the network latency of the client they're responding to, and based on this they decide whether it's worthwhile gzipping content or not. For fast connections, they don't bother because the overhead of gzipping isn't worth the small transfer improvement, but for slower connections they do the gzipping thing. I guess that having the wifi in the mix causes the network latency algorithm to be triggered and so the server is gzipping the content for your wifi connection, but sending it uncompressed when you're connected directly. So, not insane at all.

Btw, you can confirm all this by switching off the gzip encoding method in your browser, not sure about others but in firefox if you put @about:config@ in your address bar then it brings up the configs, you're looking for the @network.http.accept-encoding@ key, and you just want to remove @gzip@ from the list, then try logging in again, wired or wifi, and it should work then because the server doesn't have the option of sending the gzipped version.

Jason, that's fantastic. Thankyou VERY much for your assistance and time. It's much appreciated.

My first thought was what do I need the Dreamhost tech. support people to actually do to resolve this problem. What can I get them to do, what do I need to spell out to them? But I wonder if there's anything I can do, perhaps to my .htaccess file or even switch gzipping off perhaps?

Thanks again

Graham

After a bit of googling, I found that @mod_fastcgi@ has known conflicts with @mod_deflate@ that produce this precise problem. So my guess is that Dreamhost are using @mod_fastcgi@ and that there's no way to keep the deflating in play, and stay with Dreamhost.

You can switch off the deflating in .htaccess - I think it's:

SetEnv no-gzip dont-vary
15 Posts
Login to add your message