phusion
env['wsgi.input'].read() never completes
Issue report
Fill in as much as possible so that we can understand, find and fix the problem.
Are you sure this is a bug in Passenger? Very likely.
Please try with the newest version of Passenger to avoid issues that have already been fixed Ok.
Question 1: What is the problem?
-
What is the expected behavior? After the request-body is sent, the read-operation should finish.
-
What is the actual behavior? The request hangs ad infinitum. As far as I see it, the read-side of the unix-socket representing the request is never closed when the body is actually finished.
-
How can we reproduce it? Please try to provide a sample application (or Virtual Machine) demonstrating the issue. Otherwise, if we can't reproduce it, we might have to ask you a number of followup questions or run certain commands to try and figure out the problem.
Minimal WSGI-Application. No framework used.
def application(env, start_response): env['wsgi.input'].read() start_response("200 OK", []) return []Test with
wget http://localhost/(assuming the application is mounted on that path :smiley: )
Question 2: Passenger version and integration mode:
- For example: open source 5.0.26 standalone; enterprise 5.0.21/nginx
Your answer:
ubuntu@passenger-wsgi-hang:~/source$ passenger --version
Phusion Passenger 6.0.2
Tested with Passenger Standalone (nginx engine) and Passenger in nginx. Apache not tested.
Question 3: OS or Linux distro, platform (including version):
- For example: Debian 8, x86_64 or OS X 10.10 Yosemite, x86_64
Your answer:
From screenfetch:
OS: Ubuntu 18.04 bionic (inside lxc container)
Kernel: x86_64 Linux 5.0.0-17-generic
Uptime: 11m
Packages: 541
Shell: bash 4.4.19
CPU: AMD Ryzen 5 2600X Six-Core @ 12x 3.6GHz (42.8°C)
GPU: AMD/ATI Ellesmere [Radeon RX 580X]
RAM 125MiB / 16034MiB
Question 4: Passenger installation method:
Your answer: [ ] RubyGems + Gemfile [ ] RubyGems, no Gemfile [X] Phusion APT repo [ ] Phusion YUM repo [ ] OS X Homebrew [ ] source tarball [ ] Other, please specify:
Question 5: Your app's programming language (including any version managers) and framework (including versions):
- For example: Ruby 2.3.0, RVM, Rails 5.0.0; Node.js 4.0.0 with Express 4.13.4
Your answer: Tested with Python 3.6 and Python 3.7
Question 6: Are you using a PaaS and/or containerization? If so which one?
- For example: Heroku, Amazon Container Services, Docker 1.9 with an image based on passenger-docker
Your answer:
As written above LXC
Question 7: Anything else about your setup that we should know?
Your answer: This is a fresh LXC container.
We strive for quality and appreciate you taking the time to submit a report! Please note that if you want guaranteed response times and priority issue support we encourage you to join our enterprise customer base. They also provide us with the means to continue our high level of open source support!
After looking at wsgi-loader.py I noticed it does not implement RFC2616 Sect. 4.3 correctly.
The presence of a message-body in a request is signaled by the inclusion of a Content-Length or Transfer-Encoding header field in the request's message-headers.
This is implemented for ruby in ThreadHandler#prepare_request.
This implementation is lacking for wsgi-loader.py
