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

Handle ngrok vs livereload #3882

Closed
bep opened this Issue Sep 13, 2017 · 7 comments

Comments

Projects
None yet
2 participants
@bep
Member

bep commented Sep 13, 2017

Using ngrok with livereload and Hugo is pretty cool, but right now the port handling does not support that.

I have tested with just hard coding 443 in the livereload handler setup, and that works. We should think about how to do this properly.

Suggestions welcome.

  • We have appendPort which can be used to remove 1313 from the URL (but it does not remove from the livereload interaction)
  • We have port, but that is the listener port

@digitalcraftsman @moorereason suggestions?

https://ngrok.com/

@bep bep added the Enhancement label Sep 13, 2017

@moomerman

This comment has been minimized.

Show comment
Hide comment
@moomerman

moomerman Sep 22, 2017

I'm experiencing the same problem with a local HTTPS proxy in front of hugo.

I have started the dev server with hugo server -b https://mysite.dev/ --appendPort=false and the pages load and navigation via the proxy is fine, but livereload is appending the port which can be seen in the js console error:

WebSocket connection to 'wss://mysite.dev:64871/livereload' failed: Error in connection establishment: net::ERR_SSL_PROTOCOL_ERROR

I would expect the websocket URL in this case to be to be wss://mysite.dev/livereload

moomerman commented Sep 22, 2017

I'm experiencing the same problem with a local HTTPS proxy in front of hugo.

I have started the dev server with hugo server -b https://mysite.dev/ --appendPort=false and the pages load and navigation via the proxy is fine, but livereload is appending the port which can be seen in the js console error:

WebSocket connection to 'wss://mysite.dev:64871/livereload' failed: Error in connection establishment: net::ERR_SSL_PROTOCOL_ERROR

I would expect the websocket URL in this case to be to be wss://mysite.dev/livereload

@bep bep added this to the v0.28 milestone Sep 22, 2017

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Sep 22, 2017

Member

Thinking out loud I think that making appendPort also work for the livereload URL would solve this.

I put this in the 0.28 release because I kind of need this myself, so a quick feedback in the form of "yea, that sounds good" would be nice.

Member

bep commented Sep 22, 2017

Thinking out loud I think that making appendPort also work for the livereload URL would solve this.

I put this in the 0.28 release because I kind of need this myself, so a quick feedback in the form of "yea, that sounds good" would be nice.

@moomerman

This comment has been minimized.

Show comment
Hide comment
@moomerman

moomerman Sep 22, 2017

Yep, I would expect the --appendPort=false flag to not append the port for the livereload websocket URL.

This actually looks like a regression bug looking at some older issues like #1406

moomerman commented Sep 22, 2017

Yep, I would expect the --appendPort=false flag to not append the port for the livereload websocket URL.

This actually looks like a regression bug looking at some older issues like #1406

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Sep 22, 2017

Member

Yea, I think the port was added at some point -- which kind of solved one problem, but broke another. Let us just call it an Enhancement, to boost my motivation for fixing it, and it looks better in the release notes ...

Member

bep commented Sep 22, 2017

Yea, I think the port was added at some point -- which kind of solved one problem, but broke another. Let us just call it an Enhancement, to boost my motivation for fixing it, and it looks better in the release notes ...

@moomerman

This comment has been minimized.

Show comment
Hide comment
@moomerman

moomerman Sep 22, 2017

Give me a shout if/when you want me to test it out.

moomerman commented Sep 22, 2017

Give me a shout if/when you want me to test it out.

@bep bep closed this in b180477 Sep 23, 2017

@bep

This comment has been minimized.

Show comment
Hide comment
@bep

bep Sep 23, 2017

Member

@moomerman I have committed a fix for this. My original plan just didn't work, so I added a new flag.

Member

bep commented Sep 23, 2017

@moomerman I have committed a fix for this. My original plan just didn't work, so I added a new flag.

@moomerman

This comment has been minimized.

Show comment
Hide comment
@moomerman

moomerman Sep 23, 2017

@bep thanks very much! can confirm this works perfectly with a local HTTPS proxy - also didn't know about the --navigateToChanged flag which is very handy 😄

Have only been using hugo for a couple of days but very happy with what I've been able to produce with it, thanks!

moomerman commented Sep 23, 2017

@bep thanks very much! can confirm this works perfectly with a local HTTPS proxy - also didn't know about the --navigateToChanged flag which is very handy 😄

Have only been using hugo for a couple of days but very happy with what I've been able to produce with it, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment