-
Notifications
You must be signed in to change notification settings - Fork 78
Allow different configuration and serving ports (to allow for nginx + ssl) #48
Comments
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 |
@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 |
Any word on this? I'm having similar issues. |
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.
The text was updated successfully, but these errors were encountered: