unicorn Ruby/Rack server user+dev discussion/patches/pulls/bugs/help
 help / color / mirror / code / Atom feed
From: Eric Wong <e@yhbt.net>
To: Samuel Williams <samuel@oriontransfer.net>
Cc: unicorn-public@yhbt.net
Subject: Re: Is Rack partial hijack supported?
Date: Mon, 29 Aug 2022 08:14:15 +0000	[thread overview]
Message-ID: <20220829081415.GA7335@dcvr> (raw)
In-Reply-To: <75F28F52-26B6-4BBE-B6A0-AD4F6D8855CD@oriontransfer.net>

Samuel Williams <samuel@oriontransfer.net> wrote:
> Using `-E none` solves the issue and I can proceed with the
> conformance checks, thanks! AFAIK, no other server behaves
> like this (using `Rack::Server` for default middleware)
> although I can understand why for Rack 2 that was a logical
> choice.

OK, good to know.  I think the defaults were copied from rack
0.9 or so...  I'm still trying to keep unicorn supported across
as many Rack versions as possible since it tends to be used by
legacy systems that rarely see updates.

I've always used `-E none' for my projects.

> FYI, we have deprecated `Rack::Chunked` in Rack 3. The wire
> format should be the responsibility of the server, not the
> application/middleware. This middleware in particular was a
> blocker to support HTTP/2 which does chunked encoding using
> binary framing. In addition, `Rack::Server` has also been
> moved out of the Rack gem. The Rack gem should focus on Rack
> the interface, rather than Rack the (server) implementation.
> As such, the `default_middleware_by_environment` should be an
> internal detail of the implementation rather than the
> middleware/application.

Couldn't Rack::Chunked be made a no-op for everything aside from
HTTP/1.1?  That would cause less problems for existing Rack <=2.x
users wanting to upgrade.  It's already a no-op for HTTP/1.0...
(cf. rack/chunked.rb::chunkable_version? )

> My suggestion is that you implement chunked encoding directly
> in your server and only if it makes sense according to the
> response you get back from the application. For a hijacked
> response, given that you are already using `connection:
> close`, you can probably just directly pass the socket to the
> hijack proc. This will be compatible with websockets too.

"Connection: close" alone isn't enough.  body.each {...} can
crash and leave truncated responses clients don't know about
(especially. with non-HTML/XML/JSON content that has no closing
tag).  Either chunked is required (but HTTP/1.1-only), or
relying on gzip for built-in error-checking w/ HTTP/1.0 clients.

Anyways I'll wait a bit for rack 3 to finalize since I'm busy
with other stuff atm.

  reply	other threads:[~2022-08-29  8:14 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-29  5:56 Is Rack partial hijack supported? Samuel Williams
2022-08-29  6:42 ` Eric Wong
2022-08-29  7:19   ` Samuel Williams
2022-08-29  8:14     ` Eric Wong [this message]
2022-09-01 21:53       ` Eric Wong

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://yhbt.net/unicorn/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220829081415.GA7335@dcvr \
    --to=e@yhbt.net \
    --cc=samuel@oriontransfer.net \
    --cc=unicorn-public@yhbt.net \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).