set default base_path hono /companion + allow to customize it

[unixfox]

fixes #118

linked to iv-org/invidious#5266

This commit set the default base_path to /companion. The benefits are:

• one route for all things about companion, easier for configuring the reverse proxy. less error-prone.
• will be easier to implement proxy the requests from invidious to companion if public_url is not configured. In order to avoid having to touch the reverse proxy. from [Feature request] Invidious companion: quality of life improvements invidious#5215
  because there will only need one route to create in invidious instead of multiples one (/latest_version and so on)
• since all the paths will be under one route, we can add easily new paths without asking the user to update their reverse proxy

The big downside:

• This will set the default base_path to /companion, so all current setups will need to update their config or set the base_path to /.
  But I think this is okay wise, since companion hasn't fully landed into the core of invidious.
  I'll do an announcement about it.

[alexmaras]

I get a 404 with this when adding the /companion path to the private_url field in the invidious config. The problem is that we use HTTP::Client.new(url) in Invidious to create the client pool:

https://github.com/iv-org/invidious/blob/7579adc3a3f23958afc4f11c9c52302f9962f879/src/invidious/yt_backend/connection_pool.cr#L102

That method ignores all path information as per the docs, so we have it being called with just the base URL.

Is there a configuration approach you think makes sense here?

Or would invidious need updating to respect the base path in the config or have a base path configuration option?

[unixfox]

Yes I'm currently modifying the code of invidious for that.

[unixfox]

Created the PR: iv-org/invidious#5266

[alexmaras]

Cool, I'll do some testing with the invidious branch

[alexmaras]

Looking good, and working well with the linking invidious branch.

Seeing as this won't work without the corresponding branch merged, it'll have to hang around in this branch for a while for it to get into an invidious release.

[alexmaras]

Suggested change

	base_path: z.string().default(
	Deno.env.get("SERVER_BASE_PATH") || "/companion",
	),
	base_path: z.string().regex("^/").default(
	Deno.env.get("SERVER_BASE_PATH") || "/companion",
	),

Might be worth considering adding a quick regex check here to ensure it's prefixed with a forward-slash. Without it (i.e. base_path = "companion" in the toml), companion starts up fine but doesn't work in a non-obvious way:

The suggestion is untested.

[alexmaras]

if you don't plan on having configurability on the invidious side of the base path as per iv-org/invidious#5266 (comment), personally I feel like it'll just be misleading for it to be configurable here. Is there a use-case for a configurable base-path on companion when somebody would need to set up some reverse proxy to make it compatible with invidious anyway?

Personally I feel like it should be configurable on both sides or neither. I'm fine with neither. If there's a good reason to allow configurability on companion without having it in invidious, let me know.

Alternatively, an undocumented configuration item could be reasonable if there's a plan to have it on invidious too. If there's no plan to do that, I don't really see the point.

[unixfox]

Well my idea was that you can configure Invidious for Invidious companion in two ways:

• Not specifying public_url. Invidious will configure the traffic for companion in the frontend to go through Invidious.
  This is mainly for beginners that struggle to setup a reverse proxy or usage of no reverse proxy.
• When specifying public_url, it does what it currently does. The traffic in the frontend for companion is sent directly to it.
  This is mainly for people that knows how to configure a reverse proxy and public instances maintainers.

In the first case, you do not really care about the name of the path, it can be /companion, /wood, /rock. It's transparent to the user. Invidious proxy all the traffic. Hence why it doesn't make sense to let the ability configure the base_path, the traffic is proxied using the internal network.

In the second case, with this improvement, everyone will just have to configure one route in their reverse proxy and the companion is fully configured. No messing up with /latest_version, /dashmanifest and so on.

The second case does not use the built-in proxy in Invidious for companion, so https://github.com/iv-org/invidious/pull/5266/files#diff-b83bd9a4ffeb9402d24fe6ade99f304367e1ee03b6cd25dac08b94160b034cf0R226-R229 does not apply to the second case.

You can still choose whatever path name you want since you have the control to do it through private_url and public_url, same in your reverse proxy routes.

Do you understand better? Do you think there are flaws in this idea?

[unixfox]

We could have harcoded the base_path to /companion but:

• I wanted to let existing setups the ability to quickly get the old base_path which is / when this PR is merged and not having to possibly change many things in their existing setup.
• Anybody can configure the base_path, this is considered a nice improvement in flexibility that doesn't cost us too much.
  Could allow the ability to have multiple companions under the same domain for example.

[alexmaras]

If you change the base_path in companion, the only way invidious could communicate with it would be if you put a reverse proxy in front of it to remap that base path back to /companion, right? This change doesn't only affect public traffic, but all traffic. So the beginner use-case is fine, and the second use-case is covered even if the path is hard-coded.

I wanted to let existing setups the ability to quickly get the old base_path which is / when this PR is merged and not having to possibly change many things in their existing setup.

The only way I can see this being helpful is if they don't want to update invidious but do want to update companion. If we're interested in supporting that then I guess we'd need to do this.

Anybody can configure the base_path, this is considered a nice improvement in flexibility that doesn't cost us too much. Could allow the ability to have multiple companions under the same domain for example.

This is the bit I'm not really getting. If they did this, they have to have a reverse proxy set up to re-route /fancy-custom-path to /companion in order for the private_url to work, no? In which case they'd have 2 separate setups for the reverse proxy, one for internal comms with invidious and one to place them all on the same domain.

Am I misunderstanding anything with the private_url? If you change the base path, invidious can't communicate with companion unless you re-route it back to /companion for the purposes of the private communication, right?

To be clear, I completely agree that it's useful to put it on a path in order to make reverse proxying simpler, but I'm not sure how configurability on only one side works without having to do some really weird reverse proxy setups.

At the end of the day, I'm not that fussed - if this helps someone's setup, great. I'm just a bit confused as to the utility and supporting it may prove a bit complex to explain. If you think it's worth keeping the configurability here, then by all means go ahead.

[unixfox]

Thanks for your comments.

Yes you are probably misunderstanding what I'm changing. There isn't something that will really change with private_url. If the Invidious backend and the companion are in the same internal network, the only thing you will have to do is to add /companion to "private_url".

Invidious backend will still be able to communicate directly with the companion. No need to do any complex change in your reverse proxy.

I made a diagram for better understanding in which case for the new changes:

[alexmaras]

Apparently I've misunderstood some of the code on the invidious side. This works great even when changing the base_url. I should have just tested it out 😅 sorry for the confusion. All of the changes are working well here - I only have this suggestion: #121 (comment)

[Copilot]

Pull Request Overview

This PR centralizes all companion-related endpoints under a configurable base_path (defaulting to /companion), updates handlers and tests to honor it, and adjusts deployment settings.

• Add base_path to configuration schema and example
• Configure Hono with .basePath() and prefix routes/redirects
• Update tests to derive host, port, and path from config; adjust Dockerfile env vars

Reviewed Changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/lib/helpers/config.ts	Introduce server.base_path with default /companion
config/config.example.toml	Add commented base_path example key
src/main.ts	Apply .basePath(config.server.base_path); enhance logs
src/routes/invidious_routes/**/*.ts	Prefix URLs and redirects with config.server.base_path
src/tests/main_test.ts	Import parseConfig; use dynamic host/port/base_path
Dockerfile	Define companion path env; update health check path