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

51–60 of 236 posts

Re: Better HTTP server routing in Go 1.22

#51

Post by kjksf »

buzzdenver wrote: post #32
candiddevmike wrote: post #23

Earlier quoted context omitted.

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.

In practice much bigger practical problem is that no-one handles HEAD.

I sure don't.

And those that do probably aren't careful about HTTP headers either.

So in practice this an improvement for most.

And if you don't like how it works, there are plenty of alternatives to use.

Re: Better HTTP server routing in Go 1.22

#53

Post by badrequest »

danpalmer wrote: post #43
vhcr wrote: post #41

Earlier quoted context omitted.

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.

What common use-cases does it not support?

Re: Better HTTP server routing in Go 1.22

#54

Post by badrequest »

tazjin wrote: post #50
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.

Go is type safe.

Re: Better HTTP server routing in Go 1.22

#55

Post by badrequest »

gavinray wrote: post #47

It seems like a very bizarre design choice, especially by an official language team, to use prefix strings instead of an enum. For example: (Http.GET, "/path") Rather than the current: ("GET /path") Odd.

It adheres to the Go 1 compatibility promise.

Re: Better HTTP server routing in Go 1.22

#56

Post by ilyt »

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.

> I don't like this. Is there a reason for using a stringified method prefix?

Backward compatibility, they didn't wanted to change function signature nor add different method for it.

Re: Better HTTP server routing in Go 1.22

#57

Post by velcrovan »

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.

What kinds of routes would you generate dynamically that couldn't be implemented as wildcards in the match pattern? Genuine question

Re: Better HTTP server routing in Go 1.22

#59

Post by jbamsterdam »

mariusor wrote: post #31
shp0ngle wrote: post #27

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

No, it does not. The length of the pattern isn't important anymore, only whether it overlaps with other patterns.

Re: Better HTTP server routing in Go 1.22

#60

Post by ilyt »

gavinray wrote: post #47

It seems like a very bizarre design choice, especially by an official language team, to use prefix strings instead of an enum. For example: (Http.GET, "/path") Rather than the current: ("GET /path") Odd.

It's mistake they can't fix without breaking existing code or introducing new function.

But I'd prefer just a bunch of mux.GET/mux.POST/etc functions instead of that.

Post reply on HN