Can't proxy my request to my remote server

[nicolasbadia]

I think this is an abbot issue but I'm not really sure !

When I proxy my request to my local server, all work great, but if I proxy to my remote server, all my request get a 'canceled' status !

The problem wasn't here with 1.6 RC2.

[publickeating]

Can you post some more information? What do the proxy statements look like in the console? What about the request headers that are hitting your server, do they vary from what was being passed with 1.6 RC2?

[nicolasbadia]

Well here are the screenshots of the requests headers with SC 1.6RC2: http://dl.dropbox.com/u/138776/RC2%201.png http://dl.dropbox.com/u/138776/RC2%202.png

And here with SC 1.6 final http://dl.dropbox.com/u/138776/Final%201.png http://dl.dropbox.com/u/138776/Final%202.png

My buildfile is configured like this : proxy "/backend/", :to => "www.mywebsite.com"

If I change it to use my local server (like this: proxy "/backend/", :to => "mywebsite:8888") SC 1.6 work as well as SC 1.6RC2

Let me know if you need more information.

[n8mellis]

I am running into this issue as well. What I have been able to determine is that if the browser sends an Accepts-Encoding header with gzip or deflate, then the request will fail with a browser error saying it can't decode the response. If gzip or deflate is not included (e.g. requesting from cURL), everything works fine.

It appears that the bug may actually be with em-http-request. What changed in SC::Rack::Proxy between RC2 and GM?

[publickeating]

I’m sorry nicolasbadia, somehow I missed your response and forgot about this one. I’ll try to reproduce and fix as soon as possible.

n8mellis, the proxy was rewritten to use em-http-request to prevent blocking with long-polling requests and to support streaming APIs like Twitter.

[n8mellis]

publickeating, there is something going on with em-http-request such that it doesn't like gzip/deflate responses. I'm working on reducing it right now and will follow up with more info.

[n8mellis]

publickeating, I found the problem. When a browser sends the header "Accept-Encoding: gzip" (or deflate, compress, etc.) then the proxy is returning the proper Content-Length for the compressed content, but returning the uncompressed content in the response body. Thus the browser tries to uncompress data (because of the Content-Encoding header) that is already uncompressed (and incomplete due to the shorter Content-Length). My hunch is that the http.stream block in SC::Rack::Proxy is passing through the already uncompressed content (rather than the compressed content) while the rest of the headers "Content-Encoding" and "Content-Length" are being passed through unmodified resulting in corrupt response data. Thoughts?

[publickeating]

That actually makes a lot of sense. I don’t see any way to prevent em-http from not automatically decompressing the data, but I’ve added a request for info: https://github.com/igrigorik/em-http-request/issues/120

Once I hear back, we’ll either prevent the decompression if possible or else will have to massage the response headers to match the uncompressed data. Thanks a lot for figuring this out.

[publickeating]

Sorry for the long turn-around time on this, I was consumed by some client support issues all the beginning of this week.

I tested it and it seems to work fine, please let me know if it fixes your issues too.

[NicholasBoll]

I am having this issue. If the content headers have "Content-Encoding:gzip", the content is deflated in the proxy, but the content length is not updated. Running CURL on the request truncates the response to Content-Length. Chrome doesn't know how to handle this and puts the request in 'other' and the response is blank.

If this is fixed in Abbot now, when will it be fixed in the gem? The current gem has this issue.