One of our API has file upload functionality. Here is the swagger spec parameter for the file field.
{ “name”: “file”, “in”: “formData”, “description”: “Desc”, “required”: false, “type”: “file” }
When I send the request from Smart Docs (try out), the request is sent with Content-Disposition: attachment; filename=“file” instead of Content-Disposition: form-data; name=“file”;
Can you suggest a way to fix attachment content-disposition format?
Can you show more of your OpenAPI Spec? Specifically, What is the “consumes” value? It should be “multipart/form-data”. Is it?
yes.
“consumes”: [ “multipart/form-data” ],
When I looked at the trace, I noticed following API call is made from smart docs and the request payload look correct.
Request Payload:
------WebKitFormBoundaryAOqAIP2jBiFYKuuP Content-Disposition: form-data; name=“root-fields”
policyId=&policy=&metadata=&metadataFile=&documentName=&includeMatches=&maxContentMatchesPerRule=&skipTextExtraction=&skipWhitespaceCollapse= ------WebKitFormBoundaryAOqAIP2jBiFYKuuP Content-Disposition: form-data; name=“file”; filename=“ab.pdf” Content-Type: application/pdf
It doesn’t appear to be an issue with smart docs. But this API call is changing the content disposition type from form data to attachment. Not sure where this is happening.
I have fixed this issue onCloud, Can you verify & let us know.
Also, Are you sending any additional data along with file attachment using multipart/form-data ?
Thanks Anil.
I am sending other form parameters as application/x-www-form-urlencoded along with multi-part form data.
It’s still not working.
I get this error for any document.
<code>{
"statusCode": 400,
"message": "No document or metadata to classify.",
"error": "CLIENT_ERROR"
}
Hi Anil, We are seeing different behavior than expected when doing multipart/form-data through smart docs. If there are other form parameters, instead of sending each form parameter as a “multi-part”, it is bundling them as x-www-url-encoded into the “first part”, and then doing the file as the “second part”. Is this expected? The parsing logic on the backend would need to be different to support smartdocs (vs postman or another http client) I think it’s the Javascript in Smartdocs that is assembling the formdata like this.
Seeing the same thing - BaskarVangili, were you able to get it to work?
Any update on this please?
@BaskarVangili , Are you available to quickly test this fix before we push this to production ?
@David Mehi , Yes, You are right. Not sure the reasons behind it. I am sure it’s not a great way to do same. Also, We are modifying the request in smartdocs proxy for some reasons including browser compatability. Earlier, File upload was not working in smartdocs with petstore example. I have a fix on test environment. Need to validate with use case.
yes Anil, I am available now. Can you deploy to DEV portal?
@BaskarVangili , Can you please verify now & let us know how it goes.
I am getting different error now. we are sending few other form values along with the file. Earlier those form values were sent as application/x-www-form-urlencoded and file was sent as multipart form data. Now all the form fields are sent as multipart form data. for some reason this is breaking the target service. Any idea why was this changed?
Thanks - do you think this is something that will “fixed” or updated in SmartDocs in a future version?
For now, we are forcing the client to base64 encode the file first and then passing it in as part of the JSON payload on a POST.
@BaskarVangili , where do you mention this ‘application/x-www-form-urlencoded’ in the spec only for form fields ? I don’t think it’s right way to do. Ideally, It should be ‘formdata’ right when you are sending the API which is multipart formdata combination of form fields & file ? For example, See request going in for the similar API documented using famous petstore Open API Spec here.
@David Mehi , Fix is available on production. Smartdocs now works for multi part form data combination of form fields, files. We have verified with petstore uploadImage & works as expected.
Great! Is there a patch or anything to update in smartdocs if we already have it up and running?
I didn’t mention ‘application/x-www-form-urlencoded’ in the spec. but thats how other fields were sent earlier and that worked fine. The only issue with previous implementation was ‘Content-Disposition’ was sent as ‘attachment’ instead of ‘form-data’. But the recent change breaks the backend service and we don’t have access to change the service. We have to somehow fix this from smart docs side.
@BaskarVangili , It’s not smartdocs proxy issue. If your target server is expecting ‘application/x-www-form-urlencoded’ , You need to mention same in Spec right ? By deafault, Multi Part form data disposition header for form fields is “formdata” & that’s what we are doing. What if i change it to ‘‘application/x-www-form-urlencoded’’ just for your target & other targets expect it to be standard ‘formdata’ according to RFC spec (RFC2183) ? For example, SmartDocs famous petstore example expects it to be standard ‘formdata’. So, I am afraid we can’t change it just for your backend.
If your backend can’t change to the standard format, I would suggest having your own smartdocs proxy to talk to your target server. Again, ‘application/x-www-form-urlencoded’ in Content-Disposition is not an accepted format according to RFC spec (RFC2183).