if you strip the wildcard, should the value still be available in pathvalue?

and if you're already using wildcards, why does your handler care about the path?

The existing behavior of http.StripPrefix copies the entire Request and only modifies the path. I think maintaining the existing behavior in this version results in fewer surprises, so yes, the stripped wildcard should still be available in PathValue. It's also very useful to have access to it in sub-handlers.

@jba

I'm with @seankhliao on this. I don't see the usefulness. If we did do it, we'd have to keep access to the stripped wildcard values, as @egtann points out, but that puts the http.Request into an odd state—wildcard values with no corresponding wildcard in the path. (Admittedly, you could also get to that state with SetPathValue.)

@egtann, can you motivate this with two or three examples?

Sure, the big use-case is prefixing a path with some customer-specific identifier. Apps which allow a user to access different company accounts with a single login may employ a similar approach, so the URL itself is tied to a particular company when shared.

Here are some large (non-Go) examples. Shopify does this:

/store/{storeSlug}/...

Each handler needs access to that slug to do its job; it can't query the database for "all products" unless it knows "for which store?"

So if I hypothetically had Shopify routing set up in Go, it might use a top-level router to apply auth centrally, then have many sub-routers attached at different paths:

r.Handle("/store/{storeSlug}", http.StripPrefix("/store/{storeSlug}", storeHandler))
r.Handle("/settings", http.StripPrefix("/settings", userSettingsHandler))

// Then inside storeHandler:
sh.Handle("/settings", http.StripPrefix("/settings", storeSettingsHandler))
...

Gmail uses the same pattern in its URLs:

/mail/u/{intToIdentifyTheUser}/...

There are some workarounds that come to mind:

• Build a middleware which tosses things into context.Values.
• Pass the entire path to every sub-handler, and don't strip it at all.
• Roll your own replacement function for StripPrefix supporting this behavior.

All of these workarounds are fine. It just seemed like a surprising limitation of http.StripPrefix to need to build around given wildcard support is being added to the stdlib in other areas.

As just my own experience (without ever having looked into the StripPrefix implementation before), I naively expected it to strip a prefix in this way, and it took a while debugging to uncover the reason why my routes were responding with 404s. I've been coding professionally in Go for many years, so while it was a face-palm moment for me, I have to imagine I won't be the only one to hit this after wildcards land in 1.22.

Thanks for the examples, and for explaining exactly what your concern is.

I think the workarounds are fine, especially the second—don't use StripPrefix here at all. It seems to create more work than whatever benefit it provides.

But your point about expectations is well taken. We should add doc to StripPrefix that explains that it doesn't work with wildcards. It already says "the prefix must match exactly," so perhaps a bit more verbiage at that point would suffice.