Essentially, some servers when receiving a chunked transfer are observed to
behave poorly on the response side when receiving a chunked encoded request
body from the client.
This puts the nail in the coffin, altering the integer passed to isolate will
varyingly cause the response to error out and never reach the second "print"
or cause Keter to respond with a truncated message.
This attempts to consume the request from http-conduit by using $$+- and
printing a string before and after. The "after" never happens under the
following response header conditions:
1. HTTP/1.1
2. Connection: Close
3. *no* Content-Length
4. *no* Transfer-Encoding
This is entirely to support behavior of broken web servers that might be
proxied.
The culprit, in this case, is a Jenkins server on Ubuntu 12.04 (installed using
their repositories and running in the default Servlet container). This server
for whatever reason generates responses that have this rare ill-formed set of
headers:
HTTP/1.1 200 OK
Connection: Close
With *no content-length* and *no transfer-encoding*.
So this is an initial attempt at working around this.
This is necessary for using Keter as a front-end to other web
services that may require hacks like Jenkins does, where the
"Location" header needs to be rewritten to use https on every
response.
Example:
```
root: ..
port: 80
ssl:
# host:
port:
key:
certificate:
reverse-proxy:
- reversed-host: jenkins-internal.corp.example.com
reversed-port: 8080
reversing-host: jenkins.example.com
ssl: False
rewrite-response:
- header: Location
from: ^http://jenkins.example.com
to: https://jenkins.example.com
```
keter bundles configured with a primary hostname of "*" will serve as
the default target for all requests that aren't associated with an
explicit host mapping
this is useful when running keter as a deployment manager for a single
application on multiple machines with distinct hostnames behind a
load-balancing reverse proxy that modifies the http host header:
cluster-wide deployments no longer require the generation of a unique
keter bundle for each machine
managing two separate wildcard applications with the same keter instance
will result in an obvious race
This should solve the text file busy issue. The problem was that while
one green thread was writing a file to disk, another would already be
forking a process for executing a separate app. That new process would
retain a write FD to the file being created, which prevented that file
from eventually being executed.
