Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Better HTTP server routing in Go 1.22

eli.thegreenplace.net

Post reply on HN
Print view View original

231–236 of 236 posts

Re: Better HTTP server routing in Go 1.22

#231

Post by kunley »

oppositelock wrote: post #33
fideloper wrote: post #5

Forcing a panic when 2 routes are matched seems counter intuitive to me (versus, idk, every other web framework which uses the first-to-be-registered route that matches). Are there go-specific reasons for that? The edge case of "you might register HTTP routes in a bunch of places and it's harder to find that if multiple routes match" seems like something that be worked around with tooling. I've (ab)used the behavior…

The panics are really annoying. Sometimes, you generate routes dynamically from some data, and it would be nice for this to be an error, so you can handle it yourself and decide to skip a route, or let the user know. With the panic, I have to write some spaghetti code with a recover in a goroutine.

Mmmm, code with recover is just a valid code. Calling it spaghetti seems unjustified.

Re: Better HTTP server routing in Go 1.22

#232

Post by drdaeman »

cowl wrote: post #208
drdaeman wrote: post #182

Earlier quoted context omitted.

Not always, I can imagine a (weird, for sure) scenario where routes are a part of configuration, or are added dynamically at runtime. There’s `recover` of course, but I see no harm in returning an `error`, especially given that `errors.Join` is a thing now, so one doesn’t need to copy-paste ifs. The only reason not to is keeping the function signature intact.

And I see no Harm on making this extreme wierd usecase less user-friendly and force you to go through panic recover rather than force everyone else that will never get errors to handle errors.

It's not "extreme weird", just significantly less common, so just weird, but nowhere extreme. Dynamic routing isn't exactly unheard of, and isn't some sort of perversion - servers like Traefik and Caddy do this (except that they don't use stdlib mux, of course). Basically any DIY proxy with dynamic service discovery may need it, and while people typically pick off-the-shelf solution, some write their own lightweight one.

And panic/recover is not idiomatic Go here, as it's not an exceptional situation, just an error.

YMMV, of course.

Re: Better HTTP server routing in Go 1.22

#233

Post by pipe01 »

danpalmer wrote: post #180
superb_dev wrote: post #142

Earlier quoted context omitted.

The two routes `/foo/bar` and `/foo/*` are not ambiguous and would be allowed by the router

Are they? It seems that the latter matches the former. i.e. for the path `/foo/bar` there are 2 matching routes. One must take precedence, but this router doesn't appear to allow that. This may just be a syntax thing, I was being loose with syntax, and meant that the `*` would match anything for the purposes of this example.

It does allow that, the one without wildcards is more specific so it'll pick that one

Re: Better HTTP server routing in Go 1.22

#235

Post by cowl »

drdaeman wrote: post #232
cowl wrote: post #208

Earlier quoted context omitted.

And I see no Harm on making this extreme wierd usecase less user-friendly and force you to go through panic recover rather than force everyone else that will never get errors to handle errors.

It's not "extreme weird", just significantly less common, so just weird, but nowhere extreme. Dynamic routing isn't exactly unheard of, and isn't some sort of perversion - servers like Traefik and Caddy do this (except that they don't use stdlib mux, of course). Basically any DIY proxy with dynamic service discovery may need it, and while people typically pick off-the-shelf solution, some write their own lightweight…

do they though? first both of them and afaik all other routers need to reload so for all intents and purposes the routing table is static, you can not add routing rules during the runtime. (Their apparent "dynamism" comes because they sighup or reload the process to put the new rules in place).

Secondly and most importantly they don't error. Caddy will simply match the last declared rule while Traeffic has a system of priority labels and yet for conflicting rules with same priority again it will match the last one (or even worse a random one). Both of these are very dangerous because you may realise late (from statistic logs) that you are routing the wrong requests to the wrong handler, and have already missed countless calls that should have gone on the first declared one.

Post reply on HN