Allow different configuration and serving ports (to allow for nginx + ssl) #48
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
So I want to run SSL in development. This poses a challenge because an SSL-enabled page will not accept non-ssl javascript.
So naturally rack-livereload needs to run in ssl mode. But of course I don't expect you guys to write an SSL server. So NGINX to the rescue!!!
If you were to let me specify a port, say 1234, but the server runs on a different port, say 4567, I can have my nginx redirect port 1234 (in ssl) to talk to non-ssl port 4567. And thus I can have ssl in my development environment and still get live reloading.
So the issue is that you're loading pages on localhost:4567, but because of the proxying, localhost:1234 is being used for urls to the LiveReload JS? Try setting the
:hostoption in the middleware configuration tolocalhost:4567to override the automatic detection. Since using this through a proxy is such an edge case, I'll only add code to detect and use that if someone else provides it, but I think hard-coding:hostwill do it for now.@johnbintz so if I can get my websockets to listen on port [default] but then the js get rendered/requests sent to my overridden port, then this solves the problem as it becomes just an nginx config issue.
Does WebSockets need to go through SSL too for this to work? I have very little experience with SSL interactions, beyond setting up with Apache to serve using it.
Once you are on a ssl-enabled page, the browser is VERY unhappy with insecure content. It will refuse to communicate via ajax to non-ssl enabled endpoints. Not 100% sure about websockets but I believe it is subject to the same restrictions.
So point is all I need is the enabling functionality (ability to poke one port, but serve on another port). I think this can be overridden in the page by overriding that global constant that rack injects, so the JS thinks one port is being used, and nginx can do all the ssl work for you, meanwhile the server is being really ignorant of all this and just listening for non-ssl.
Then, if I understand correctly, I would try changing both
:hostand:live_reload_portto the host:port nginx is serving from and the port through which nginx will proxy WebSockets to an SSL version, respectively. I can try setting up a similar setup tomorrow if that doesn't work and play with it myself to figure it out.Any word on this? I'm having similar issues.