Strip prefix in the forwarded request

[jeanblanchard]

Scenario:

• I have fabio set up to listen to http://fabioserver/
• I have a route configured for a service, with prefix /myservice

When making a request to http://fabioserver/myservice/index.html, the service currently receives the forwarded request from fabio to /myservice/index.html
I would like to have the option to strip the prefix in fabio, so that the service would receive a request to /index.html

I currently have a homemade go proxy that does that, using http.StripPrefix. I may have the time to prepare a PR for this at some point, but no promises...

[magiconair]

This is a duplicate of issue #2 for which I've decided not to support this. See the reasoning in the closing comment.

[jeanblanchard]

OK I get the reasoning.

I would argue that this introduces a requirement that services need to know the route they serve.
You can't change the "mount" path for a service, say from /myservice to /legacy/myservice without changing the service itself (which may not be an option).

[magiconair]

I would counter that argument that it is better to add another handler to the service than splitting up your configuration across services and load balancer. I know you can do and lots of other load balancers allow you to do it but in our own setup we have had enough additional complexity with this that this actually led to the development of fabio in the first place.

[jeanblanchard]

... And I'm back...

It turns out I really need this after all. I tried to make all services have their prefix configurable, but this introduces a bit of complexity everywhere in the service, which I really want to avoid.
I think you'll agree that the services should not depend on the host where they are deployed. I believe the same is true for the path.
Stripping the prefix would allow services to work the same, regardless of the path where they are deployed.

Note that I do not suggest rewriting the urls in the responses (or maybe just Location headers), but instead encourage services to use relative urls.

Anyway, would you accept a pull request to add this option, or should I maintain my own fork ?

[magiconair]

I agree on the host but not the path but that doesn't really matter. Please start this discussion with a suggestion on how this should work from the configuration perspective so that we can decide what the best approach is. No promises since I'd like to see how you want to solve that first and also want to think a bit about edge cases.

[jeanblanchard]

On the configuration side, I'm thinking a global configuration flag in fabio.properties (proxy.prefix.strip?).

It's probably not necessary to allow each service/route to override the behavior.

After a first look at the code, the global config case seems to be pretty straightforward. I'm not sure yet how to handle the websocket case, I'll look into it.

[magiconair]

Why should this work only for a single, global prefix? Do you want to strip some of the path or all of it, for some of the services or for all of them, the same prefix for all services?

http://foo.com/service/user/index.html -> http://usersvc/index.html
or
http://foo.com/service/user/index.html -> http://usersvc/user/index.html

Can you explain a bit more what makes it so difficult to change the apps? Are these services you don't control or can't change or are they just too many?

[jeanblanchard]

I don't think it should work for a single global prefix. I think there should be a global option to strip the configured prefix for all services.

Basically to access an app behind a fabio proxy, you need to add a prefix to identify the app. I propose to remove the prefix from the requests so that the app works as if there were no proxy.

http://fabioserver/serviceprefix/user/index.html -> http://serviceserver/user/index.html

The idea for my case is that the services are third-party developed plugins, that should work the same regardless of where they are deployed.

[magiconair]

Does http://serviceserver/user/index.html need to know that /serviceprefix was stripped from the original request? (i.e. do we need to inject a header?)

I could extend the route add command with a strip <prefix> option which would allow to control this per route/target. The only question is how to encode that in the service registration.

In issue #42 I've outlined a more flexible notation for the tags, i.e. p-host/path?key=val&key=val... which would provide the mechanism to add a strip=/serviceprefix option.