Add a new identifier that can rewrite the request path

[briansmith]

Here are two questions where people expect that dtabs allow rewriting the request path:

• https://discourse.linkerd.io/t/url-based-routing/545
• https://stackoverflow.com/questions/44500828/linkerd-dtab-expression-not-transforming-as-expected

I personally was also surprised to find that this kind of rewriting of request paths is not currently possible with the built-in functionality. Linkerd should implement a new namer that is like io.l5d.rewrite but which allows the actual request path to be rewritten, similar to how io.l5d.path with consume allows path segments to be removed from the beginning.

[adleong]

Thanks for filing this, @briansmith. I'll try to use this space to shed a bit of light on this topic and hopefully clear up some confusion. I agree with you that Linkerd's behavior in this regard is surprising and unintuitive.

It is not actually possible to create a namer that mutates requests. Namers operate on Finagle Names and NameTrees which means that a namer does not have access to the request object. Any rewrites of the Name that a namer does are for the purposes of routing only and cannot affect the request itself. Likewise, dtabs operate on Finagle Names and not requests and don't have access to the request object.

I think a lot of the confusion around this comes from the fact that Finagle Names are slash delimited and look very much like request paths and it can be easy to conflate the two, especially when the io.l5d.path identifier is involved.

In contrast to Namers, identifiers (such as the io.l5d.path identifier) DO have access to the request object and therefore have the ability to mutate requests. A detailed description of identifiers and namers is available on the routing in-depth doc.

Even though identifiers have the ability to mutate requests, we've tried to avoid doing this as much as possible. This is because a request can transit multiple Linkerds in a single service-to-service hop (2 Linkerds in a linker-to-linker setup, potentially more in more complex setups). If each Linkerd that a request passes through modifies it, each Linkerd will potentially see a request with different properties and may therefore make different routing decisions. This isn't necessarily wrong, but it makes routing much more difficult to reason about. The one exception that we have made (by popular demand) is for path consumption in the io.l5d.path identifier. But even this introduces a common pitfall where if the path is consumed by the first Linkerd then the second Linkerd will be unable to route.

Of course, request modification is a powerful and sometimes necessary feature so we can't bury our head in the sand and avoid it forever. But we have not yet spent the time thinking of a way to introduce it into Linkerd in a way that minimizes cognitive load and complexity, especially as it relates to routing and policy as a request transits multiple Linkerds.

[briansmith]

I changed the summary of this issue to say "new identifier" instead of "new namer" to better reflect what seems to be needed.

I have to admit that I don't understand the aversion to identifiers mutating the request URI. I think there are probably two mental models that are common, the linkerd model and another model that is what the people requesting this feature have. I can understand that if one has fully internalized the linkerd model then the other model might lead to confusing results. However, there's no denying that at least some people (probably many people) have a need for this functionality. Like Alex said, linkerd has already introduced the concept of mutating identifiers with the Path identifier, so a new one that mutates the request URI more drastically doesn't seem to actually introduce anything new conceptually.

[IssueHuntBot]

@BoostIO funded this issue with $10. See it on IssueHunt