HTML served with <img src=http://localhost:3100> even with HOST=10.0.0.1 myst start --keep-host`

[drewlio]

Describe the bug

When I have a fresh install with the mystmd-quickstart, and do a HOST=10.0.0.1 myst start --keep-host,

I expect to remotely access http://10.0.01:3000 and have it serve the entire web page,

but instead, while most assets are loaded from relative links and work fine, <img src> tags point to an absolute URL of http://localhost:3100/... (see picture below of incorrect links in the client browser)

However, the server is binding to 10.0.0.1 and will serve the asset file. (see picture below of directly accessing the asset URL with the correct domain instead of localhost)

This is a problem for people trying to use mystmd through a SSH connection to the big server where they do their computational work and where their Jupyter notebooks live and run.

To try to help, could it be related to the hardcoded localhost below? It seems like this would be fixed if this was a relative path like the other assets.

myst-theme/themes/book/app/utils/loaders.server.ts

Line 14 in e549832

const CONTENT_CDN = `http://localhost:${CONTENT_CDN_PORT}`;

Reproduce the bug

1. install mystmd
2. download the quickstart
3. set your HOST env variable
4. myst start --keep-host

List your environment

$ myst --version
v1.1.48

$ myst templates list --site book-theme
ID: site/myst/book-theme
Version: 1.0.0

[welcome]

Thanks for opening your first issue here! Engagement like this is essential for open source projects! 🤗

If you haven't done so already, check out EBP's Code of Conduct. Also, please try to follow the issue template as it helps other community members to contribute more effectively.

If your issue is a feature request, others may react to it, to raise its prominence (see Feature Voting).

Welcome to the EBP community! 🎉

[drewlio]

Looks like article-theme does the same thing

myst-theme/themes/article/app/utils/loaders.server.ts

Line 14 in e549832

const CONTENT_CDN = `http://localhost:${CONTENT_CDN_PORT}`;

[drewlio]

On the idea of making it a relative path, RFC3986 Section 5.2.2 says you can't change the port in a relative path. If you need to change the port, you have to specify the entire "authority" (host:port).

[LecrisUT]

On the idea of making it a relative path, RFC3986 Section 5.2.2 says you can't change the port in a relative path. If you need to change the port, you have to specify the entire "authority" (host:port).

I am not sure this is relevant. myst start controls what host:port are being listened to, and the relative paths should just change according to the paths that are served + the current document/path

About the utils/loders.server.ts, I am not sure if that one is related. I wonder if that one is just used to get the pages. What we are after here is to change the link parser itself, so I think it would be in myst-to-react, maybe somewhere around

myst-theme/packages/myst-to-react/src/links/index.tsx

Lines 25 to 55 in e549832

	function InternalLink({ url, children }: { url: string; children: React.ReactNode }) {
	const Link = useLinkProvider();
	const site = useSiteManifest();
	const page = getPageInfo(site, url);
	const baseurl = useBaseurl();
	const skipPreview = !page || (!page.description && !page.thumbnail);
	if (!page || skipPreview) {
	return (
	<Link to={withBaseurl(url, baseurl)} prefetch="intent">
	{children}
	</Link>
	);
	}
	return (
	<HoverPopover
	card={
	<LinkCard
	internal
	url={url}
	title={page.title}
	description={page.description}
	thumbnail={page.thumbnailOptimized || page.thumbnail}
	/>
	}
	>
	<Link to={withBaseurl(url, baseurl)} prefetch="intent">
	{children}
	</Link>
	</HoverPopover>
	);
	}

[stevejpurves]

I think this could be on the right track as this is where the url's get re-written based on the CONTENT_CDN and that is what is setting the image paths to localhost.

There is a possible change to make here and a parallel change needed in mystmd to make this work, I think.

[LecrisUT]

Probably worth mentioning the context for the other discussions in mystmd. A better solution is to keep all of the paths relative (and add .html suffix on .md files) in order to make the static site generation more portable

[stevejpurves]

I see... tagging these issues executablebooks/mystmd#994 & executablebooks/mystmd#994

so in using relative paths are you suggesting proxying to the content server when running the development server so get around the different port mapping? (I don't follow on the need for the additional .html suffix, though as all content files get .html extensions in the static build -- but I probably need to dig into the other issue a bit more)

[LecrisUT]

so in using relative paths are you suggesting proxying to the content server when running the development server so get around the different port mapping?

Kinda, basically this fixes both the static site generation and serving behind a reverse-proxy because in both cases it will navigate based on whatever url it was served, beit file://, https://, etc.

I don't follow on the need for the additional .html suffix

For context, you can check: https://mystmd-temp.readthedocs.io/latest/ which was generated from the static builder. (The site is not navigable¹). Yes, all html files were downloaded, but the links were those of react which did not add the .html suffix so that they are navigable. On the other hand sphinx always adds .html suffix to the page links, mirroring the .md file structure.

Footnotes

1. https://github.com/executablebooks/mystmd/issues/984 ↩