Live reload doesn't respect --baseURL setting

[sth]

What version of Hugo are you using (hugo version)?

$ hugo version
Hugo Static Site Generator v0.54.0/extended linux/amd64 BuildDate: 2019-06-04T19:16:36Z

Does this issue reproduce with the latest release?

Yes, the current git master version has the same behaviour.

The problem

livereload.js

Hugo always tries to load livereload.js from the hardcoded path /livereload.js, even when there is a --baseURL parameter that specifies a different root path. So, for example, with --baseURL=https://tejp.de/drafts/ I would have expected the livereload script to be loaded from https://tejp.de/drafts/livereload.js or simply /drafts/livereload.js, but not from /livereload.js which lies "outside" of the baseURL.

Other page resources respect the specified baseURL, so I would have expected the support scripts for livereload to do the same.

What's wrong with that?

So why is that a problem? My use case for --baseURL including a path was to access the hugo server through a proxy as a subdirectory on my webserver, accessible as https://tejp.de/drafts/.
So https://tejp.de/drafts/ and everything below gets proxied to http://localhost:1313/. I add some authentication and now I can view my draft posts conveniently at that URL. It works nicely, only live reload doesn't work because it uses a different path.

I imagine such a proxy to be the main use case for --baseURL.

livereload websocket

If I reconfigure things so livereload.js gets loaded successfully, it tries to open a websocket connection to /livereload, again without using the --baseURL setting. This websocket should also be located below baseURL and not "leak" into the toplevel directory.

This can easily be accomplished by passing an additional path=... URL parameter to livereload.js.

Fixing it

It is quite possible that I misunderstand how live reload is supposed to work and am going in the wrong direction, but not I have a proof of concept patch that implements these changes. It needs some polishing but should work out without major problems.

[bep]

This websocket should also be located below baseURL and not "leak" into the toplevel directory.

Can you tell me what real problem you're trying to solve? Note that this is a development server.

[sth]

I have a web server with a hugo installation. Nginx on that server is configured to serve the generated pages. To change something, I ssh into the server, write some text and run hugo to re-generate the page.

When I want to run hugo serve on the server while writing new content I need some way to access that with my browser on my local machine (not on the web server).

The easiest way would probably be to use hugo serve --bind=0.0.0.0 to make it accessible from the internet, but it doesn't seem optimal to have it openly accessible by anyone. So I decided to try and add a password protected path to nginx that proxies through to hugo serve. This gives me access from my local machine without directly exposing it to the internet.

[bep]

I suggest something ala:

hugo server --liveReloadPort=443 --baseURL=https://yourngrokid.ngrok.io --appendPort=false

Your setup seems a little too special/complex for us to add complexity to support it.

[sth]

As far as I can tell a baseURL with a subdir like --baseURL=https://example.com/subdir/ is supported and works. Page resources and generated links all contain the subdir. As far as I can see only live reload uses a different URL not following the general pattern. To me it would look much more logical and straight forward if live reload would work the same way as everything else. If generating sites living in a subdirectory is supported it seems logical that testing them with hugo serve should work the same way.

I don't think it would add much complexity, basically it's just a URL being passed around instead of a single int port number.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[Maldris]

hi @bep,
I'm just curious as to if this issue and its associated pull request #6698 could be revisited/reconsidered.

To give a hopefully more compelling example of a real problem;

One of my clients I am doing contract work for uses hugo internally and currently provides sites for their customers as part of a larger offering.
In order to streamline their process, they are attempting to put together a web based editor to facilitate customer edits to the parts of the site they control. The goal being to use hugo server running in a docker container to preview any edits the user makes (with bringing the container/preview up and down being an application level concern).
Creating the container and binding it to a path work fine, but as mentioned above, the live reload behaviour does not observe the --baseURL argument.

In this particular use case, being able to put the preview behind a path is a requirement to avoid collisions in the namespace of the editor environment's api and the preview instance, as we don't have complete control over the customers DNS settings to place it on a subdomain.

While supporting such an editor environment is not really part of this projects concern, given the relatively minor change to support it, I hope you can see some value in reconsidering these changes.

[bep]

I think I may have misunderstood you.

Are you saying that running with: --baseURL https://somehost/subpath does not work with livereload?

[Maldris]

It works in a way which works for local development, but not in the above example case.

Regardless of any value passed in --baseURL the live reload script is always given the path /livereload.js which is no longer inside the base URL.
In my example case, that would be fine. I could just serve the script as part of the editor rather than the one provided by the hugo server instance.
The problem is that the livereload script looks to connect to a websocket at /livereload, which is also outside that base URL, and hard coded in commands/server.go at this path.

[bep]

OK, then I understand. Let's continue the discussion in the reopened PR.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Hugo team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

[ryanburnette]

For the sake of my sanity, is --appendPort=false broken for websockets right now?

I'm using

hugo server --baseURL=https://example.com --port=3000 --appendPort=false

Version

Hugo Static Site Generator v0.76.5-60F0725B linux/amd64 BuildDate: 2020-10-14T15:15:49Z

And I'm getting errors when the livereload ws tries to connect on port 3000.

What's the URL for the PR?

[larryare]

@ryanburnette It appears it is broken, no matter what you do, port is appended.

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.