I am trying to consume a REST service using TRestClient but I believe there is an issue with the boundary string for multipart content.
I am capturing the body of the request I am sending, and this is the content type header:
Content-Type: multipart/form-data; boundary=-------Embt-Boundary--07CC944C29DA577E
Then, this is the first section of the multipart form:
-----------Embt-Boundary--07CC944C29DA577E
Content-Disposition: form-data; name="file"; filename="ce.csv"
Content-Type: text/csv
And this is how it ends:
---------Embt-Boundary--07CC944C29DA577E--
I don't think this is an issue on the server, as even my proxy is not able to parse the body:
When I compare this same request vs postman, I notice that the starting and ending boundaries do not match!
Starting: -----------Embt-Boundary--07CC944C29DA577E
Ending: ---------Embt-Boundary--07CC944C29DA577E--
I found that the boundary generation is done in TMultipartFormData.GenerateBoundary() from System.Net.Mime:
When checking the starting and ending boundaries from postman, they match, so I am almost sure this is the issue. I don't think it is related to my code, but let me know if you need it.
Related
I encountered a problem with Mediator (9.7 with Fix 11) package, and I would like to know if you have encountered the same thing or if you have some ideas to correct or get around it ?
The problem is : I have a http REST-like request, which is in fact a multipart/form-data page. When I call it by Mediator (virtualized with Centrasite), the multipart payload is transformed in xml format. The endpoint is not able to respond correctly with that format.
Why mediator do this transformation and how can we prevent it ?
In Mediator input, we have this :
Content-Type: multipart/form-data; boundary=---- WebKitFormBoundaryiBMdnONIEM1rPnWp\r\n
------WebKitFormBoundaryiBMdnONIEM1rPnWp
Content-Disposition: form-data; name="typeEnvoi"
99
------WebKitFormBoundaryiBMdnONIEM1rPnWp
Content-Disposition: form-data; name="prenom"
hhhh
------WebKitFormBoundaryiBMdnONIEM1rPnWp
Content-Disposition: form-data; name="fileVisualExam1"; filename="Mezer_Stamp.png"
Content-Type: image/png
?PNG
The endpoint recieve that :
Content-Type: application/xml; charset=UTF-8
<?xml version='1.0' encoding='UTF-8'?><tns:POST_AppMobile
xmlns:tns="http://namespaces.compagny.com/wsdl">
<typeEnvoi>99</typeEnvoi>
<fileVisualExam1>iVBORw0KGgoAAAANSUhEUgAAAF4AAABZCAYAAAC315PWAAAAAXNSR0IArs
4c6QAAAARnQU1BAACxjwv8YQUAAAAJcEhZcwAADsMAAA7DAcdvqGQAAARZSURBVHja7NAJAQAwEAIg+5
[...] Wp70lgEAafIxtwjUN/HS1B12VkNYiYm0i9wcjG1+yo+S9ZjauIsIDRm5RobKkeQoQ2fYxx9DUmU5S9Kx
T8QwYfynJcRoSFgt6mVKqxBdehf4bx9B7G0A+Y6r6ra9R1VdvI=</fileVisualExam1>
<prenom>hhhh</prenom></tns:POST_AppMobile>
I have made some attemps by modifying the content-types.xml config file for mediator (adding multipart or binary for that mime), but without success.
Please install the latest Mediator 9.7 Fix (currently fix 18). As of Fix 15, the following issue has been resolved:
SMGME-5868 (Fix 15)
Mediator transforms rest request of type multipart/form-data to XML.
When requests with multipart/form-data are sent to Mediator, Mediator converts
the request to application/xml. This issue is resolved
This should resolve your issue.
I have a COBOL batch program where I am able to send mail notification to an ID once my job is complete however, I also want to add an attachment in the mail of the processed file.
The following code attaches another mail as an attachment.
HELO SANTAANA
MAIL FROM:<abc#somting.com>
RCPT TO:<abc#something.com>
DATA
From: LandT P2P - LO <abc#something.com>
To: abc#something.com
Subject: File processed - Price_Change_10-27-15 07-08-44
MIME-VERSION: 1.0
CONTENT-TYPE: MULTIPART/MIXED;name="Price_Change_10-27-15.csv"
CONTENT-DISPOSITION: ATTACHMENT;
FILENAME="Price_Change_10-27-15 07-08-44.csv"
Note: I have also tried using SMTP and still does not work
Here is the sample of the mail i receive on running this code.
If you are generating the text of the email from within your Cobol program, which it sounds like, you would need to append another section, specify the Content-Type and Content-Disposition, filename and encoding, and then follow it with the properly encoded data, similar to this:
Content-Type: application/xml; name="Price_Change_10-27-15 07-08-44"
Content-Disposition: attachment; filename="Price_Change_10-27-15 07-08-44"
Content-Transfer-Encoding: base64
UEsDBBQABgAIAAAAIQDfrfoCnAEAAEcGAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
... and so on ...
I did notice that you had the content of those tags in upper case, that might be a problem. RFC1341 specifies those as "multipart/mixed" and "attachment" and so on. It is possible that your lack of mixed case is messing you up.
CONTENT-TYPE: MULTIPART/MIXED;name="Price_Change_10-27-15.csv"
CONTENT-DISPOSITION: ATTACHMENT;
FILENAME
Even easier than generating your own, have you looked into the excellent XMITIP package by Lyonel B. Dyck, it manages all that for you and you write a few config arms to control it, and you can easily call it from a Cobol program just like any other Rexx. Or you could add it to the end of your job stream as a separate step and make the task really easy.
I'm trying to post a jpeg file to a locally developed web service via Fiddler. This would be simple enough, but I also need to include some data alongside the file and can’t quite nail the syntax that fiddler wants. If I click the upload file button and select a file to upload, it replaces my POST body with:
---------------------------acebdf13572468
Content-Disposition: form-data; name="fieldNameHere"; filename="PantheraLeo.jpg"
Content-Type: image/jpeg
<#INCLUDE *C:\temp\PantheraLeo.jpg*#>
---------------------------acebdf13572468—
Now I want to add some additional data:
user=1&album=2&photo=[OUTPUT FROM FILE UPLOAD]
I’ve tried putting this at the start of the body, but when my Node app receives the request, I’m getting a user parameter, an album parameter but no photo.
Any ideas on how I could format this request to get both parameters and the photo uploaded as the photo parameter?
I've also been looking to do something similar myself and stumbled on your question. I've just managed to achieve what I needed after a bit of messing about with Fiddler. Try this:
---------------------------acebdf13572468
Content-Disposition: form-data; name="model"
MyModelInfo
---------------------------acebdf13572468
Content-Disposition: form-data; model="test123"; filename="123.gif"
Content-Type: image/gif
<#INCLUDE *Z:\Downloads\123.gif*#>
---------------------------acebdf13572468--
It would seem that you link the form data being sent up in your request body to the 'acebdf13572468' boundary in the POST info. Provide the Content-Disposition with a key name (in my case 'model') and then the following line represents your actual value for this key. (In my case "MyModelInfo".
Using the above request body I was able to POST up a file as well as some accompanying POST data to my API.
The accepted answer works well. But be warned the extra line after MyModelInfo comes through into the string. Also when copying and pasting in and out of fiddler some lines were corrupted breaking the file.
Note I have named the file param "file" in the fiddler body and in the receiving API function.
This works for me:
---------------------------acebdf13572468
Content-Disposition: form-data; name="PARAM1"
Some text with a line before but not after
---------------------------acebdf13572468
Content-Disposition: form-data; name="file"; filename="filename.jpg"
Content-Type: image/jpeg
<#INCLUDE *C:\local\filename.jpg*#>
---------------------------acebdf13572468--
The data can be received in .net core 2 like this:
[HttpPost]
[Route("AddImage")]
public async System.Threading.Tasks.Task<IActionResult> AddImageAsync(IFormFile file)
{
//f is the same as file
//var f = Request.Form.Files.Count > 0 ? Request.Form.Files[0] : null;
//useful to check the keys
//var additionalProperties = Request.Form.Keys;
if (file != null)
{
try
{
if (Request.Form.TryGetValue("PARAM1", out StringValues p1))
{
var txt = p1.ToString():
I followed the example from here but I cannot get this to work!
I can't see anything wrong with the update query and I can't think of what to change because it seems fine. I'm only testing with one request because I wanted to make sure it works first.
Here's the request's body:
--batch_hJUuHcmH7ADWhYbtkF0o9JWlq
Content-Type: multipart/mixed; boundary=changeset_oYIVi6ByvAtKBlI7hqFWoOwX7
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)
Content-Type: application/http
Content-Transfer-Encoding: binary
MERGE PrescriptionService.svc/Prescriptions(1L) HTTP/1.1
Host: 192.168.10.179
Content-Type: application/json;odata=verbose
{"PrescriptionType":"RegularMedicationPrescriptionType","Page":"0","Comment":"whoaaaaaa"}
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)--
--batch(hJUuHcmH7ADWhYbtkF0o9JWlq)--
I get a 202 Accepted so the "overall" batch request is not malformed. This is the response from the server:
--batchresponse_d8e813eb-0327-4518-9312-9b7a55d0da0c
Content-Type: multipart/mixed; boundary=changesetresponse_fc085e3b-68a8-46dd-86c6-334b1070607d
--changesetresponse_fc085e3b-68a8-46dd-86c6-334b1070607d--
--batchresponse_d8e813eb-0327-4518-9312-9b7a55d0da0c--
I tried POSTing to that same URL in the batch body to create an entity and it doesn't work either, so it has to be something with the request body.
What's wrong with the request's body?
The changeset boundary as specified in the header:
boundary=changeset_oYIVi6ByvAtKBlI7hqFWoOwX7
must match exactly the one used later on:
--changeset(oYIVi6ByvAtKBlI7hqFWoOwX7)
Which it doesn't. I don't know why you added the parenthesis, but they should not be there.
Same goes for the batch boundary itself.
I'm trying to implement an odata consumer, specifically right now related to doing batch operations and change sets, following the odata documentation essentially loads to this sample multipart batch that I've used as a basis.
However when I actually run this batch code (via fiddler request builder for example) updated with my own entity paths and such, I receive the following error:
Error processing batch request. At the
start of every operation, exactly two
headers need to be specified:
'Content-Type' and
'Content-Transfer-Encoding'. Make sure
these headers are present and have the
correct values.
If I remove the Content-ID from the change set the change set works correctly, but obviously the later operations no longer work because they reference this Content-ID.
I've attempted to move the Content-ID header out of the change request multipart.. part headers, and into the actual part payload request headers, ie:
--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621)
Content-Type: application/http
Content-Transfer-Encoding: binary
Content-ID: 1
POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml;type=entry
Content-Length: ###
<AtomPub representation of a new Customer>
becomes
--changeset(77162fcd-b8da-41ac-a9f8-9357efbbd621)
Content-Type: application/http
Content-Transfer-Encoding: binary
POST /service.svc/Customers HTTP/1.1
Host: host
Content-Type: application/atom+xml;type=entry
Content-Length: ###
Content-ID: 1
Again this no longer complains about the change set having only headers, but still the later reference the content id fails with
HTTP 404, Resource not found for the segment '$1'
The request part which references this content-id looks something like this:
--changeset_7448d3fc-39f6-49bb-b822-30fa4a1676ce
Content-Type: application/http
Content-Transfer-Encoding: binary
POST http://example.org/test.svc/$1/$links/Resources HTTP/1.1
Content-Type: application/json
.. json ..
Assume that http://example.org/test.svc is the service root.
The documentation isn't very clear really about the format of the inner request locations, so the path reference may be incorrect.
Hopefully somebody has better understood this aspect and can advise, thanks in advance.
Stephen.
Turns out you cannot refer to a change set request if the operation in this way if the operation isn't a POST, this makes sense from the aspect that only POST methods really require this reference, but it would be useful to not need this branching logic.
Importantly however the path when referencing the Content-ID should not be absolute, but instead simply:
POST $1/$links/Resources HTTP/1.1
Content-Type: application/json