Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Host from request is not used to determine live reload host #6

Closed
tvanekeris opened this issue May 10, 2017 · 3 comments
Closed

Host from request is not used to determine live reload host #6

tvanekeris opened this issue May 10, 2017 · 3 comments
Labels

Comments

@tvanekeris
Copy link

Hi,

first of all: many thanks for your work, fast-live-reload is awesome.

Setup

I run fast-live-reload in a Docker container so that I request the pages not from localhost but from 192.168.99.100.

I run flr using flr -sp 8000 -s build grunt/livereload in the Docker container
so that content from the build directory is served and flr watches for changes in another directory.

Bug description

Everything works correctly when run locally on the system (not within a Docker container), so the bug is related to a different host string than localhost.

The (potential) bug is in the UpdateNotifier class around line 31. The hostString is correctly determined from the request (from document.location.href) to be 192.168.99.100 but never used afterwards. This results in the WebSocket to be opened (wrongly) to the default host localhost:9001 instead of the correct 192.168.99.100:9001. When I hard-code the correct host string in line 41 after all the automatic determination, everything works as expected.

Solution

I did not directly fix this in code because I am not sure how exactly the different ways of specifying the fastLiveReloadHost value should be prioritized. But I am pretty sure that without giving any additional parameter (e.g., you describe the way via GET parameters in the docs), the already correctly determined hostString should be used somehow.

@bmustiata bmustiata added the bug label May 10, 2017
@bmustiata
Copy link
Owner

Thank you for the detailed bug report and the kind words. I'll check it tonight.

@tvanekeris
Copy link
Author

Many thanks @bmustiata, this was really fast and it works (directly tested)!

@bmustiata
Copy link
Owner

bmustiata commented May 10, 2017 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants