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

POST file via multipart/form-data not parsed correctly #3162

andrewabest opened this issue Jul 19, 2018 · 5 comments

POST file via multipart/form-data not parsed correctly #3162

andrewabest opened this issue Jul 19, 2018 · 5 comments


Copy link

When POST-ing a file (in this case a .docx or .pdf) to an Azure Function, the request is not correctly parsed, and the Body of the request within the function contains part of the Header of the request

Investigative information

Please provide the following:

  • Timestamp: N/A
  • Function App version (1.0 or 2.0-beta): 2.0-beta
  • Function App name: occurs locally
  • Function name(s) (as appropriate): N/A
  • Invocation ID: N/A
  • Region: N/A

Repro steps

Provide the steps required to reproduce the problem:

Expected behavior

The string should only contain the posted file payload

Actual behavior

The string contains some HTTP headers, along with the posted file payload, like so

----------------------------240199329954201831832994\r\nContent-Disposition: form-data; name=\"document\"; filename=\"test.docx\"\r\nContent-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document\r\n\r\nPK\u0003\u0004\u0014\0\u0006\0\b\0\0\0!\0�\u0018���\u0001\0\0�\a\0\0\u0013\0\b\u0002[Content_Types].xml �\u0004\u0002(�\0\u0002\0\0\...

Known workarounds

Use ASP.NET core WebAPI instead.

Related information

I've written a blog post on this here with a few more details and screenshots.

@fabiocav fabiocav added this to the Active Questions milestone Jan 9, 2019
Copy link

WueF commented Feb 7, 2019

@andrewabest Those are not HTTP Headers, but multipart/form-data boundaries.
Reason of seeing that is (according to screenshot in your blog post), you didn't POST a raw stream (direct file) but form-data from Postman.
To properly handle that you need different approach.
You can check, whether request is of type form by simple check if (req.HasFormContentType).

You can achieve same results as IFormFile in ASP.NET Core Webapi by digging into request and using ie.
foreach (var formFile in req.Form.Files)

Then inside formFile variable (exactly the same IFormFile like in ASP.NET Core) you have stream of only file you are interested in.

Copy link

@WueF ah interesting, so webapi will model bind to IFormFile from form-data, but functions won't? Will functions only accept application/octet-stream? I'll have to give it a test and update my post :)

Copy link

WueF commented Feb 11, 2019

@andrewabest Yes, ASP has "automated tools" in it's pipeline which process incoming HTTP Requests and bind it's data to controller method's parameters (based on names, conventions and attributes like [FromQuery], [FromBody], [FromPath]. Hence you can use directly IFormFile or IEnumerable<IFormFile> in controller action parameter.

In function you have clear HttpRequest as trigger parameter, but as I said previously, you can still use many of ASP features, so you can see multipart form in req.Form property, files will be under req.Form.Files. Functions still use ASP APIs beneath, just you don't have standalone main loop where .UseMvc() adds many features to pipeline.

Copy link

Hey @andrewabest,
By using "application/octet-stream" content type, does it solve your issue?
If so, please let us know if we can close the issue. Many thanks.

@ghost ghost added the no-recent-activity label Jul 20, 2019
Copy link

ghost commented Jul 20, 2019

This issue has been automatically marked as stale because it has been marked as requiring author feedback but has not had any activity for 4 days. It will be closed if no further activity occurs within 3 days of this comment.

@ghost ghost closed this as completed Jul 23, 2019
@Azure Azure locked as resolved and limited conversation to collaborators Jan 1, 2020
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

4 participants