shelf 0.6.5+3

  • README.md
  • CHANGELOG.md
  • Installing
  • Versions
  • 92

Web Server Middleware for Dart

Build Status Coverage Status

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.
  • Trivially mix and match synchronous and asynchronous processing.
  • Flexibility to return a simple string or a byte stream with the same model.

Example

See example/example_server.dart

import 'package:shelf/shelf.dart' as shelf;
import 'package:shelf/shelf_io.dart' as io;

void main() {
  var handler = const shelf.Pipeline().addMiddleware(shelf.logRequests())
      .addHandler(_echoRequest);

  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.

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.

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.

Middleware that routes requests between handlers should be sure to update each request's handlerPath and url. This allows inner handlers to know where they are in the application so they can do their own routing correctly. This can be easily accomplished using Request.change():

// In an imaginary routing middleware...
var component = request.url.pathComponents.first;
var handler = _handlers[component];
if (handler == null) return new Response.notFound(null);

// Create a new request just like this one but with whatever URL comes after
// [component] instead.
return handler(request.change(script: component));

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.

When implementing an adapter, some rules must be followed. The adapter must not pass the url or handlerPath 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.

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 include the Date header with the time the handler returns a response. If the handler returns a response with the Date header set, that must take precedence.

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:

/// 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();
  }
}

An adapter that knows its own URL should provide an implementation of the Server interface.

Inspiration

0.6.5+3

  • Improve the documentation of logRequests().

0.6.5+2

  • Support http_parser 3.0.0.

0.6.5+1

  • Fix all strong-mode warnings and errors.

0.6.5

  • Request.hijack() now takes a callback that accepts a single StreamChannel argument rather than separate Stream and StreamSink arguments. The old callback signature is still supported, but should be considered deprecated.

  • The HijackCallback and OnHijackCallback typedefs are deprecated.

0.6.4+3

  • Support http_parser 2.0.0.

0.6.4+2

  • Fix a bug where the Content-Type header didn't interact properly with the encoding parameter for new Request() and new Response() if it wasn't lowercase.

0.6.4+1

  • When the shelf_io adapter detects an error, print the request context as well as the error itself.

0.6.4

  • Add a Server interface representing an adapter that knows its own URL.

  • Add a ServerHandler class that exposes a Server backed by a Handler.

  • Add an IOServer class that implements Server in terms of dart:io's HttpServer.

0.6.3+1

  • Cleaned up handling of certain Map instances and related dependencies.

0.6.3

  • Messages returned by Request.change() and Response.change() are marked read whenever the original message is read, and vice-versa. This means that it's possible to read a message on which change() has been called and to call change() on a message more than once, as long as read() is called on only one of those messages.

0.6.2+1

  • Support http_parser 1.0.0.

0.6.2

  • Added a body named argument to change method on Request and Response.

0.6.1+3

  • Updated minimum SDK to 1.9.0.

  • Allow an empty url parameter to be passed in to new Request(). This fits the stated semantics of the class, and should not have been forbidden.

0.6.1+2

  • logRequests outputs a better message a request has a query string.

0.6.1+1

  • Don't throw a bogus exception for null responses.

0.6.1

  • shelf_io now takes a "shelf.io.buffer_output" Response.context parameter that controls HttpResponse.bufferOutput.

  • Fixed spelling errors in README and code comments.

0.6.0

Breaking change: The semantics of Request.scriptName and Request.url have been overhauled, and the former has been renamed to Request.handlerPath. handlerPath is now the root-relative URL path to the current handler, while url's path is the relative path from the current handler to the requested. The new semantics are easier to describe and to understand.

Practically speaking, the main difference is that the / at the beginning of url's path has been moved to the end of handlerPath. This makes url's path easier to parse using the path package.

Request.change's handling of handlerPath and url has also changed. Instead of taking both parameters separately and requiring that the user manually maintain all the associated guarantees, it now takes a single path parameter. This parameter is the relative path from the current handlerPath to the next one, and sets both handlerPath and url on the new Request accordingly.

0.5.7

  • Updated Request to support the body model from Response.

0.5.6

  • Fixed createMiddleware to only catch errors if errorHandler is provided.

  • Updated handleRequest in shelf_io to more gracefully handle errors when parsing HttpRequest.

0.5.5+1

  • Updated Request.change to include the original onHijack callback if one exists.

0.5.5

  • Added default body text for Response.forbidden and Response.notFound if null is provided.

  • Clarified documentation on a number of Response constructors.

  • Updated README links to point to latest docs on www.dartdocs.org.

0.5.4+3

  • Widen the version constraint on the collection package.

0.5.4+2

  • Updated headers map to use a more efficient case-insensitive backing store.

0.5.4+1

  • Widen the version constraint for stack_trace.

0.5.4

  • The shelf_io adapter now sends the Date HTTP header by default.

  • Fixed logic for setting Server header in shelf_io.

0.5.3

  • Add new named parameters to Request.change: scriptName and url.

0.5.2

  • Add a Cascade helper that runs handlers in sequence until one returns a response that's neither a 404 nor a 405.

  • Add a Request.change method that copies a request with new header values.

  • Add a Request.hijack method that allows handlers to gain access to the underlying HTTP socket.

0.5.1+1

  • Capture all asynchronous errors thrown by handlers if they would otherwise be top-leveled.

  • Add more detail to the README about handlers, middleware, and the rules for implementing an adapter.

0.5.1

  • Add a context map to Request and Response for passing data among handlers and middleware.

0.5.0+1

  • Allow scheduled_test development dependency up to v0.12.0

0.5.0

  • Renamed Stack to Pipeline.

0.4.0

  • Access to headers for Request and Response is now case-insensitive.

  • The constructor for Request has been simplified.

  • Request now exposes url which replaces pathInfo, queryString, and pathSegments.

0.3.0+9

  • Removed old testing infrastructure.

  • Updated documentation address.

0.3.0+8

  • Added a dependency on the http_parser package.

0.3.0+7

  • Removed unused dependency on the mime package.

0.3.0+6

  • Added a dependency on the string_scanner package.

0.3.0+5

  • Updated pubspec details for move to Dart SDK.

0.3.0 2014-03-25

  • Response
    • NEW! int get contentLength
    • NEW! DateTime get expires
    • NEW! DateTime get lastModified
  • Request
    • BREAKING contentLength is now read from headers. The constructor argument has been removed.
    • NEW! supports an optional Stream<List<int>> body constructor argument.
    • NEW! Stream<List<int>> read() and Future<String> readAsString([Encoding encoding])
    • NEW! DateTime get ifModifiedSince
    • NEW! String get mimeType
    • NEW! Encoding get encoding

0.2.0 2014-03-06

  • BREAKING Removed Shelf prefix from all classes.
  • BREAKING Response has drastically different constructors.
  • NEW! Response now accepts a body of either String or Stream<List<int>>.
  • NEW! Response now exposes encoding and mimeType.

0.1.0 2014-03-02

  • First reviewed release

1. Depend on it

Add this to your package's pubspec.yaml file:


dependencies:
  shelf: "^0.6.5+3"

2. Install it

You can install packages from the command line:

with pub:


$ pub get

with Flutter:


$ flutter packages get

Alternatively, your editor might support pub get or packages get. Check the docs for your editor to learn more.

3. Import it

Now in your Dart code, you can use:


import 'package:shelf/shelf.dart';
        
Version Uploaded Documentation Archive
0.7.1 Oct 26, 2017 Go to the documentation of shelf 0.7.1 Download shelf 0.7.1 archive
0.7.0 Aug 29, 2017 Go to the documentation of shelf 0.7.0 Download shelf 0.7.0 archive
0.6.8 Jun 23, 2017 Go to the documentation of shelf 0.6.8 Download shelf 0.6.8 archive
0.6.7+2 Dec 6, 2016 Go to the documentation of shelf 0.6.7+2 Download shelf 0.6.7+2 archive
0.6.7+1 Oct 26, 2016 Go to the documentation of shelf 0.6.7+1 Download shelf 0.6.7+1 archive
0.6.7 Oct 26, 2016 Go to the documentation of shelf 0.6.7 Download shelf 0.6.7 archive
0.6.6 Oct 24, 2016 Go to the documentation of shelf 0.6.6 Download shelf 0.6.6 archive
0.6.5+3 Aug 25, 2016 Go to the documentation of shelf 0.6.5+3 Download shelf 0.6.5+3 archive
0.6.5+2 May 5, 2016 Go to the documentation of shelf 0.6.5+2 Download shelf 0.6.5+2 archive
0.6.5+1 May 4, 2016 Go to the documentation of shelf 0.6.5+1 Download shelf 0.6.5+1 archive

All 52 versions...

Analysis

This feature is new.
We welcome feedback.

We analyzed this package, and provided a score, details, and suggestions below.

  • completed on Dec 7, 2017
  • Dart: 2.0.0-dev.8.0
  • pana: 0.7.3+1

Scores

Popularity:
Describes how popular the package is relative to other packages. [more]
97
Health:
Code health derived from static analysis. [more]
98
Maintenance:
Reflects how tidy and up-to-date the package is. [more]
71
Overall score:
Weighted score of the above. [more]
92

Platforms

Detected platforms: Flutter, server, web

primary library - package:shelf/shelf.dart

Suggestions

  • Use analysis_options.yaml.

    Rename old .analysis_options file to analysis_options.yaml.

Dependencies

Package Constraint Resolved Available
Direct dependencies
async ^1.10.0 1.13.3 2.0.1
http_parser >=1.0.0 <4.0.0 3.1.1
path ^1.0.0 1.5.1
stack_trace ^1.0.0 1.9.1
stream_channel ^1.0.0 1.6.2
Transitive dependencies
charcode 1.1.1
collection 1.14.3
source_span 1.4.0
string_scanner 1.0.2
typed_data 1.1.5
Dev dependencies
http >=0.9.2 <0.12.0
scheduled_test ^0.12.0
test ^0.12.0