Re: Undelivered Mail Returned to Sender

Re: Undelivered Mail Returned to Sender

[Joe McIlvain]

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?