host for static file routes is no longer hardcoded as localhost

[drewlio]

Modification to: mystmd/packages/myst-cli/src/build/html/index.ts

Builds host variable from env variable HOST in accordance with documentation and option to honor HOST with --keep-host option

[welcome[bot]]

Thanks for submitting your first pull request! You are awesome! :hugs:
If you haven't done so already, check out EBP's Code of Conduct and our Contributing Guide, as this will greatly help the review process.
Welcome to the EBP community! :tada:

[drewlio]

This is created to address issue https://github.com/executablebooks/mystmd/issues/965

[LecrisUT]

Doesn't this affect myst build instead of myst start? My understanding is that that section creates a temporary server so that it can download all of the html files, while myst start only serves the contents without downloading the pages (i.e. it doesn't use the artifacts from myst build), but it keeps it open for users to use.

[drewlio]

Thanks for the reply. I should mention that I'm just a user, or at least I'd like to be a user, but I can't get myst to work when I have to run on a remote machine via ssh. My goal is to be a user.

I'm not following the distinction between running the server as myst build vs myst start. It seems like if you do a myst start it does a build. Are you suggest I'm actually doing it wrong? (Not offended! That would be a great outcome because it's easy to fix!)

[LecrisUT]

myst build is to get all of the exports: pdf, LaTeX, html, etc. myst does not write the html files directly, instead it generates them through react/remix. The way it does html exports is that it launches a temporary server and downloads all html files, and it closes it after that (check the few lines after the changes there).

myst start is to start serving the react/remix content as a web server.

Generally though, it should fine if you leave it to run as localhost and you use a reverse-proxy to handle the actual url, though I haven't gotten that far to test that. caddy at least can be easy to configure and rewrite paths.

I should mention that I'm just a user

Same 😉

[drewlio]

Can you say more about how caddy as a reverse-proxy would be used to fix this? Running it on the server side works for the initial requests, but when the client browser tries to load img tags, etc, they are being requested from localhost:3100. If I'm understanding correctly, caddy would have to rewrite the served HTML file. (see pic below)

Or are you picturing caddy running on the client side?

[LecrisUT]

caddy is run at the server side. The screenshot you have are when running caddy? Hmm, indeed the links there should point to the actual host to work, or rather they should be relative paths.

You could check where the server is actually started: https://github.com/executablebooks/mystmd/blob/2b4f85036f8aa8f8d1a7035eba3f28bccf05371e/packages/myst-cli/src/build/site/start.ts#L104

But I think this would be an issue either with myst parsing link files (try to look at the json files in the artifacts for any clues), or with the theme. I didn't manage to navigate passed the webserver start to see how the content is generated

[drewlio]

Thanks. Your comments helped a lot.

After investigating more, it seems that the server (the ContentServer on port 3100) is truly binding to the external interface and truly serving the files when asked. (I can pluck the URL out of the HTML served to the client and modify the domain and it loads.)

I suspect you're right in that this might be an issue with book-theme. In fact, I found a place where they are hardcoding localhost in the theme and I submitted and issue there. (https://github.com/executablebooks/myst-theme/issues/342) It seems like, as you said earlier, if these were served with a relative path vs absolute URL then this wouldn't be an issue.

[connorferster]

I am having this exact same issue with the book theme.

@drewlio Were you able to find a workaround that allowed you to actually publish a site with your content?