Since Goji accepts the underlying version of this type (i.e., the raw
function), and since it doesn't use web.Handler in the same way as the
net/http ecosystem uses http.Handler, there's really no reason to ever
use web.HandlerFunc.
This is a breaking change. Developers who previously used the
web.HandlerFunc type are encouraged to inline it into their own
projects.
This change exposes a new type, Match, which represents a matched route.
When present in the Goji environment (bound to the key MatchKey),
routing will be skipped and the bound Match will be dispatched to
instead.
In addition, the Goji router has been exposed as a middleware using the
Match mechanism above. This allows middleware inserted after the router
access to the Match object and any bound URLParams.
Fixes#76. See also #32.
This replaces the enormous free-form docstring at the top with something
that's at least syntax highlighted and collapsible. I'm a little worried
about discoverability, but "oh well."
In order to expose a convenient API, it's unfortunately necessary to
lean on Go's interface{} quite a bit: in reality we only accept a
handful of types at each call site, but it's impossible to express this
using the type system.
Prior to this commit (as well as the ParsePattern commit), I exposed all
of this type information in the form of an enormous comment on web.Mux,
however this was pretty gross. Instead, let's use "vanity" type aliases
for interface{} to provide documentation about which types are accepted
where. This will hopefully make the API documentation easier to skim,
but doesn't affect any existing uses of Goji.
This commit also clarifies a couple other parts of the documentation.
This is a major breaking change to web.C, the Goji context object. The
Env key has been changed from a map[string]interface{} to a
map[interface{}]interface{} in order to better support package-private
environment values and to make the context value more compatible with
golang.org/x/net/context's Context.
Since strings support equality, most existing uses of web.C should
continue to function. Users who construct Env by hand (i.e., by calling
"make") will need to update their code as instructed by their compiler.
Users who iterate over the environment will need to update their code to
take into account the fact that keys may no longer be strings.
Go's regular expressions don't allow you to create a capturing group
named "*", which previously made using SubRouter with regular expression
patterns impossible. This change introduces the alternate key "_", which
happens to be a legal capturing group name.
Fixes#98.
In particular, these started failing when running tests under the race
detector in Go 1.4 [0], probably due to some kind of (GC?) hijinks
clearing out the sync.Pool.
[0]: these tests might have also failed in 1.3, but I didn't check
"util" is a really bad name for a package since it isn't very
descriptive and so often collides with other names.
Unfortunately, this is a breaking change, but it's both very easy to fix
and perhaps more importantly also better to do now than later.
Previously, a route like "/:a.png" would match "/foo/bar/baz.png".
This was incorrect, as all matches should be restricted to path segments
(or smaller, as dictated by a break character).
This bug was introduced in 1a390aba1c.
Fixes#75.
This middleware makes it much easier to write sub-routes, allowing you
to make the sub-router ignorant of its parent router's matched prefix.
The example app has also been modified to use this functionality for its
admin pages.
Fixes#65.
This is a breaking API change that changes how wildcard patterns are
treated. In particular, wildcards are no longer allowed to appear at
arbitrary places in the URL, and are only allowed to appear immediately
after a path separator. This change effectively changes the wildcard
sigil from "*" to "/*".
Users who use wildcard routes like "/hello*" will have to switch to
regular expression based routes to preserve the old semantics.
The motivation for this change is that it allows the router to publish a
special "tail" key which represents the unmatched portion of the URL.
This is placed into URLParams under the key "*", and includes a leading
"/" to make it easier to write sub-routers.
This allows you to match "/a/cat.gif" with patterns like "/a/:b.:c".
Thanks to @Minecrell for an early patch implementing this functionality.
Fixes#75.
Fixes#48.
Make the bytecode runner return the route that we're going to use. It's
up to the router itself to dispatch to that route.
Besides feeling a teensy bit cleaner, this refactoring is to prepare for
a "Router" middleware, which will allow application developers to
control when in the middleware stack routing occurs.
Instead of using struct embedding to build web.Mux, start moving towards
explicit mappings. This doesn't actually change the public API of
web.Mux, but feels a little cleaner to me.
The longer-term thing here is to get rid of the functions defined on
Muxes in the public documentation that are defined on "rt *Mux", which
is just plain ugly.
It turns out WriterProxy is pretty generally useful, especially when
defining custom http loggers. Expose it in a util package so that other
packages can use it.
If you're manipulating your middleware stack concurrently with active
requests you're probably doing something wrong, and it's not worth
either the complexity or runtime cost to support you hitting yourself.
We can probably take this principle a bit further and disallow mutating
the middleware stack after any requests have been made (which will
eliminate even more complexity) but that can be a project for another
day.
App Engine disallows package unsafe. As a workaround for the (unsafe)
RCU atomic pointer shenanigans we pull in order to avoid taking a lock
in the hot routing path, let's just grab the lock. Honestly, I doubt
anyone will notice anyways, especially considering the fact that App
Engine is single-threaded anyways.
Fixes#52.
Previously, a state machine invalidation could have raced against an
in-flight routing attempt: if the invalidation occured after the routing
attempt had already completed its nil-check (choosing not to compile a
new state machine) but before the state machine was atomically loaded to
perform routing, the routing goroutine would begin to panic from
dereferencing nil.
The meat of this change is that we now return the state machine that we
compiled (while still holding the lock), and we only ever interact with
the state machine through atomic pointer loads.
Many common panic values, e.g. nil pointer dereferences, don't print
very well under "%#v", emitting something like
"runtime.errorCString{cstr:0x54b2a4}" or similar.
If WriteHeader is called multiple times on a http.ResponseWriter, the
first status is the one that is used, not the last. Fix the wrapped
writer to reflect this fact.
Carl Jackson
SatoShun
Marcus Redivo
R. Peres