On Thu, Jun 1, 2023 at 2:23 PM 'Jonathan Amsterdam' via golang-nuts
<
golan...@googlegroups.com> wrote:
>
> The second question is about a specific routing scheme, and here I have no preconceived notions. Here is the context: given two routing patterns that might otherwise conflict, we'd like to allow both by preferring one over the other, where this makes sense. Currently, we prefer a pattern that specifies a method over one that doesn't; and after that, we prefer a pattern with a more specific path. For example,
>
> GET /foo/
>
> wins over
>
> /foo/
>
> because the first specifies a method, but it loses to
>
> GET /foo/bar
>
> because the latter's path is more specific (it matches only "/foo/bar", while "/foo/" matches any path beginning "/foo").
>
> Those three patterns make sense together:
>
> GET /foo/bar match a specific GET request
> GET /foo/ match any GET request beginning /foo
> /foo/ match a request with any method beginning /foo
>
> But what about these two patterns:
>
> GET /foo/
> /foo/bar
>
> The first pattern specifies a method, but the second has a more specific path. Which should win? Or should this combination be disallowed because it's too confusing? My question is, do any pairs of patterns like this show up in practice? And if so, which one should take precedence?
This is an obvious point, but in general for any case where two
different patterns can match an HTTP request it is possible to write a
single pattern that matches both and then let the function
differentiate based on the precise request. On the other hand, when
it is unclear which pattern is going to match a specific HTTP request,
it seems quite possible for the programmer to make a mistake as to
which one will match, and since the cases are by construction obscure
it seems easy to fail to detect such a case in testing.
This suggests that one possible approach is to use a very simple
request matching rule that no reasonable person can misunderstand, and
for the router to give an error on ambiguous cases.
Ian