Live data from Hacker News

Better HTTP server routing in Go 1.22

eli.thegreenplace.net

31–40 of 236 posts

Re: Better HTTP server routing in Go 1.22

#31

One thing I don't like about default ServeMux is that addresses are prefixes. So `mux.HandleFunc("/"...)` always handles _everything_. And there is no easy way to say "no, just handle exact matches, plus maybe ? queries". As gorilla/mux does. I don't think that is changed in the new go?

I would say that unless specified differently this bit of the documentation[1] still applies (second paragraph):

> Longer patterns take precedence over shorter ones,

https://pkg.go.dev/net/http#ServeMux

Re: Better HTTP server routing in Go 1.22

#32
post #3

As I commented[1] I think the syntax is flawed in the proposal. You need to weirdly create a magic string to define your handler. Why not make it an actual argument, then using already existing constants is easier. [1] https://github.com/golang/go/issues/61410#issuecomment-16580...

What's wrong with automatically registering a HEAD route?

"The HTTP HEAD method requests the headers that would be returned if the HEAD request's URL was instead requested with the HTTP GET method. ". So it goes against the HTTP spec.

Re: Better HTTP server routing in Go 1.22

#33

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.

Re: Better HTTP server routing in Go 1.22

#34
post #24
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

Yes, but the ownership transfer happened quite some time after the project was tagged as archived, which from my side was a flag to move to a solution which is actively maintained. But i am glad to see that the project is getting attention again, i liked using gorilla/mux. But its even nicer that there is going to be out of the support for similar baked into golang.

Re: Better HTTP server routing in Go 1.22

#35
It's a nice change for little experimental programs, but production servers need lots of functionality that third party routers offer, like request middleware, better error handling, etc. It's tedious to build these on top of the native router, so convenience will steer people to excellent packages like Gin, Echo, Fiber, Gorilla, Chi, etc.

Re: Better HTTP server routing in Go 1.22

#36
Man I really really dislike this proposal. Putting the http request method into the URI... an just sometimes... oh and maybe do "POST,PUT,PATCH /something". Just no thank you. Make a dedicated method that accepts http request method names if you must do something.

Re: Better HTTP server routing in Go 1.22

#37
post #11
post #3

As I commented[1] I think the syntax is flawed in the proposal. You need to weirdly create a magic string to define your handler. Why not make it an actual argument, then using already existing constants is easier. [1] https://github.com/golang/go/issues/61410#issuecomment-16580...

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.

Re: Better HTTP server routing in Go 1.22

#39
post #16

Good one less external dependency. As a side note sqlc + postgres + templ (kindah jsx for go) + htmx + tailwinds has being extremely productive stack to develop in

I thought you had mistyped template there but actually no, templ is some other package different from the stdlib one. I had a quick look on its documentation and it seems quite neat!

I was hoping that bud with svelte compilation would fill this gap, but looks like templ is a nicer alternative.

Re: Better HTTP server routing in Go 1.22

#40

One thing I don't like about default ServeMux is that addresses are prefixes. So `mux.HandleFunc("/"...)` always handles _everything_. And there is no easy way to say "no, just handle exact matches, plus maybe ? queries". As gorilla/mux does. I don't think that is changed in the new go?

From the proposal:

"There is one last, special wildcard: {$} matches only the end of the URL, allowing writing a pattern that ends in slash but does not match all extensions of that path. For example, the pattern /{$} matches the root page / but (unlike the pattern / today) does not match a request for /anythingelse."

Post reply on HN