Discrepancy in the parsing behavior of Rack::Multipart between versions 1.6 and 2.2 about rack HOT 8 CLOSED

There is no such version of rack "2.8.2.1".

from rack.

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

from rack.

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

from rack.

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

from rack.

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

from rack.

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?

from rack.

@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

from rack.

Found the solution.

from rack.