Discrepancy in the parsing behavior of Rack::Multipart between versions 1.6 and 2.2

[sandipransing]

It seems like there's a discrepancy in the parsing behavior of Rack::Multipart between versions 1.6 and 2.8. The key difference lies in how the multipart form data is parsed and structured in the resulting hash.

[198] pry(main)> env = Rack::MockRequest.env_for '/', fixture
=> {"rack.version"=>[1, 3],
"rack.input"=>#StringIO:0x00007fc8e0cdb508,
"rack.errors"=>#StringIO:0x00007fc8d5075f30,
"rack.multithread"=>true,
"rack.multiprocess"=>true,
"rack.run_once"=>false,
"REQUEST_METHOD"=>"GET",
"SERVER_NAME"=>"example.org",
"SERVER_PORT"=>"80",
"QUERY_STRING"=>"",
"PATH_INFO"=>"/",
"rack.url_scheme"=>"http",
"HTTPS"=>"off",
"SCRIPT_NAME"=>"",
"CONTENT_LENGTH"=>"1048802",
"CONTENT_TYPE"=>"multipart/form-data; boundary=---------------------------932620571087722842402766118"}
[199] pry(main)> Rack::Multipart.parse_multipart(env)

VERSION rack 2.2.8.1

=> {"a.pdf"=>
{:filename=>"a.pdf",
:type=>nil,
:name=>"a.pdf",
:tempfile=>#File:/var/folders/dq/gh_0mwnd2mg9zjksn9l5h5580000gp/T/RackMultipart20240422-84772-4g22na.pdf,
:head=>"Content-Disposition: form-data; filename="a.pdf"; size=12545 name="a[p]"\r\nContent-Type:application/pdf\r\n"}}

**VERSION rack 1.6 **
=> {"a"=>
{"p"=>
{:filename=>"a.pdf",
:type=>nil,
:name=>"a[p]",
:tempfile=>#File:/var/folders/dq/gh_0mwnd2mg9zjksn9l5h5580000gp/T/RackMultipart20240422-63994-9ofkkg.pdf,
:head=>"Content-Disposition: form-data; filename="a.pdf"; size=12545 name="a[p]"\r\n" + "Content-Type:application/pdf\r\n"}}}

[ioquatix]

There is no such version of rack "2.8.2.1".

[sandipransing]

Is there a way to make it backwards compatible?

There is no such version of rack "2.8.2.1".

Updated. @ioquatix it is 2.2.8.1

[ioquatix]

I don't think either Rack 1.x or 2.x will be modified. What are you proposing needs to be done?

[sandipransing]

@ioquatix Is there a way to get the earlier behaviour working in Rack version 2.2?

[ioquatix]

I don't think so unless you were willing to copy and monkey patch the code.

[matthewd]

What does the input stream look like? Does it meet the HTTP specification? Is one version of Rack departing from specified behaviour, or are they both just making different guesses about a malformed input?

Have you identified what change in Rack caused the difference?

[sandipransing]

@matthewd It does look like below:

""--Boundary_13116_510748529_1713764139541\r\nContent-Type: application/octet-stream\r\nContent-Disposition: form-data; filename=\""a.pdf\""; modification-date=\""Mon, 22 Apr 2024 05:35:39 GMT\""; size=12545; name=\""a[p]\""\r\n\r\n%PDF-1.7\r\n5 0 obj\r\n<</Type /Page/Parent 3 0 R/Contents 6 0 R/MediaBox [0 0 595.29998779 841.90002441]/Resources<</Font<</FAAAAI 8 0 R>>>>/Group <</Type/Group/S/Transparency/CS/DeviceRGB>>>>\r\nendobj\r\n6 0 obj\r\n<</Length 10 0 R>>stream\r\n1 0 0 -1 0 841.90002441 cm q 1 0 0 1 72 72 cm BT /FAAAAI 12 Tf 1 0 0 -1 0 11.25599957 Tm 0 g [(Test Document 1)] TJ ET Q 1 0 0 -1 0 841.90002441 cm \r\nendstream\r\nendobj\r\n10 0 obj\r\n148 \r\nendobj\r\n1 0 obj\r\n<</Author(\xFE\xFF\x00S\x00w\x00a\x00p\x00n\x00i\x00l\x00 \x00O\x00z\x00