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
```
