Heroku

How It Works

HTTP Routing

Last Updated: 15 February 2012

routing

Table of Contents

The Heroku platform automatically routes HTTP requests sent to your app’s hostname(s) through to all of your web dynos.

Applications on the Cedar stack use the herokuapp.com HTTP stack.

The herokuapp.com HTTP Stack

Cedar apps use the herokuapp.com stack. Any request sent to *.herokuapp.com is using the herokuapp.com stack.

The herokuapp.com HTTP stack offers a much more direct routing path to your web dynos. This allows for advanced HTTP uses such as chunked responses, long polling, and using an async webserver to handle multiple responses from a single web process.

Requests come in to a load balancer that offers HTTP and SSL terminiation. From there they are directly passed to the routing mesh. This shorter path allows for full support of HTTP 1.1, but without offering any implicit caching capabilities.

Timeouts

Requests on the herokuapp.com have an initial 30 second window in which the app process must return at least some response data. After the initial response, each byte sent (either from the client or from your app process) resets a rolling 55 second window. If no data is sent during this 55 second window then the connection is terminated.

Multiple Simultaneous Connections

The herokuapp.com routing stack can be used for async or multi-threaded apps that wish to handle more than one connection simultaneously. Ruby webservers such as Goliath, Thin (with a suitable web framework such as Async Sinatra), or your own custom EventMachine web process are some examples. Node.js web apps (such as those built with Express) can almost always handle multiple connections in a single process, as can most Python, Java, Scala, and Clojure apps.

The routing mesh will pass new HTTP connections to your web dynos just as soon as they are received. If you have more than one web dyno, the routing mesh will load balance across them using a standard random selection algorithm.

Websockets

WebSockets are not yet supported.

No reverse proxy cache

The new HTTP stack does not include Varnish (a reverse proxy cache) because it is not compatible with the advanced HTTP features described above. If you wish to use HTTP caching headers, rack-cache and the memcache add-on offer features and performance comparable to Varnish, but with the additional benefit of giving you complete control over authentication and page expiration.

Read more in Jim Gay’s Rack Cache on Heroku with Memcached.

Gzipped Responses

Since requests to Cedar apps are made directly to the application server – not proxied through an HTTP server like nginx – any compression of responses must be done within your application. For Rack apps, this can be accomplished with the Rack::Deflater middleware. For gzipped static assets, make sure that Rack::Deflater is loaded before ActionDispatch::Static in your middleware stack.