middleware.CleanPath
: new middleware that clean’s request path of double slasheschi.ServerBaseContext
in favour of stdlib http.Server#BaseContext
chi
dates back to 2016 with it’s original implementation as one of the first routers to adopt the newly introduced
context.Context api to the stdlib -- set out to design a router that is faster, more modular and simpler than anything
else out there -- while not introducing any custom handler types or dependencies. Today, chi
still has zero dependencies,
and in many ways is future proofed from changes, given it’s minimal nature. Between versions, chi’s iterations have been very
incremental, with the architecture and api being the same today as it was originally designed in 2016. For this reason it
makes chi a pretty easy project to maintain, as well thanks to the many amazing community contributions over the years
to who all help make chi better (total of 86 contributors to date -- thanks all!).
Chi has been an labour of love, art and engineering, with the goals to offer beautiful ergonomics, flexibility, performance
and simplicity when building HTTP services with Go. I’ve strived to keep the router very minimal in surface area / code size,
and always improving the code wherever possible -- and as of today the chi
package is just 1082 lines of code (not counting
middlewares, which are all optional). As well, I don’t have the exact metrics, but from my analysis and email exchanges from
companies and developers, chi is used by thousands of projects around the world -- thank you all as there is no better form of
joy for me than to have art I had started be helpful and enjoyed by others. And of course I use chi in all of my own projects too :)
For me, the asthetics of chi’s code and usage are very important. With the introduction of Go’s module support (which I’m a big fan of), chi’s past versioning scheme choice to v2, v3 and v4 would mean I’d require the import path of “github.com/go-chi/chi/v4”, leading to the lengthy discussion at https://github.com/go-chi/chi/issues/462. Haha, to some, you may be scratching your head why I’ve spent > 1 year stalling to adopt “/vXX” convention in the import path -- which isn’t horrible in general -- but for chi, I’m unable to accept it as I strive for perfection in it’s API design, aesthetics and simplicity. It just doesn’t feel good to me given chi’s simple nature -- I do not foresee a “v5” or “v6”, and upgrading between versions in the future will also be just incremental.
I do understand versioning is a part of the API design as well, which is why the solution for a while has been to “do nothing”,
as Go supports both old and new import paths with/out go.mod. However, now that Go module support has had time to iron out kinks and
is adopted everywhere, it’s time for chi to get with the times. Luckily, I’ve discovered a path forward that will make me happy,
while also not breaking anyone’s app who adopted a prior versioning from tags in v2/v3/v4. I’ve made an experimental release of
v1.5.0 with go.mod silently, and tested it with new and old projects, to ensure the developer experience is preserved, and it’s
largely unnoticed. Fortunately, Go’s toolchain will check the tags of a repo and consider the “latest” tag the one with go.mod.
However, you can still request a specific older tag such as v4.1.2, and everything will “just work”. But new users can just
go get github.com/go-chi/chi
or go get github.com/go-chi/chi@latest
and they will get the latest version which contains
go.mod support, which is v1.5.0+. chi
will not change very much over the years, just like it hasn’t changed much from 4 years ago.
Therefore, we will stay on v1.x from here on, starting from v1.5.0. Any breaking changes will bump a “minor” release and
backwards-compatible improvements/fixes will bump a “tiny” release.
For existing projects who want to upgrade to the latest go.mod version, run: go get -u github.com/go-chi/chi@v1.5.0
,
which will get you on the go.mod version line (as Go’s mod cache may still remember v4.x). Brand new systems can run
go get -u github.com/go-chi/chi
or go get -u github.com/go-chi/chi@latest
to install chi, which will install v1.5.0+
built with go.mod support.
My apologies to the developers who will disagree with the decisions above, but, hope you’ll try it and see it’s a very minor request which is backwards compatible and won’t break your existing installations.
Cheers all, happy coding!
ContentCharset
to check matching charsets. Thank you
@csucu for your community contribution!AllowContentType
handler for explicit whitelist of accepted request Content-TypesSetHeader
handler for short-hand middleware to set a response header key/valuechi.RegisterMethod("LINK")
and chi.RegisterMethod("UNLINK")
in an init()
functionMatch(rctx *Context, method, path string) bool
method to Routes
interface
and Mux
. Match searches the mux’s routing tree for a handler that matches the method/pathRouteMethod
to *Context
Routes
pointer to *Context
middleware.GetHead
to route missing HEAD requests to GET handlerfunc ServerBaseContext(h http.Handler, baseCtx context.Context) http.Handler
to func ServerBaseContext(baseCtx context.Context, h http.Handler) http.Handler
docgen
sub-pkg to https://github.com/go-chi/docgenrender
sub-pkg to https://github.com/go-chi/renderURLFormat
handler to chi/middleware sub-pkg to make working with url mime
suffixes easier, ie. parsing /articles/1.json
and /articles/1.xml
. See comments in
https://github.com/go-chi/chi/blob/master/middleware/url_format.go for example usage./:id
to /{id}
for even more flexible routing, such as
/articles/{month}-{day}-{year}-{slug}
, /articles/{id}
, and /articles/{id}.{ext}
on the
same router/{paramKey:regExp}
for example:
r.Get("/articles/{name:[a-z]+}", h)
and chi.URLParam(r, "name")
Method
and MethodFunc
to chi.Router
to allow routing definitions such as
r.Method("GET", "/", h)
which provides a cleaner interface for custom handlers like
in _examples/custom-handler
mux#FileServer
helper function. Instead, we encourage users to create their
own using file handler with the stdlib, see _examples/fileserver
for an exampler.Method()
and r.MethodFunc()
"github.com/go-chi/chi"
chi/render
sub-package to complete the story of building
APIs to offer a pattern for managing well-defined request / response payloads. Please
check out the updated _examples/rest
example for how it works.MethodNotAllowed(h http.HandlerFunc)
to chi.Router interface"net/context"
package has been included in the standard library as "context"
and
utilized by "net/http"
and http.Request
to managing deadlines, cancelation signals and other
request-scoped values. We’re very excited about the new context addition and are proud to
introduce chi v2, a minimal and powerful routing package for building large HTTP services,
with zero external dependencies. Chi focuses on idiomatic design and encourages the use of
stdlib HTTP handlers and middlwares.chi.Handler
interface and requires http.Handler
or http.HandlerFunc
r.Context()
chi.RouteContext(r.Context()) *chi.Context
,
which provides direct access to URL routing parameters, the routing path and the matching
routing patterns.func(ctx context.Context, w http.ResponseWriter, r *http.Request)
to
the standard http.Handler: func(w http.ResponseWriter, r *http.Request)
chi.URLParam(r *http.Request, paramKey string) string
or URLParamFromCtx(ctx context.Context, paramKey string) string
to access a url parameter valuechi.URLParams(ctx)["id"]
used to access url parameters
has changed to: chi.URLParam(ctx, "id")