Re: [go-nuts] call for data on HTTP routing
I wanted to make a quick observation w/r/t Ian's suggestion of not
registering ambiguous patterns. The tradeoff isn't ultimately about what
behaviors can be associated with what routes, but around what is required
to register routes. To intentionally use the kinds of routes we'd interpret
as ambiguous, it might be plausible to (1) register a methodless pattern,
and move the method-matching into the associated handler. Or, (2) register
a methodless pattern with e.g. a blanket 404 or 405 handler, and then
register a the same pattern with a method and a more active handler. Or,
something else - it would add friction to setting up this kind of routing
logic (maybe more verbose, maybe more explicit), but not prohibit it.
(1)
mux.HandleFunc("/foo/", func...
...
if req.Method == http.MethodGet ...
...
(2)
mux.Hanlde("/foo/", notReallyFooHandler)
mux.Handle("GET /foo/", fooHandler)
On Thursday, June 1, 2023 at 2:34:54 PM UTC-7 Ian Lance Taylor wrote:
> On Thu, Jun 1, 2023 at 2:23 PM 'Jonathan Amsterdam' via golang-nuts
> 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
>
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to golang-nuts+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/b90c13c1-5fcd-41a0-aba1-2f529be3828fn%40googlegroups.com.
Re: [go-nuts] call for data on HTTP routing
On Thu, Jun 1, 2023 at 2:23 PM 'Jonathan Amsterdam' via golang-nuts 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 -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/CAOyqgcXuDR3ueTKT1c1v4ZsttBTdiqnrHD7HBEKjb1OfpaMyEg%40mail.gmail.com.
[go-nuts] call for data on HTTP routing
At https://github.com/golang/go/discussions/60227, we're discussing enhancements to the standard library's http.ServeMux routing. Two issues have arisen that we could use your help on. The first is easy to state: does fast routing matter? Are there Go web servers for which http.ServeMux is too slow, where it consumes a significant fraction of the serving latency? My position (which is also the null hypothesis) is that no, for the vast majority of applications routing time is noise. Some evidence for that: the gorilla/mux router (https://github.com/gorilla/mux) is about 60 times slower than the fastest routers, but as far as we can tell it's still widely used (despite being unmaintained for two years). Change my view! Do you have a production service for which you had to abandon http.ServeMux because it was too slow? Tell me about it. Specific routing schemes and benchmarks are a plus. 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? Thanks in advance for your help. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/0b53f667-4ac2-4910-a49b-17a38e486de1n%40googlegroups.com.
