Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multipart.File has no MIME type information #1001

Open
srittau opened this issue Dec 21, 2022 · 7 comments
Open

multipart.File has no MIME type information #1001

srittau opened this issue Dec 21, 2022 · 7 comments
Labels
help wanted Extra attention is needed

Comments

@srittau
Copy link

srittau commented Dec 21, 2022

Unfortunately, multipart's File class seems to have a serious regression compared to cgi's FieldStorage class: Where FieldStorage.type contained the declared MIME type of the uploaded file (or None if not given), File does not seem to have this information. This makes is basically impossible to download uploaded files while keeping the file type intact.

@rafalp rafalp added the help wanted Extra attention is needed label Dec 21, 2022
@rafalp
Copy link
Contributor

rafalp commented Dec 21, 2022

Pull request resolving this is welcome. But I'm afraid this will require changes upstream to the library we are using for request parsing. :/

@rafalp
Copy link
Contributor

rafalp commented Dec 21, 2022

Can't this be worked around by checking uploaded file's extension and contents? Those are sent by browser in the first place and can be spoofed anyway.

@srittau
Copy link
Author

srittau commented Dec 21, 2022

It's kind of possible to try to determine the MIME type server side, using a library that does that, but it's more reliable to use the uploaded file type when the file is just transparently stored server-side. For example, a user might upload a file from a proprietary program that correctly registers its (custom) MIME type in the OS. When downloading that file, the MIME type will still be correct. The server would most likely not recognize the file type and just use application/octet-stream.

Of course there are certain security implications when trusting the client's MIME type, but those are application-specific.

@rafalp
Copy link
Contributor

rafalp commented Dec 21, 2022

Until somebody contributes a fix to either Ariadne or upstream to python-multipart, this will be a limitation that will have to be worked around I'm afraid.

We just can't maintain custom HTTP parser as part of Ariadne. We are GraphQL library and not HTTP library.

Other workarounds that come to mind here are replacing ariadne.wsgi with one of existing WSGI frameworks like Flask.

@rafalp
Copy link
Contributor

rafalp commented Jan 18, 2023

Multipart's limitations keep coming up on Encode's GitHub, and will be discussed on our next meeting. 🤞

@rafalp
Copy link
Contributor

rafalp commented Feb 16, 2023

I've started musing if moving WSGI app to use the Werkzeug wouldn't solve the problem. That way people using Ariadne's WSGI app would get layer of sanity between raw environ dict and proper Request and Response objects that Flask already uses.

We could have a quick Ariadne release with ariadne.wsgi_future module that has new WSGI app powered by Werkzeug, and after few versions move it under wsgi and drop old one.

@rafalp
Copy link
Contributor

rafalp commented Jul 21, 2023

Issue on python-multipart repo: Kludex/python-multipart#58

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants