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 Request #53

Open
umang-singhal opened this issue Dec 11, 2019 · 4 comments
Open

Multipart Request #53

umang-singhal opened this issue Dec 11, 2019 · 4 comments

Comments

@umang-singhal
Copy link

Currently, only content-type:json is supported in @accepts as per code here.

In my use-case, request schema has a file and other form parameters. Since flask keeps that data in request.values and request.form attributes it is currently not configurable.

My suggestion for this is to check the headers and parse the parameters accordingly. Please let me know If there is another way to get around it or this can be the right direction going forward. And If it is, I can pitch in to create a PR for it.

@apryor6
Copy link
Owner

apryor6 commented Dec 13, 2019

The way it is currently implemented, flask_accepts reserves the JSON body for the schema parameter if one has been provided. This is mostly to prevent logical conflict/collision between schemas and associated query parameters. This prevents the (potentially confusing) scenario where a query parameter is provided with the same name as an attribute in the schema.

How are you including a file inside of a Marshmallow schema? Or do you just mean that a file is part of the request, perhaps like in the example here?

@umang-singhal
Copy link
Author

Yes, exactly like in this example(the file is a part of a POST request) and the marshmallow schema consists of a fields.Raw attribute to parse that.
Since binary type object(file) cannot be JSON parsed, this request is sent as multipart and cannot be parsed using request.get_json(). Here we could use request.values and request.files to parse request data.
I have worked out a quick way-around here. Can you suggest if it is the right way or there can be a better way?

@apryor6
Copy link
Owner

apryor6 commented Dec 21, 2019

Yes this looks on track, just verify that request.files can be accessed safely even if it is not provided. I can’t recall the behavior and am on holiday unable to check for a couple of days. Provided that request.files returns an empty dict when not provided, your code looks fine.

@apryor6
Copy link
Owner

apryor6 commented Dec 21, 2019

Also be aware any PR will need associated test cases

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants