johnbintz/rack-livereload

Asset requests aborted when using pow via proxy with rack-livereload

Closed this issue · 5 comments

Ok, this is a bit of a weird one. Pow can be configured to proxy to a port. For example, I could run thin on port 3000.

If I echo 3000 > ~/.pow/foo then go to http://foo.dev I would see what is running on thin.

The very first request is fine. Every subsequent request fails to load assets. This is only the case if rack-livereload is running. If I go to http://foo.dev:3000 or http://localhost:3000 all is fine.

m8si-qgi_a-j

I don't use pow. Can you give me some more details on what's going on?

Specifically, what's happening within rack-livereload when a request comes in? Where in the code it's getting hung up?

Honestly I have no idea. The browser aborts all of the requests to assets. Both firefox and Chrome. I just dug further and apparently it only repros if both rack-mini-profiler and rack-livereload are enabled. quite an edge case. I've just disabled rack-mini-profiler for now as we don't use it very often.

My money is on rack-mini-profiler. It doesn't appear to be closing the response body if a close method is available on it, which can cause deadlock issues. See https://github.com/johnbintz/rack-livereload/blob/master/lib/rack/livereload.rb#L56 for how it should be done. If I were you, I would try adding a similar statement to rack-mini-profiler and see if that helps fix the issue, then do a pull on their repo for the fix.

That makes a lot of sense, thanks for looking into it. I'll give it a shot.

On Friday, December 14, 2012 at 10:27 AM, John Bintz wrote:

My money is on rack-mini-profiler. It doesn't appear to be closing the response body if a close method is available on it, which can cause deadlock issues. See https://github.com/johnbintz/rack-livereload/blob/master/lib/rack/livereload.rb#L56 for how it should be done. If I were you, I would try adding a similar statement to rack-mini-profiler and see if that helps fix the issue, then do a pull on their repo for the fix.


Reply to this email directly or view it on GitHub (#22 (comment)).