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

41–50 of 236 posts

Re: Better HTTP server routing in Go 1.22

#41

Post by vhcr »

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…

Getting an error instead of the incorrect data because the route that was actually ran was another one is pretty good for debugging. I have actually ran into this with Django, one route was missing the ending "$" regex.

Re: Better HTTP server routing in Go 1.22

#43

Post by danpalmer »

vhcr wrote: post #41
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…

Getting an error instead of the incorrect data because the route that was actually ran was another one is pretty good for debugging. I have actually ran into this with Django, one route was missing the ending "$" regex.

I get the frustration, but URL routing correctness is fairly trivially tested in Django and other frameworks to work around this issue, whereas it sounds like the matching algorithm here simply does not support certain common use-cases.

Re: Better HTTP server routing in Go 1.22

#44

Post by danpalmer »

figmert wrote: post #24
Cupprum wrote: post #22

The gorrila/mux project is weird and I am confused by it. Last year the maintainers archived the gorrila/mux project. Therefore i switched to another multiplexor called gin-gonic. Now as i saw the OP mentioning it in their blog, i went to take a look at the gorrila/mux project again to verify i correctly remembered the project to be archived. Apparently its not archived anymore, which brings the stability of the whol…

The ownership transfer was publicly announced in quite a few places. Most notably gorilla's blog[0], but also on Reddit[1] as well as HN[2], though it didn't get much reaction on HN. [0] https://gorilla.github.io/blog/2023-07-17-project-status-upd... [1] https://www.reddit.com/r/golang/comments/1528e25/gorilla_web... [2] https://news.ycombinator.com/item?id=36935541

In my experience most developers are not connected to the development processes of their dependencies. Maybe they should be, I think there's an argument for it, but with so many dependencies there's only so much time and attention. I think any migration such as this should be done on the assumption that most people won't know it's happening.

Re: Better HTTP server routing in Go 1.22

#45

Post by kjksf »

jamescun wrote: post #18

I don't like this. Is there a reason for using a stringified method prefix? I'd prefer the type safety of verb-specific methods (i.e. mux.Get, mux.Post etc) than magic strings validated at run time. Additionally editors can autocomplete/intellisense methods.

Adding this is so trivial. If it really, really bothers you that much:

    func Get(mux, uri, handler) { mux.HandleFunc("GET " + uri, handler) }
Obviously skipped the types for brevity.

Re: Better HTTP server routing in Go 1.22

#46

Post by jchw »

Interesting. Now that the mux can match methods, I wonder what happens when you match a route but not a method. Do you get a 404, or a 405?

Apparently, a 405 with a properly-populated Allow header.

https://cs.opensource.google/go/go/+/master:src/net/http/ser...

I know people don't love the stringly-typed interface, but rather than typo the HTTP method name, I suspect I'm more likely to simply type the wrong thing in correctly anyways. So I'd be fine with having static analysis warn about bad syntax personally.

For what it's worth, though, in my opinion, you probably shouldn't use the default serve mux if you already have advanced needs; there are plenty of options out there that are more suitable to different use cases, and if you're already doing dynamic route generation, it may wind up being less effort to just write your own router rather than try to munge whatever data structures you have into an existing router's.

Re: Better HTTP server routing in Go 1.22

#48

Post by fsociety »

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…

If it panics, you discover it instantly and can fix. If it didn’t panic, you could unknowingly deploy and rely on behavior you did not know about until it is an issue.

Re: Better HTTP server routing in Go 1.22

#49

Post by kjksf »

imetatroll wrote: post #37
donatj wrote: post #11

Earlier quoted context omitted.

While I do agree it’s kind of strange, the reasoning is pretty clear. The desire to not break or change the existing public interface.

Just add a new method with a new name. Vastly better than the proposal at hand.

Is it vastly better, though?

With this proposal if you already have an app using mux, you can change one line and you have app using new mux which you can then evolve to take advantage of additional capabilities.

With new name you have to rename all your codebase.

Not to mention that writing a wrapper with an API to your liking is few trivial lines of code so this is bike shedding at its finest.

Re: Better HTTP server routing in Go 1.22

#50

Post by tazjin »

jamescun wrote: post #18

I don't like this. Is there a reason for using a stringified method prefix? I'd prefer the type safety of verb-specific methods (i.e. mux.Get, mux.Post etc) than magic strings validated at run time. Additionally editors can autocomplete/intellisense methods.

If you want type safety, pick a type-safe language.
Post reply on HN