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

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

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

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.

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

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, so you understand that you now sound insane to everyone else :)

I'm back to asking whether you can setup two other pages that do the same thing but are not admin pages, so we can take a look directly.

OK, so I try to access the login pages of my site at work where the interconnection is NOT wireless but wired. It all seems ok, on both MS IE and Firefox, under Windows. I go home to my wireless network and I have the octet-stream problem. I then connect my PC to my router using an ethernet cable (not wireless) and I managed to logon, logout and keep doing that about 10 times. I only had the problem once during those times. I'm wondering if the redirect information is occasionally getting lost and thus resulting in the error? A friend of mine also tried. He has a wireless network and the problem only occurred once or twice.

I'm getting nowhere wit this problem. Have asked Dreamhost tech support and all they can say is there must be a problem with the code. I just don't get it.

Ok, so no red flags in your code. So, back to a Dreamhost misconfiguration.

15 Posts
Login to add your message