You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Uploading multipart forms without setting the Content-Length header fails for Passenger on Rack 2.x releases. This is because Rack itself does not conform to it's Input Stream SPEC and calls an #eof? on an input stream in the case of no Content-Length header:
At this point, the io is of type PhusionPassenger::Utils::TeeInput, which does not implement the #eof?method. This is pretty legit, as the Rack SPEC does not require it. However, in the case of no content length, no BoundedIO wrapping is happening, which leaves a raw call to the #eof? method of PhusionPassenger::Utils::TeeInput, which leads to:
NoMethodError: undefined method `eof?' for #<PhusionPassenger::Utils::TeeInput:0x0000563c49844cf8>
This is where it gets interesting. This problem was found out and fixed in 2017 by rack/rack#1201. The commit sat in master and wasn't ported to rack's 2-0-stable branch, where the 2.* are built from. Yesterday the rack maintainers backported the change into the 2-0-stable branch, but no release have been made yet.
While you are completely complying to the spec, it may be a good idea to put the #eof? method on the TeeInput class for the folks who cannot run on 2-0-stable or are locked to a specific rack version, but can fix the issue by updating Passenger.
The text was updated successfully, but these errors were encountered:
Uploading multipart forms without setting the
Content-Length
header fails for Passenger on Rack 2.x releases. This is because Rack itself does not conform to it's Input Stream SPEC and calls an#eof?
on an input stream in the case of noContent-Length
header:https://github.com/rack/rack/blob/8376dd11e6526a53432ee59b7a5d092bda9fc901/lib/rack/multipart/parser.rb#L59-L77
At this point, the
io
is of typePhusionPassenger::Utils::TeeInput
, which does not implement the#eof?
method. This is pretty legit, as the Rack SPEC does not require it. However, in the case of no content length, noBoundedIO
wrapping is happening, which leaves a raw call to the#eof?
method ofPhusionPassenger::Utils::TeeInput
, which leads to:This is where it gets interesting. This problem was found out and fixed in 2017 by rack/rack#1201. The commit sat in master and wasn't ported to rack's
2-0-stable
branch, where the2.*
are built from. Yesterday the rack maintainers backported the change into the2-0-stable
branch, but no release have been made yet.While you are completely complying to the spec, it may be a good idea to put the
#eof?
method on theTeeInput
class for the folks who cannot run on2-0-stable
or are locked to a specific rack version, but can fix the issue by updating Passenger.The text was updated successfully, but these errors were encountered: