Fabio fails to strip the prefix if the url prefix does not start with the strip option value

[pvandervelde]

We have a web service running which serves a site on

http://myhost/artefacts

And the consul service configuration contains the following tag

urlprefix-/artefacts/installers strip=/installers host=dst

I was expecting that this would make fabio strip the path correctly but what happens instead seems to be that the full prefix is passed on to the service, i.e. fabio calls http://myhost/artefacts/installers.
I assumed that the strip option would indicate to fabio which part of the prefix to remove however it seems that it only works if the option contains the first part of the url prefix.

Is there a way to get fabio to strip the selected text from the prefix?

[deuch]

Did you put the three options in the same consul tag ?

[pvandervelde]

Yes, that entire line is one single consul tag. I've got other services (with other prefixes / strip / host options) and those work just fine but they strip either just the start of the prefix or the entire prefix.

[magiconair]

@pvandervelde fabio is not intended to be a full nginx replacement which mangles routes and rewrites URLs. It is primarily a stateless router which forwards requests to services which claim that they can handle them without changing them.

If your service needs to handle requests from /artefacts/installers why not add a handler for this to the code?

The main motivation for the strip prefix option was that entire sets of services were proxied behind a common URI which made it impractical to change every service. I don't see that use case for stripping the suffix but maybe you can explain your use case a bit more.

[pvandervelde]

In our case we're proxying using fabio to proxy a set of sites / services that we use in our build infrastructure. Most of these services aren't our own services, they're third party tools that we run so we have very little control over what handlers there are. The goal is to provide the developers with a single 'site' that looks like it has all the services they need to interact with our build infrastructure. So for instance the site that fabio presents to the users looks like

myhost.mycompany.com
    builds
    artefacts
        installers
        images
    services
        rabbitmq

Where builds points to a jenkins instance, artefacts/files points to a caddy webserver instance, artefacts/images points to a web service and services/rabbitmq points to a local RabbitMQ instance. The problem described was that the caddy webserver was serving pages on

myotherhost.mycompany.com/artefacts

Because we have multiple artefacts sites we wanted to combine them under the artefacts directory, hence we decided to put it under artefacts/files.

I get that this is probably not what fabio was designed for and we can probably figure a way around it with some effort. I was just interested to see if I configured something wrong or if this was by design (which is perfectly fine by us).

[magiconair]

@pvandervelde you could use strip=/artefacts/installers and access the other service under / I don't see the point in the upstream service to respond to /artefacts when in fact it is providing /installers. What am I missing?

[pvandervelde]

Probably the fact that my explanation is crap. There are several other web services running on that machine so we can't use the machine root because it could collide with the other services, however we might be able to make it respond to /installers instead.

In the end it doesn't matter very much we'll be able to work around it :) I was just curious to see if I'd missed anything because I assumed that strip just replaced whatever term with an empty string, but that is not the case. Maybe it's more of a case of me not reading the documentation correctly.

[magiconair]

My main lesson from the eBay team I ran was that adding this kind of complexity caused more issues downstream even if it fixed your immediate problem at hand. fabio was the result of that constant maintenance pain, the fact that everything had to be looked up instead of being derived. My main motivation for writing it was to simplify the architecture by actually removing entire components and workflows, e.g. you do not have to coordinate the deployment and maintenance of an LB configuration in tandem with your service config. The services announce what they can serve and fabio will just serve them. We literally ran fabio for months without restart/reconfigure and even more literally forgot that it was there at all.

What you are trying to do feels like going against that very motivation and that usually makes me question the approach as a whole.

Therefore, my advice is to push (invest time) for having the services advertise and handle what they actually claim they handle. It pays off.

[pvandervelde]

Sounds sensible. For the immediate time we'll work around it while we update the services. Thanks