Empty multipart form data raises ActionController::BadRequest error since Rails 7.0.5 about rails HOT 6 CLOSED

I was trying to build a minimal repro script, but this is a Rack error not Rails.

This behavior is intended.
That being said, there is a difference between the Rack ticket example and the example in this issue. The example in the Rack ticket doesn't pass the ending boundary, which is definitely invalid.

This ticket example does pass the ending boundary. Here's a curl version triggering the error:

curl 'http://localhost:3000/hello' \
  -H 'Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryy8DrMokPrH5xA9X2' \
  --data-raw $'------WebKitFormBoundaryy8DrMokPrH5xA9X2--\r\n'

I feel like this is a different case. It's not passing any fields, but it is passing a body, with the final boundary. I would expect a parser to parse this without crashing. I was trying to look what the spec says about this, but haven't found a quick answer. I'll look into it this week.

from rails.

Hi @JoeDupuis , thank you for letting me know. I confirmed the latest "2-2-stable" resolved this issue. I appreciate your support!

from rails.

I am not yet 100% sure what the 1* means in BNF notation, but I would assume one or more. If that's the case, an empty request, even with the final boundary, would not be valid.
From https://www.w3.org/Protocols/rfc1341/7_2_Multipart.html

boundary := 0*69<bchars> bcharsnospace 

bchars := bcharsnospace / " " 

bcharsnospace :=    DIGIT / ALPHA / "'" / "(" / ")" / "+"  / 
"_" 
               / "," / "-" / "." / "/" / ":" / "=" / "?" 

Overall, the body of a multipart entity may be specified as follows:
multipart-body := preamble 1*encapsulation 
               close-delimiter epilogue 

encapsulation := delimiter CRLF body-part 

delimiter := CRLF "--" boundary   ; taken from  Content-Type 
field. 
                               ;   when   content-type    is 
multipart 
                             ; There must be no space 
                             ; between "--" and boundary. 

close-delimiter := delimiter "--" ; Again, no  space  before 
"--" 

preamble :=  *text                  ;  to  be  ignored  upon 
receipt. 

epilogue :=  *text                  ;  to  be  ignored  upon 
receipt. 

body-part = <"message" as defined in RFC 822, 
         with all header fields optional, and with the 
         specified delimiter not occurring anywhere in 
         the message body, either on a line by itself 
         or as a substring anywhere.  Note that the 
         semantics of a part differ from the semantics 
         of a message, as described in the text.> 

1*encapsulation suggest one or more encapsulation (where encapsulation is a delimiter + a body part).

If I read that correctly I doubt a PR to change Rack's behavior would be accepted.

I think the fix here is to open an issue or a PR on Axios' repo to stop sending empty multi part as they are not valid in the spec.

from rails.

Thank you for your investigation. I opened an issue on Axios:
axios/axios#6289

from rails.

I was able to confirm that the spec does require at least one part.
.

Turns out, the browser implementations of fetch do send this invalid request. It is not an axios issue.

The spec does warn against being too rigid in parsing. It is not this specific section, but it makes me think that this is worth the discussion.
I believe the RFC is too restrictive (see my comment in the linked issue) and/or that it should be the job of the browsers to prevent sending the invalid request on an empty form data:

await (await fetch('https://httpbin.org/post', {method: 'post', body: new FormData()})).json()

But realistically the fix here would be to relax Rack's parsing or to change your application code to account for this. I'll look into it a bit more this week.

from rails.

Hi @JunichiIto, I am not sure how I missed it the first time I looked, but turns out this issue is already fixed In Rack, but the fix wasn't included in the last release.

I asked the Rack maintainers if they could cut a release with the fix, but you don't have to wait.

If you point your Gemfile to the Rack repo, you can use the new version today.

To do so replace (or add) the Rack gem in your Gemfile with either:

gem "rack", github: 'rack/rack', branch: "2-2-stable" (for version 2)

or gem "rack", github: 'rack/rack', branch: "main" ( for version 3)

Then run bundle update rack
That should fix the error.

from rails.