--base-url ignored by serve

[blueglyph]

Bug Report

The option -u or --base-url is not taken into account with the serve command.

Environment

Zola version: 0.17.2

Expected Behavior

With the command zola serve -u 127.0.0.1/test/ -O, I was expecting the server to open this URL and to make the site available at this URL.

Current Behavior

• the command opens this URL: http://127.0.0.1:1111/
• the site is only partially available. The CSS and static items aren't found.
• opening http://127.0.0.1:1111/test/ leads to a 404 answer from the server.

Step to reproduce

Type the following command:

zola serve -u 127.0.0.1/test/ -O

The output is:

Building site...
Checking all internal links with anchors.
> Successfully checked 0 internal link(s) with anchors.
-> Creating 14 pages (0 orphan) and 1 sections
Done in 62ms.

Web server is available at http://127.0.0.1:1111

Listening for changes in \\?\D:\projects\web\test_blog\{config.toml,content,sass,static,templates}
Press Ctrl+C to stop

The browser opens this page: http://127.0.0.1:1111/

Other information

My config.toml file specifies a base URL on github.io. When I publish the website, it mostly works there except a few dangling URLs that I need to debug.

Used with the default options, e.g. zola serve -O, it works fine too. It just makes it difficult to check those dangling links with a more realistic URL that includes a path after the IP.

[blueglyph]

While zola serve -i 0.0.0.0 -u 192.168.56.1 -O works, it doesn't with a path after the IP either.

Besides, it opens the browser at http://0.0.0.0:1111/ instead of the expected 192.168.56.1:1111 URL. I would suggest to open the '-u' IP to make it more user-friendly.

[Keats]

zola serve strips anything other than the ip/url

[blueglyph]

I suppose you mean it strips everything after the IP. That must be the problem, on top of ignoring the IP when launching the browser, or ignoring the IP altogether when -i is not used..

[blueglyph]

I got an issue when cloning the repo (see below), but I can build and reproduce the problems. If that helps, I can try to fix them, but what should be the expected behaviour?

-O flag

As a user, I'd expect:

• When -i 0.0.0.0 is given without -u, it should launch the browser at localhost or 127.0.0.1 instead of 0.0.0.0.
• When -u $IP is given (with or without -i), it should launch the browser at $IP instead of 127.0.0.1 or 0.0.0.0.

Complete URL

The URL given with -u:

• Either it should refuse anything other than the host (giving a path returns an error). Not the best solution but at least less confusing for the user.
• Or it should accept it and use it as base url (for ex. in get_url(path="/")) to be consistent with the build behaviour (when base_url contains a path in config.toml).

---

PS: Submodule issue when cloning the repo. I've tried 3 times at different times and always get the same error.

This is strange since this revision exists in that repo...

[lorenzleutgeb]

I am trying to use Zola within Gitpod. The Gitpod instance is associated a domain name, and is exposed to the internet (if I chose to configure it this way). To get zola serve to work as intended, the base URL must use the HTTPS protocol and the domain name of the Gitpod instance, i.e. the base URL should be something like https://1111-debug-foo-bar-724uni8fxkr.ws-eu92.gitpod.io/.

Zola is particularly stubborn about the base URL. The parameter that you call "base URL" is not really treated as an URL, but only a hostname which is then prefixed with a fixed protocol scheme (http://) and postfixed with the port number (:1111 by default) which can be optionally disabled by --no-port-append.

I consider the parameter "base URL" to be confusing. It does not take a URL, and it will be modified in ways that are not intuitive, i.e. http:// will be prepended even if the specified base URL already contains a protocol. Zola really needs a way to say "I know what I am doing, this is the base URL, stop trying to be smart about it." Such a hatch might be added in addition to all the smartness you are trying to achieve by prepending the protocol and appending the port, but it should definitely exist.

[Keats]

Honestly I would need to re-read the code to see how -i/-u actually work, I don't think I've ever used those myself with serve. If i remember correctly, it was mostly added to support Docker workflows.

@blueglyph you don't need to pull the submodules to work on Zola, we keep the theme/syntaxes binary outputs in the repo. You only need to pull them if you are adding a syntax or a theme.

[blueglyph]

@Keats I may give it a try, I don't think users use the test server and expect it to open at 0.0.0.0, and having a path should not be breaking either.

I prefer to ask first because I would hate to do that for nothing. I've had that problem before, and it's not fun. 😅

[Keats]

Have a look at how other SSG handle that, if they all do the same thing we can match it.

[lorenzleutgeb]

@Keats, I have thought a bit about a backward compatible solution that would allow users to fully customize the base URL. Check https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=f19b3126a567464a7e5903214a341cdb and tell me if you would like me to PR.

[blueglyph]

@lorenzleutgeb I'm a little surprised to see that you decided to take over the fix without even warning me, only posting about it 4 days later. That's not how we do things, and I specifically said how it could be frustrating to work on a patch in vain.

Seeing you're so keen, I'll stop there; fortunately I haven't spent too much time on it yet. But next time please don't ignore the OP's posts and communicate to avoid that sort of situation.

[lorenzleutgeb]

@blueglyph Sorry to have attempted to hijack the issue you posted here. The code I posted only addresses what I mentioned in https://github.com/getzola/zola/issues/2170#issuecomment-1504023159 . I'll file a new one, so that it can be discussed (or ignored) independently.

[blueglyph]

It's not at all what I wrote. I don't think you're hijacking the issue since it seems to be the same one.

[Keats]

@blueglyph I would be interested to see what you had in mind

[blueglyph]

@Keats What I described a few posts above.

The code isn't very clear to navigate through, but I saw something strange. Apparently the path isn't stripped from the URL, but the port is added after, based on a test performed on the configuration URL, which seems like a bug to me. So perhaps it's just the matter of fixing the test and formatting the URL properly, when the -u argument contains a path.

Then I suppose the correct URL should be used when launching the browser instead of using the -i argument.

[jamwil]

@blueglyph @Keats As there hasn't been any activity on this issue in some time and I don't see any related PRs, would it be alright if I worked on a patch for this?

[blueglyph]

@blueglyph @Keats As there hasn't been any activity on this issue in some time and I don't see any related PRs, would it be alright if I worked on a patch for this?

I'm not working on it anymore, since someone else apparently decided to do it. There was no news though, so maybe he stopped too.

So I think it's fine, and even welcome! :)

[jamwil]

I have taken a stab at it in #2311. Marked as a draft PR for now as I'm going to test on a few different setups, just wanted to get the code out in the open early.

[jamwil]

I have tested this with @lorenzleutgeb's issue (remote development server with https) and it works wonderfully (also solving my particular use case), but it doesn't yet address @blueglyph's arbitrary path issue. I am correctly parsing the base url I believe, but I still get 404s at example.com/testpath/<application-routes>, so I suspect I'll need to implement similar logic on the bound interface?

[jamwil]

@blueglyph I think I have this working on arbitrary paths now! Give #2311 a try.

[dijit]

2311 is fixing the path suffix it seems. (http://<...>/something)

However, I have a similar case as @lorenzleutgeb (using tailscale funnel to preview a site collaboratively), and the patch is not helping with -u https://<...> protocol change declarations.

[jamwil]

@dijit Are you certain? This works for me over tailscale funnel: zola serve --base-url "https://example.com" --no-port-append

[jamwil]

@dijit Actually, I may have introduced a regression when I did the path bit. Looking into this.