From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 3DAE5211B3 for ; Thu, 29 Nov 2018 10:38:08 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CB57C1214A8; Thu, 29 Nov 2018 19:38:06 +0900 (JST) Received: from dcvr.yhbt.net (dcvr.yhbt.net [64.71.152.64]) by neon.ruby-lang.org (Postfix) with ESMTPS id E90141214A8 for ; Thu, 29 Nov 2018 19:38:02 +0900 (JST) Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id B93D0211B3; Thu, 29 Nov 2018 10:38:01 +0000 (UTC) Date: Thu, 29 Nov 2018 10:38:01 +0000 From: Eric Wong To: ruby-core@ruby-lang.org Message-ID: <20181129103801.cq2bgzemmxkpppvv@dcvr> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: X-ML-Name: ruby-core X-Mail-Count: 90160 Subject: [ruby-core:90160] Re: [Ruby trunk Bug#15356] Rack::Deflater on Rails responds with no data on Ruby 2.6.0 X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" zundan@gmail.com wrote: > Clarify what I think of causing the problem. > 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). So you're saying this is not a new problem... > I suspect some kind of change in > behavior of pipe or named pipe is causing this. ...Because the only recent change for pipe was enabling non-blocking by default on *nix; and that only happened about a week ago on r65922 [Bug #14968] Anyways, you can try using blocking pipes (one-line change below), but I suspect the problem is some bad interaction with Rails and Rack::Deflater (Rack::Deflater does some weird stuff with block captures) ``` 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 ``` Fwiw, I don't know Rails well, but I use Rack::Deflater a bunch with Rack (not-Rails) apps on Ruby trunk.