Make sure handler errors won't bring down a shelf server.

pkg/shelf/README.md

 ## Web Server Middleware for Dart
 
 ## Introduction
 
 **Shelf** makes it easy to create and compose **web servers** and **parts of web
 servers**. How?
 
 * Expose a small set of simple types.
 * Map server logic into a simple function: a single argument for the request,
 the response is the return value.
@@ skipping 15 matching lines @@
   io.serve(handler, 'localhost', 8080).then((server) {
     print('Serving at http://${server.address.host}:${server.port}');
   });
 }
 
 shelf.Response _echoRequest(shelf.Request request) {
   return new shelf.Response.ok('Request for "${request.url}"');
 }
 ```
 
+## Handlers and Middleware
+
+A [handler][] is any function that handles a [shelf.Request][] and returns a
+[shelf.Response][]. It can either handle the request itself--for example, a
+static file server that looks up the requested URI on the filesystem--or it can
+do some processing and forward it to another handler--for example, a logger that
+prints information about requests and responses to the command line.
+
+[handler]: https://api.dartlang.org/apidocs/channels/be/dartdoc-viewer/shelf/shelf.Handler
+
+[shelf.Request]: https://api.dartlang.org/apidocs/channels/be/dartdoc-viewer/shelf/shelf.Request
+
+[shelf.Response]:  https://api.dartlang.org/apidocs/channels/be/dartdoc-viewer/shelf/shelf.Response
+
+The latter kind of handler is called "[middleware][]", since it sits in the
+middle of the server stack. Middleware can be thought of as a function that
+takes a handler and wraps it in another handler to provide additional
+functionality. A Shelf application is usually composed of many layers of
+middleware with one or more handlers at the very center; the [shelf.Pipeline][]
+class makes this sort of application easy to construct.
+
+[middleware]: https://api.dartlang.org/apidocs/channels/be/dartdoc-viewer/shelf/shelf.Middleware
+
+[shelf.Pipeline]:  https://api.dartlang.org/apidocs/channels/be/dartdoc-viewer/shelf/shelf.Pipeline
+
+Some middleware can also take multiple handlers and call one or more of them for
+each request. For example, a routing middleware might choose which handler to
+call based on the request's URI or HTTP method, while a cascading middleware
+might call each one in sequence until one returns a successful response.
+
+## Adapters
+
+An adapter is any code that creates [shelf.Request][] objects, passes them to a
+handler, and deals with the resulting [shelf.Response][]. For the most part,
+adapters forward requests from and responses to an underlying HTTP server;
+[shelf_io.serve][] is this sort of adapter. An adapter might also synthesize
+HTTP requests within the browser using `window.location` and `window.history`,
+or it might pipe requests directly from an HTTP client to a Shelf handler.
+
+[shelf_io.serve]: https://api.dartlang.org/apidocs/channels/be/dartdoc-viewer/shelf/shelf-io#id_serve
+
+When implementing an adapter, some rules must be followed. The adapter must not
+pass the `url` or `scriptName` parameters to [new shelf.Request][]; it should
+only pass `requestedUri`. If it passes the `context` parameter, all keys must
+begin with the adapter's package name followed by a period. If multiple headers
+with the same name are received, the adapter must collapse them into a single
+header separated by commas as per [RFC 2616 section 4.2][].
+
+[new shelf.Request]: https://api.dartlang.org/apidocs/channels/be/dartdoc-viewer/shelf/shelf.Request#id_Request-
+
+[RFC 2616 section 4.2]: http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html
+
+An adapter must handle all errors from the handler, including the handler
+returning a `null` response. It should print each error to the console if
+possible, then act as though the handler returned a 500 response. The adapter
+may include body data for the 500 response, but this body data must not include
+information about the error that occurred. This ensures that unexpected errors
+don't result in exposing internal information in production by default; if the
+user wants to return detailed error descriptions, they should explicitly include
+middleware to do so.
+
+An adapter should include information about itself in the Server header of the
+response by default. If the handler returns a response with the Server header
+set, that must take precedence over the adapter's default header.
+
+An adapter should ensure that asynchronous errors thrown by the handler don't
+cause the application to crash, even if they aren't reported by the future
+chain. Specifically, these errors shouldn't be passed to the root zone's error
+handler; however, if the adapter is run within another error zone, it should
+allow these errors to be passed to that zone. The following function can be used
+to capture only errors that would otherwise be top-leveled:
+
+```dart
+/// Run [callback] and capture any errors that would otherwise be top-leveled.
+///
+/// If [this] is called in a non-root error zone, it will just run [callback]
+/// and return the result. Otherwise, it will capture any errors using
+/// [runZoned] and pass them to [onError].
+catchTopLevelErrors(callback(), void onError(error, StackTrace stackTrace)) {
+  if (Zone.current.inSameErrorZone(Zone.ROOT)) {
+    return runZoned(callback, onError: onError);
+  } else {
+    return callback();
+  }
+}
+```
+
 ## Inspiration
 
 * [Connect](http://www.senchalabs.org/connect/) for NodeJS.
     * Read [this great write-up](http://howtonode.org/connect-it) to understand
       the overall philosophy of all of these models.
 * [Rack](http://rack.github.io/) for Ruby.
 * [WSGI](http://legacy.python.org/dev/peps/pep-3333/) for Python.