Open stephenlprice opened 1 year ago
@jeremymayo @joseacortez91 @illonage @dzucker-tab
The following cURL request generated by Postman works:
curl --location --request POST 'https://10ay.online.tableau.com/api/3.16/sites/{{your-site-id}}/datasources?datasourceType=tdsx' \
--header 'Content-Type: multipart/mixed; boundary=--------------------------808837830458042221641451' \
--header 'X-Tableau-Auth: {{valid-api-key}}' \
--header 'Cookie: AWSELB=A1C7138F06714863BC67FB7B4BBB58E53F877896C9BF741843C826233D1F67A88AB8B733971A833BFCC5EF7A67795ABA4A5EC3D87B74C8D6293A5A1263BB5EFE685E5ECE1C4DFAAE9CBCF370BFCEBB3C0290447EB5; hid=10aypd-hap02' \
--form 'request_payload="<tsRequest>
<datasource name=\"SuperStore\"
useRemoteQueryAgent=\"False\"
description=\"SuperStore Sales Data Source\">
<project id=\"4972f17f-a8f8-4a92-a3ec-8f89371cda49\" />
</datasource>
</tsRequest>";type=text/xml' \
--form 'tableau_datasource=@"Sample - Superstore.tdsx"'
W3 defines multipart/mixed
as:
7.2.2 The Multipart/mixed (primary) subtype The primary subtype for multipart, "mixed", is intended for use when the body parts are independent and intended to be displayed serially. Any multipart subtypes that an implementation does not recognize should be treated as being of subtype "mixed".
Microsoft describes it as:
multipart/mixed [RFC1521]: The multipart/mixed content type is used when the body parts are independent and need to be bundled in a particular order. When a UA does not recognize a multipart subtype, it will treat the message as multipart/mixed.
If you look at RFC1521 it indicates that "mixed" is the primary subtype of the multipart content type and a pretty big gap for Postman in that case. On the other hand multipart/form-data
is defined under RFC1867 for "Form-based File Upload in HTML".
Is there an existing request for this feature?
Is your feature request related to a problem?
I have a Postman collection for a Public REST API that is nearly ready to share with our customers. A key workflow on our platform allows users to upload files to their environment via the UI/REST. These "publishing" methods require support for the following header:
multipart/mixed:
Content-Type: multipart/mixed; boundary=<calculated when request is sent>
Adding the header manually in this way does not work:
Content-Type: multipart/mixed; boundary=--------------------------808837830458042221641451
I believe this is caused because Postman will also add
Content-Disposition: form-data;
to the request body as shown in the raw logs for the request. Whereas the manual boundary string is being sent correctly, this mismatchedContent-Disposition
attribute is unexpected since it should beContent-Disposition: mixed;
:Our servers respond to the above request with:
Our endpoint requires that the Request Body look like this:
Describe the solution you'd like
We would like the same level of support for
multipart/mixed
as is currently offered formultipart/form-data
headers. We also have methods that use multipart/form-data and users are able to successfully send requests with Postman.Currently,
multipart/form-data
headers are created by the Postman UI automatically and result in this:Content-Type: multipart/form-data; boundary=<calculated when request is sent>
Which will result in a header that looks like this when sent:
Content-Type: multipart/form-data; boundary=--------------------------808837830458042221641451
It is not necessary to significantly alter the current Postman UI, perhaps provide a dropdown so users can choose between
mixed
andform-data
content types under theform-data
selector. This will effectively create valid boundary strings automatically for the end user.Additionally when selecting
multipart/mixed
, the Content-Disposition must be set to the correct value (Content-Disposition: mixed;
?) rather thanContent-Disposition: form-data;
.Describe alternatives you've considered
Manually writing the header value. This creates valid Content-Type and boundary strings but will still add
form-data
as the Content-Disposition.I have also tried sending requests using a
multipart/form-data
header generated automatically by the UI and I get the following error response from our servers:Users can send successful requests via cURL however, it is possible that lack of first-class support for
multipart/mixed
will make it difficult or impossible to adequately describe the method in a collection and generate valid code without requiring users to understand how to configure a cURL request to make it work.There are other similar GH issues that are either open or have been closed as duplicates: https://github.com/postmanlabs/postman-app-support/issues/8203 https://github.com/postmanlabs/postman-app-support/issues/6933 https://github.com/postmanlabs/postman-app-support/issues/1104 https://github.com/postmanlabs/postman-app-support/issues/814 https://github.com/postmanlabs/postman-app-support/issues/6140
Additional context
In other words, a key workflow/scenario on our platform is currently blocked since our aim is to enable internal and external stakeholders to send requests and generate valid code without needing to have enough expertise to do so from our API documentation alone.
This is stopping us from making a public release of the collection to Salesforce's Public Workspace.