Similar to how express() returns an express `app` instance which is also
a function, express.Router() returns the Router instance which is also a
function and can be easily used via another router or the app.
app.use(express.Router());
Middleware (.use) can now specify parameter arguments to trigger
Router.param loading. This is handy if you want to `.use` additional
routers but need to load certain objects before the mounted middleware
runs.
closes#1804
this is an unnecessary maintenance burden (see the number of removed
tests), especially when supporting mounting. browsers handle relative
locations, and so should all clients.
a regression could be absolute locations on a mounted app, but 1. we
can fix that later when someone complains and 2) code-smell
This is an overhaul of middleware processing, Router and Route. Connect is no
longer used to process the middleware stack. This functionality has been
split into two parts: middleware stack and default error response.
The entry point for request processing is the `app.handle` method. It
sets up the default error response handle (to run in the event of no
other error handler) and then triggers the app router (instance of
Router) to handle the request.
The app router `handle` function contains the middleware dispatch layer
previously in the connect codebase. This layer handle the logic for
dispatching `.use` calls (stripping paths if needed). The app contains a
base router `app._router`. New routes can be created and `.use`d on this
router to organize routes into files.
Routers now have the following methods `.use`, `.all`, `.param` which
are all public.
Additionally, Routers have a `.route(path)` method which returns a new
instance of Route for the requested path. Route(s) are isolated
middleware stacks and contain methods for the HTTP verbs as well as an
`.all` method to act similar to middleware. These methods are chainable
to easily describe requirements for a route.
var route = Router.route('/foo'); // or 'app.route('/foo')'
route
.all(auth)
.get(function(...) {})
.all(more_checks)
.post(function(...) {})
Any Route and Router methods which accept handlers also accept error
(arity 4) handlers which will also behave as expected.
Finally, the `app.router` getter has been removed. Middleware and
handlers are run IN THE ORDER they are seen in the file. This means that
code which injected the `app.router` and then added error handlers (or
other middleware) will need to be updated to move those handlers after
any requests added on the app object. The examples have been updated
accordingly. This is the largest breaking change to codebases in this
commit.
The router has automatic handling of OPTIONS based on the registered
routes, but if you make an OPTIONS request for an endpoint that does
not exist, then it will still return a 200 with nothing allowed.
Instead, we can let the request move on down the middleware chain. This
has two benefits: first, if the route was not defined and no other
middleware handles it, it will return with a 404. Secondly, if multiple
routers are used and a later one has the route or a custom OPTIONS
defined, the first router will not respond incorrectly.
Similar to app.all() but specifically for attaching handlers to all
methods under a standalone router. This is useful for isolating routers
that require "middleware" like features for all routes managed by the
router.
- Azure absolute paths look like \\ip_address\volume\guid\guid\site\wwwroot\...file.js.
Changed Util.isAbsolute to return true for paths that start with two backslashes.
Roman Shtylman