Routing in Private Spaces
Last updated 01 September 2017
Table of Contents
The routers in Private Spaces have a slightly different behavior to the routers found in the Common Runtime. This article explains the differences. Please refer to HTTP Routing for an understanding of the shared routing behavior between Common Runtime and Private Spaces.
Heroku error codes
Among the Heroku error codes for the Common Runtime, the Private Spaces routing supports the following errors:
- H10 - App crashed
- H11 - Backlog too deep
- H12 - Request timeout
- H13 - Connection closed without response
- H15 - Idle connection
- H17 - Poorly formatted HTTP response
- H18 - Server Request Interrupted
- H19 - Backend connection timeout
- H21 - Backend connection refused
- H25 - HTTP Restriction: Oversized cookies
- H25 - HTTP Restriction: Oversized header
- H25 - HTTP Restriction: Oversized status line
- H26 - Request Error: Unsupported expect header value
- H26 - Request Error: Bad header
- H27 - Client Request Interrupted
- H28 - Client Connection Idle
- H99 - Platform error
Large cookie & header support
Routing supports individual HTTP header of up to 512 KB.
Response body size logging
The router counts only the size of the response body on the
bytes field in app logs. The Heroku router for Common Runtime counts the status line, headers, and body size.
Dyno connection reuse
For applications that support persistent HTTP connections, the Private Spaces routing may reuse connections to the dyno for multiple requests. These reused connections are independent of the connections between the client software and the Heroku platform.
Response body buffering
The response body from the dyno may be buffered internally by the router to avoid sending many small body fragments to the client. This improves performance for most applications but can have a detrimental effect on applications that require low latency streaming. Small body fragments may be buffered for a maximum of 10ms, but the client may observe larger buffering times due to networking characteristics.
Maintenance mode & custom error pages
Both Maintenance Mode and Custom Error Pages are supported in Private Spaces. Unlike the Common Runtime, at least one web dyno must be started for the Private Spaces routing to serve maintenance and custom error pages.
Content-Length & Content-Type headers
Unlike Common Runtime Routing, which allows multiple
Content-Length headers in the request so long as they contain the same value, Private Spaces routing serves a
400 Bad Response anytime multiple
Content-Length headers are present.
The Private Spaces router will also attempt to set a
Content-Type header on requests when missing from the dyno’s response based on the MIME Sniffing Standard.
Query string logging
Log messages generated by the Private Spaces router contain query string parameters (also known as URL or Get parameters) in the
path field. Some applications pass sensitive data using the query string. For example, OAuth applications typically use a query string parameter for passing temporary tokens between services. For applications that cannot log query string parameters due to compliance or security concerns, this behavior can be disabled by enabling the
spaces-no-log-query labs feature via the Heroku CLI:
$ heroku labs:enable spaces-no-log-query --app desolate-dawn-42
SNI servername & host header matching
Some clients and CDNs set a different value for the SNI servername than the request’s host header when connecting to a Heroku application. Heroku recommends Private Space applications setup a CNAME record for an application’s public DNS entry that points to the internal space name. This is typically a record for your
www.example-app.com custom domain that points to a
desolate-dawn-42.fathomless-ravine-43.herokuspace.com style record. Mismatched servername and host header values are allowed so long as both names are configured as domains for the same application. The
desolate-dawn-42.fathomless-ravine-43.herokuspace.com style domains are configured and managed by Heroku.
Client support for SNI is required by default in Private Spaces. Please contact support if your application supports legacy clients that do not support SNI.
The Private Spaces routers supports TLS versions 1.0, 1.1, & 1.2 with the following ciphers:
spaces-strict-tls feature flag drops support for TLS 1.0 and enables the following ciphers:
spaces-strict-tls feature flag can be enabled via the Heroku CLI:
$ heroku labs:enable spaces-strict-tls --app desolate-dawn-42
HTTP 1.0 requests are converted by the Private Spaces routers into HTTP 1.1 requests to dynos. Likewise, HTTP 1.1 responses from dynos are sent to the client as HTTP 1.0 responses when the client sends HTTP 1.0 requests. The Common Runtime routers convert HTTP 1.0 requests to HTTP 1.1 requests, but do not convert HTTP 1.1 responses back to HTTP 1.0 responses.
Private Spaces routers treats the entire first line of the request (up to the first
\n character) as the status line, regardless of the line ending in a
\r\n) as specified in the HTTP 1.1 RFC. It is typical for HTTP servers like Nginx to allow bare newlines in the end of the status line.
Supported HTTP Methods
The Private Spaces routers supports any HTTP method (sometimes called a “verb”), even those not defined in an RFC.