Heya @MysticRyuujin,

This looks technically good, but the intention of the prefix detection was to route the client specific endpoints to the right client type.
Eg lighthouse provides a bunch of custom api endpoints with a /lighthouse/v*/... prefix. Dugtrio should forward these requests to lighthouse clients only.
I've added all clients just for completeness - I know not all clients have such custom apis ;)

The usual way to enforce a specific underlying client type would be via the X-Dugtrio-Next-Endpoint header or ?dugtrio-next-endpoint=xy query parameter.
We could probably add such client specific prefixes too, but I'd hide that behind a more advanced prefix to not interfere with the normal api namespace.
sth. like /_dugtrio/next:lighthouse/... or so.. not sure

Edit: I see the readme is also very misleading in describing this feature :D

I see, I did not consider the client specific APIs as being part of the routing logic, which makes sense.

I was purely going off the README in assuming that this was the use case, to query different clients via a path router.

Now I'm not sure the best path forward, other than to close the PR and attempt to make use of the headers only, but then perhaps the README should be updated to be less confusing 😆

Technically this PR still works, if you double prefix lighthouse lol but I think that's not what is intended.

curl -s -H 'Content-Type: application/json' http://localhost:8080/lighthouse/lighthouse/syncing
{"data":{"BackFillSyncing":{"completed":543392,"remaining":509184}}}

I thought of a compromise? Not 100% sure this will work, but if we only strip the prefix when it's NOT a standard beacon API endpont (/eth/v*) that "should" cover both use cases?

curl -s -H 'Content-Type: application/json' http://localhost:8080/lighthouse/syncing
{"data":{"BackFillSyncing":{"completed":549248,"remaining":503328}}}

curl -s -H 'Content-Type: application/json' http://localhost:8080/eth/v1/node/version
{"data":{"version":"Lighthouse/v8.0.1-ced49dd/x86_64-linux"}}

curl -s -H 'Content-Type: application/json' http://localhost:8080/caplin/eth/v1/node/version
{"data":{"version":"Caplin/v3.3.4-dirty linux/amd64"}}

I think that should work out.
But I'd rather do it the other way round:
if the prefix is followed by the standard beacon api pattern (.../eth/v*/...) then trim the prefix, otherwise leave it.

That should work with all future additions too if they follow the same path pattern with the version as second segment.

Edit: I just saw the commit now :D So yea, as you implemented it.