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

pkg/shelf/README.md

Index: pkg/shelf/README.md
diff --git a/pkg/shelf/README.md b/pkg/shelf/README.md
index 7f527d0ae31c362da7487d42f0c2889afa00890a..7366ba88240fddd7ad207a2c030f5593b9695790 100644
--- a/pkg/shelf/README.md
+++ b/pkg/shelf/README.md
@@ -33,6 +33,93 @@ shelf.Response _echoRequest(shelf.Request request) {
 }
 ```
 
+## 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.