Can't proxy my request to my remote server about abbot HOT 9 CLOSED

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?

from abbot.

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.

from abbot.

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?

from abbot.

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.

from abbot.

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.

from abbot.

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?

from abbot.

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: igrigorik/em-http-request#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.

from abbot.

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.

from abbot.

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.

from abbot.