Join GitHub today
204 No Content responses may contain both Content-Length and Transfer-Encoding: chunked headers #1595
Let me start by saying this is a complicated problem that I've spent several hours tracking down, and it's certainly possible that the root cause isn't Passenger. I'm starting here because it's how I've worked around the problem for now.
Over the weekend, I pushed some updates to a customer's site that has been stable for many months. As part of this, I installed a handful of security and infrastructure updates. This server runs Debian Wheezy, and one of the updates was from Apache 2.2.22-13+deb7u4 to +deb7u6. Passenger was upgraded from 5.0.8 to 5.0.16.
Today I was notified that clients of an API exposed by the application were no longer functioning correctly. In particular, iOS 8.x clients were unable to parse the response for a request that returns 204 No Content. I eventually found that the server was responding with both
I tried downgrading the Apache packages and it did not resolve the problem.
I found that Passenger 5.0.9 included a change that reverted the downcasing of headers from the application behind Passenger. After downgrading Passenger from 5.0.16 to 5.0.8, the application started working normally again. I re-upgraded the Apache packages and everything is still OK.
The application in question is a Rails 4.0.x app on Ruby 2.1. The changes I made over the weekend are minimal and did not touch any of the API endpoints. None of the configuration files have been touched in a long time (Apache, Passenger, etc.). This application was first deployed with Passenger 4.x, which as I understand from research also did not downcase headers.
So, I'm a little perplexed. The downcasing is (was) new, it didn't happen in 4.x when header case was untouched, it's a problem now that headers are again untouched. I don't see anything related to
I have a staging server available and could do some additional research if it'll help, but I could use some guidance about how to proceed.
Possibly the same as: #1517
Passenger adds Transfer-Encoding if it doesn't see "Content-Length" in the application response, with that exact casing (that's the new part). So doublecheck if the app really isn't sending out something with a different case like "Content-length" or "content-length".
I'm having this exact same problem with a Rails app that uses
I tested the following:
Our API users succeed under 4.0.59, but fail under 5.0.20. Curl gives error 18 "transfer closed with outstanding read data remaining".
(Edited to add Apache version.)