* Re: Undelivered Mail Returned to Sender
[not found] ` <CAPGBM9YkEnTMic9GF5hLmo9251aW-NgJUVp7JB2ayMTeUa7BVw@mail.gmail.com>
@ 2016-11-01 17:29 ` Joe McIlvain
0 siblings, 0 replies; only message in thread
From: Joe McIlvain @ 2016-11-01 17:29 UTC (permalink / raw)
To: unicorn-public
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 <joe.eli.mac@gmail.com> 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?
^ permalink raw reply [flat|nested] only message in thread