[ruby-core:90171] [Ruby trunk Bug#15356] Rack::Deflater on Rails responds with no data on Ruby 2.6.0

[zundan@gmail.com]

Issue #15356 has been updated by zunda (zunda an).


Thanks! The patch actually fixed the problem.

With `2.6.0-dev` pointing to the binary built as below, the command `curl -H 'Accept-encoding: gzip' -v http://localhost:3000 --raw` prints the HTML data as expected.

~~~
$ cat io.patch 
diff --git a/io.c b/io.c
index d59bde93cf..e87e507540 100644
--- a/io.c
+++ b/io.c
@@ -138,7 +138,7 @@ off_t __syscall(quad_t number, ...);
 #if defined(_WIN32)
 #  define RUBY_PIPE_NONBLOCK_DEFAULT    (0)
 #elif defined(O_NONBLOCK)
-#  define RUBY_PIPE_NONBLOCK_DEFAULT    (O_NONBLOCK)
+#  define RUBY_PIPE_NONBLOCK_DEFAULT    (0)
 #else /* any platforms where O_NONBLOCK does not exist? */
 #  define RUBY_PIPE_NONBLOCK_DEFAULT    (0)
 #endif

$ mv ~/.rbenv/versions/2.6.0-dev ~/.rbenv/versions/2.6.0-dev-vanila
$ rbenv install --patch 2.6.0-dev < io.patch
Cloning https://github.com/ruby/ruby.git...
Installing ruby-trunk...
patching file io.c
$ ruby --version
ruby 2.6.0dev (2018-11-29 trunk 66092) [x86_64-linux]
~~~

> So you're saying this is not a new problem...

First time I noticed this was running a Rails app on `2.6.0-preview1` on Heroku. Since then, I've been trying to see what was going on from time to time but I couldn't figure out how Rails and Rack::Deflater interacts with each other as you wrote. Sorry being slow in reporting it here. I might also have to note that the I do NOT see the problem on `2.5.3`.

> I use Rack::Deflater a bunch with Rack (not-Rails) apps on Ruby trunk.

Right. I couldn't reproduce the problem on non-Rails Rack apps.

----------------------------------------
Bug #15356: Rack::Deflater on Rails responds with no data on Ruby 2.6.0
https://bugs.ruby-lang.org/issues/15356#change-75294

* Author: zunda (zunda an)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.6.0dev (2018-11-28 trunk 66081) [x86_64-linux]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN
----------------------------------------
I'd like to report that a Rails app with `Rack::Deflater` enabled responds with a zero-length body on Ruby 2.6.0, to a request with `Accept-encoding: gzip` request header. It seems to happen at least on `x86_64-linux` (Ubuntu 18.04.1; see below for procedure for a reproduction) as well as on `universal.x86_64-darwin17` (macOS High Sierra 10.13.6; tested about a half year ago). I suspect some kind of change in behavior of pipe or named pipe is causing this.

## 1: Prepare a Rails app, enable Rack::Deflater, and run the server

~~~
$ rbenv install 2.6.0-dev
$ mkdir ruby26-rails-deflater
$ cd ruby26-rails-deflater
$ echo 2.6.0-dev > .ruby-version
$ ruby --version
ruby 2.6.0dev (2018-11-28 trunk 66081) [x86_64-linux]
$ cat <<_END > Gemfile
source 'https://rubygems.org'
gem 'rails', '~> 5.2.1'
_END
$ bundle install --path=vendor/bundle
$ bundle exec rails new test-deflater
$ cd test-deflater
$ sed -ie '/config.load_defaults 5.2/a config.middleware.use Rack::Deflater' \
config/application.rb
$ bundle exec rails s
~~~

## 2: Send a request

From another terminal, run the curl command. The `0` in the last line represents the first chunked response body with zero-length. I expect to see the "Yay! You're on Rails!" response body.

~~~
$ curl -H 'Accept-encoding: gzip' -v http://localhost:3000 --raw
* Rebuilt URL to: http://localhost:3000/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3000 (#0)
> GET / HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.58.0
> Accept: */*
> Accept-encoding: gzip
> 
< HTTP/1.1 200 OK
< X-Frame-Options: SAMEORIGIN
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Download-Options: noopen
< X-Permitted-Cross-Domain-Policies: none
< Referrer-Policy: strict-origin-when-cross-origin
< Content-Type: text/html; charset=utf-8
< Vary: Accept-Encoding
< Content-Encoding: gzip
< ETag: W/"cd54cb5f8d93b7800b9e76460c5fe915"
< Cache-Control: max-age=0, private, must-revalidate
< Content-Security-Policy: script-src 'unsafe-inline'; style-src 'unsafe-inline'
< X-Request-Id: e671eca8-f6ff-4599-b241-ea00fd864f56
< X-Runtime: 0.033015
< Transfer-Encoding: chunked
< 
0

* Connection #0 to host localhost left intact
~~~

Puma logs doesn't show anything out of ordinary:

~~~
Started GET "/" for 127.0.0.1 at 2018-11-28 09:09:44 -1000
Processing by Rails::WelcomeController#index as */*
  Rendering /home/zunda/.rbenv/versions/2.6.0-dev/lib/ruby/gems/2.6.0/gems/railties-5.2.1.1/lib/rails/templates/rails/welcome/index.html.erb
  Rendered /home/zunda/.rbenv/versions/2.6.0-dev/lib/ruby/gems/2.6.0/gems/railties-5.2.1.1/lib/rails/templates/rails/welcome/index.html.erb (5.1ms)
Completed 200 OK in 17ms (Views: 10.8ms | ActiveRecord: 0.0ms)
~~~

Puma responds as expected without compression:

~~~
$ curl -s http://localhost:3000 | tail -8
      <p class="version">
        <strong>Rails version:</strong> 5.2.1.1<br />
        <strong>Ruby version:</strong> 2.6.0 (x86_64-linux)
      </p>
    </section>
  </div>
</body>
</html>
~~~



-- 
https://bugs.ruby-lang.org/