webui: add configurable base path support for subdirectory deployment

[ServeurpersoCom]

• Add configurable base path in svelte.config.js (default: '' for backward compatibility)
• Update all hardcoded URLs to use prefix for API calls and navigation
• Enables deployment in subdirectories (e.g., /llama, /ai, etc.) while maintaining root deployment compatibility
• Affected: fetch calls to /props, /v1, /slots and all goto/href navigation

Note: Current implementation assumes client and API share same base path. Future enhancement could separate client base path from API base path for advanced proxy/security configurations where only client UI is in subdirectory.

Make sure to read the contributing guidelines before submitting a PR

[mostlygeek]

Restoring the relative path behaviour of the previous UI would be a much better solution. The new UI likely broke for everyone using it behind a proxy and serving llama-server on something that is not `/'.

[ServeurpersoCom]

Restoring the relative path behaviour of the previous UI would be a much better solution. The new UI likely broke for everyone using it behind a proxy and serving llama-server on something that is not `/'.

You're right, that's exactly my case. I can add relative path behavior by adding a function that retrieves the current path to initialize the base. I tested pure relative everywhere (removing all leading / from fetch calls etc) but it breaks quite a few things. This configurable base path is the simplest solution I could find that doesn't break existing behavior.
Also conversations need this .htaccess:
RewriteEngine On
RewriteRule ^chat/[^/]+/?$ index.html [L]
Without it, browser F5 on a selected conversation makes 404 error on /chat URLs (Svelte virtual routes).
I also have many bugs on mobile with Svelte (can't delete or edit conversation titles, bad z-index on popups, sidebar closing randomly etc.) that I'm trying to fix in another pull request.

[mostlygeek]

I think avoiding new solutions to a problem that should not exist is the right strategy.

@allozaur, any thoughts on restoring the previous relative path behaviour?

[allozaur]

Hey guys! I will take a look at the relative paths subject tomorrow.

Also, @ServeurpersoCom i haven't had any of the issues with the UI that u described, can you create separate issue(s) with screenshots/videos and more details? I'll do my best to tackle them asap.

[ServeurpersoCom]

Hey guys! I will take a look at the relative paths subject tomorrow.

Also, @ServeurpersoCom i haven't had any of the issues with the UI that u described, can you create separate issue(s) with screenshots/videos and more details? I'll do my best to tackle them asap.

Here is the issue (and my proposal) : #16094

[isaac-mcfadyen]

Looks like SvelteKit's paths only work at build time which makes this PR incompatible with a large number of tools that wish to change the base path at runtime.

For example, https://github.com/mostlygeek/llama-swap runs the same llama.cpp server with different base paths for each model. Needing to recompile the server for each model greatly increases the burden of using the tool and is not directly compatible with the behavior pre-SvelteKit UI.

[isaac-mcfadyen]

I suspect we need to consider moving back to hash-based routing, as was done with the previous server, because:

• base is only able to be set at build-time
• We cannot use relative because we render multiple routes into one file (using the fallback config option) which means that relative paths just don't work.
• We cannot prerender because routes like /chat/<id> will not work.

When we moved to SvelteKit we dropped hash-based routing, which solves all this (relative paths will work the same on all routes with hash-based routing).

With SvelteKit we can use hash-based routing using the router.type option. The only caveat is that we need prepend # to all links in the app. If we want to go in this direction I can submit a PR for this later if wanted.

EDIT: opened PR #16157

[allozaur]

@ServeurpersoCom it will be better to go with #16157 proposed by @isaac-mcfadyen as the arguments he presented are very solid, but either way this PR got us much closer to solving the problem so i'd say this work did not go to waste 😉