Semantics of url rewrite prefix replace - clarifications required

[LiorLieberman]

This is a followup to a surprisingly long thread on slack.

Our spec has a very detailed table of expectations for ReplacePrefixMatch field. However it does not cover the case where the Prefix Match(not the replacement) is "/".

Adding the spec table here for convenience:

// Request Path | Prefix Match | Replace Prefix | Modified Path
// -------------|--------------|----------------|----------
// /foo/bar     | /foo         | /xyz           | /xyz/bar
// /foo/bar     | /foo         | /xyz/          | /xyz/bar
// /foo/bar     | /foo/        | /xyz           | /xyz/bar
// /foo/bar     | /foo/        | /xyz/          | /xyz/bar
// /foo         | /foo         | /xyz           | /xyz
// /foo/        | /foo         | /xyz           | /xyz/
// /foo/bar     | /foo         | <empty string> | /bar
// /foo/        | /foo         | <empty string> | /
// /foo         | /foo         | <empty string> | /
// /foo/        | /foo         | /              | /
// /foo         | /foo         | /              | /

The ambiguity mostly comes down to the case where Prefix Match is "/". Below are a few examples:

// Request Path | Prefix Match | Replace Prefix | Modified Path
// -------------|--------------|----------------|----------
// /bar         | /            | /xyz           | /xyz/bar (AND NOT "/xyzbar")
// /bar         | /            | /xyz/          | /xyz/bar (AND NOT "/xyz//bar")
// /            | /            | /xyz           | /xyz (AND NOT "/xyz/")
// /bar         | /            | <empty string> | /bar (And NOT "bar")
// /            | /            | <empty string> | / (AND NOT "")
// /            | /            | /              | /

AND NOT is a language I used to reflect the proposed standardization. You can also be read it as OR if you have a different opinion.

Although there is no easy way in envoy to achieve this behavior (other non-envoy implementations, please shout if this is easily possible with your proxies), @howardjohn came up with a regex that makes this possible (ref https://github.com/istio/istio/pull/54939/files#diff-a0e8831b6aefb0ef9b2cd269fcd726b26fd1104120950952b5217a7b104ba153R1668-R1669)

Hoping this thread would result in a change to our spec to explicitly iron it out.

/cc @mikemorris @arkodg @robscott @howardjohn @kflynn

[kflynn]

I made this suggestion on Slack:

I’m wondering how well it would work to simply say that:

• if the rewrite prefix starts with a /, make sure the rewriting pattern does too, and
• if the rewrite prefix ends with a /, make sure the rewriting pattern does too.

That would imply that your “rewrite prefix / to /xyz” would become “rewrite prefix / to /xyz/“, which I think is likely to always be what people expect. 🤔 It still leaves the door open for “rewrite /foo to /bar”, but maybe that’s a necessary evil…

I think that making that change in validation could resolve this ambiguity, and even without validation, making this change to the spec would let implementations refuse rewrites that are likely to cause trouble. Anyone else have thoughts?

[howardjohn]

I think that making that change in validation could resolve this ambiguity, and even without validation, making this change to the spec would let implementations refuse rewrites that are likely to cause trouble. Anyone else have thoughts?

I don't really understand the suggestion. What is a rewrite prefix and rewrite pattern? Might help to give some examples and use the same terms are the tables above (Request Path | Prefix Match | Replace Prefix | Modified Path) so we don't get things mixed up?