Use relative url for resources

[hmacias-avaya]

This is a "work in progress" PR trying to address https://github.com/trunk-rs/trunk/issues/626 and https://github.com/trunk-rs/trunk/issues/668

I have not gone through all the different resources trunk bundles so I've likely missed something.

In summary, this PR will make base url default to "./" if it was empty or "/". This results in resources being loaded relative to whichever original resource was requested. For example browser loads html, html refers to js/css/wasm, the browser tries loading the js/css/wasm from the same current path. https://server.som/some_path/and_some_more/index.html refers to ./something.js and ./app.wasm which loads https://server.som/some_path/and_some_more/something.js https://server.som/some_path/and_some_more/app.wasm

Without this change: https://server.som/some_path/and_some_more/index.html refers to /something.js and /app.wasm which loads https://server.som/something.js https://server.som/app.wasm which does not work.

Similar thing for the _trunk/ws route for the reloading websocket.

[ctron]

Thanks for the PR. I did a quick look at it, and rebased it too. I think it needs some more work, but goes in the right direction.

What I don't like is the auto-detection for the trunk ws path. From what I understand, that would fail in cases where the user loads the application with a sub-path. I guess trunk would need to inject that path, like it does with the other information.

Also using a relative path will lead into trunk panicking when using serve:

thread 'tokio-runtime-worker' panicked at src/serve/mod.rs:299:27:
Paths must start with a `/`

[ctron]

The whole idea of using ./ as a default seems to work quite poorly when using the browser's History API. A reload of the page with a sub-path then turns into the problem that all resources try to get loaded from that sub-path. I am not sure this is a reasonable default.

[hmacias-avaya]

ok perhaps I'm missing some fundamental stuff here.

What would be a minimum example of this scenario? Would the following be a valid scenario?

• yew application showing a "main" page and a link to a child page. clicking on child link loads child page
• child page has a "go back" button that uses the browser's history API to go back and should show the main page.
• user should be able to hit reload on main page and also on child page; all resources (including ws) should load correctly

[ctron]

Yes, I think that describes it. I am also taking a look at this problem right now. I've come up with a PR which is a bit different and captures more of the intent of the configuration … vs just trying to tweak strings until it fits.

My two main uses are:

• Allowing the current model of trunk serve, handling the absolute path for a public URL
• Allowing the same model, but behind a reverse proxy, adding a scope to the path, forwarding to trunk serve

I am trying to capture this in the configuration which is close to the current model, and provide overrides when necessary. Although I am not sure all the values always make sense. But the defaults should "just work".

[hmacias-avaya]

thanks, I definitely agree this not finished.

One of the challenges I faced trying to cover all scenarios is that I didn't know what the "all scenarios" were :)

Do we have a list of scenarios so that we can go over them all making sure we're covering all angles? Eventually even having some unit tests against these would help us make changes with a bit more confidence (I'd be happy to help wherever suitable).

For example:

• Using trunk serve with a subpath. Command: trunk serve --subpath whatever. Where do we expect the user to load the application from? e.g. http://ip/subpath/ What will index.html contain to point to the reload ws? will this "route correctly"?
• Using trunk behind a reverse proxy. Command: trunk serve. etc

if this is already documented or hinted somewhere please let me know

[ctron]

if this is already documented or hinted somewhere please let me know

Welcome to open source, PRs welcome, unfortunately no … :rofl:

The more positive answer I guess is in the comments I merged yesterday, which isn't published yet as the homepage doesn't have a "next version" documentation. There was an initial idea, trunk slowly outgrew this, breaking the original idea. But it was missing some knobs to compensate for scenarios that hadn't been covered. I think the PR adds those, keeping the original idea valid.

It would be great to have such a specification/documentation. Then again, if no one is doing it :shrug: … the situation seems to be just good enough.

[ctron]

I think the PR can be closed as the issue should be solved with trunk 0.19.0.