multipart disposition parameter parser is case-sensitive in violation of RFC6266

[ge0rg]

I was trying to implement a file uploader for a very-legacy system that is using a content-disposition: form-data; name="message"; fileName="sample.txt" header in multipart/form-data uploads.

Flask/werkzeug/sansio is only looking for a filename extra, so it misses the fileName extra.

Therefore, the files are misdetected as fields instead of as files.

However, RFC6266 §4.3 says that

The parameters "filename" and "filename*", to be matched case-insensitively, provide information on how to construct a filename for storing the message payload.

Minimal example:

from flask import Flask, request, make_response

app = Flask(__name__)

@app.route('/',methods = ['POST', 'GET'])
def sendmail():
    if request.method == 'POST':
        print('files', request.files)
        print('form', request.form)
        return make_response("Yay", 201)
    return make_response("Nay", 200)

if __name__ == '__main__':
    app.run(debug = True)

Payload to trigger the issue:

POST / HTTP/1.0
Content-Type: multipart/form-data; boundary=---------------------------7d93b9550d4a
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Content-Length: 350

-----------------------------7d93b9550d4a
content-disposition: form-data; name="message"; fileName="sample.txt"
content-Type: multipart/form-data;

message

-----------------------------7d93b9550d4a
content-disposition: form-data; name="binary"; fileName="none.jpg"
content-Type: image/jpeg;


-----------------------------7d93b9550d4a--

Save the above into request.http and run to test:

nc 127.0.0.1 5000 < request.http

Expected output: request.files has two elements, "message" and "binary"

Actual output: request.form has two elements, "message" and "binary", request.files has none

Environment:

• Python version: 3.9.10
• Werkzeug version: 2.1.2

P.S: the legacy system I'm using fails to submit an epilogue, instead sending a regular boundary (I've fixed that in the above example), causing the parsing to fail with a ValueError which is however silently ignored somewhere upstack, resulting in a "successful" parsing of the form that has neither form fields nor files on it. I'm not sure if this silent ignoring of a form error should be reported as a separate bug.

[pgjones]

Hmm, it might make sense for parse_options_header to lowercase the options name - I don't think it is considered case sensitive anywhere.

[pgjones]

Fixed by #2442