| 1 | Perlbal for the most part only speaks HTTP/1.0 both to clients and to |
|---|
| 2 | backend webservers. It happily takes requests advertising HTTP/1.1 |
|---|
| 3 | and downgrading them to HTTP/1.0 when speaking to backend serves. |
|---|
| 4 | |
|---|
| 5 | It knows all about persistent connections (in both 1.0 and 1.1) and |
|---|
| 6 | will reply with HTTP/1.0 Connection: keep-alive the request was only |
|---|
| 7 | implicitly keep-alive with HTTP/1.1. etc, etc. |
|---|
| 8 | |
|---|
| 9 | Perlbal is now also starting to speak more of 1.1. For instance, |
|---|
| 10 | Perlbal does support receiving transfer-encoding "chunked" requests |
|---|
| 11 | from clients (a feature of HTTP/1.1), will send a "100 Continue" in |
|---|
| 12 | response to "Expect: 100-continue", and will parse the chunked |
|---|
| 13 | requests, writing the request-of-unknown-length to disk (only if |
|---|
| 14 | buffered_uploads is enabled), and then will send an HTTP/1.0 request |
|---|
| 15 | to the backends, with the actual Content-Length (now known) filled in. |
|---|
| 16 | |
|---|
| 17 | When more of 1.1 is supported, it will become an option, and later |
|---|
| 18 | become the default. However, after several years of usage, there just |
|---|
| 19 | hasn't been that much of a reason. The chunked requests (common from |
|---|
| 20 | mobile phones uploading large images) has been the most annoying |
|---|
| 21 | shortcoming but now that it's solved, it's questionable whether or not |
|---|
| 22 | more of HTTP/1.1 will be supported. |
|---|
| 23 | |
|---|
