We work on an IoT-oriented web service that uses Unicorn. One of our requirements is to support HTTP/1.0 for low-complexity devices.
We've noticed that HTTP/1.0 requests to Unicorn always get HTTP/1.1 responses, which is invalid behaviour for the HTTP/1.0 protocol. Sure enough, looking through the Unicorn source I see that the "HTTP/1.1" protocol is hard-coded in the response writing logic: https://github.com/defunkt/unicorn/blob/a72d2e7fbd13a6bfe64b79ae361c17ea568d4867/lib/unicorn/http_response.rb#L30 When behind our nginx/haproxy frontend, this behaviour is a little more sneaky. For "short" response payloads, the proxy will override the response and always (correctly) use HTTP/1.0. However, for "long" response payloads, the content encoding is "chunked" and the proxy will use "HTTP/1.1" You can actually see this bug in action in the GitHub API (a prominent web service using Unicorn). If you send `curl -v --http1.0 https://api.github.com/gists/public`, you will get an HTTP/1.1 chunked response, which an HTTP/1.0 client cannot handle. I've experimented with using puma instead of unicorn, and it behaves correctly in this respect (it responds to HTTP/1.0 requests with HTTP/1.0 responses). However we'd like to keep using unicorn if possible. Does Unicorn intend to support HTTP/1.0? On Tue, Nov 1, 2016 at 10:18 AM, Joe McIlvain <[email protected]> wrote: > We work on an IoT-oriented web service that uses Unicorn. One of our > requirements is to support HTTP/1.0 for low-complexity devices. > > We've noticed that HTTP/1.0 requests to Unicorn always get HTTP/1.1 > responses, which is invalid behaviour for the HTTP/1.0 protocol. > > Sure enough, looking through the Unicorn source I see that the "HTTP/1.1" > protocol is hard-coded in the response writing logic: > https://github.com/defunkt/unicorn/blob/a72d2e7fbd13a6bfe64b79ae361c17ea568d4867/lib/unicorn/http_response.rb#L30 > > When behind our nginx/haproxy frontend, this behaviour is a little more > sneaky. For "short" response payloads, the proxy will override the response > and always (correctly) use HTTP/1.0. However, for "long" response payloads, > the content encoding is "chunked" and the proxy will use "HTTP/1.1" > > You can actually see this bug in action in the GitHub API (a prominent web > service using Unicorn). If you send `curl -v --http1.0 > https://api.github.com/gists/public`, you will get an HTTP/1.1 chunked > response, which an HTTP/1.0 client cannot handle. > > I've experimented with using puma instead of unicorn, and it behaves > correctly in this respect (it responds to HTTP/1.0 requests with HTTP/1.0 > responses). However we'd like to keep using unicorn if possible. > > Does Unicorn intend to support HTTP/1.0?
