| Author |
Message
|
| mapa |
 Posted: Thu Mar 26, 2015 4:15 am Post subject: File upload using multipart/form-data and HTTPRequestNode |
 |
|
Master
Joined: 09 Aug 2001
Posts: 257
Location: Malmö, Sweden
|
I'm going crazy trying to implement a simple file upload using the HTTPRequestNode.
I want to send it as "Content-Type: multipart/form-data" rfc2388
This means "on the wire":
| Code: |
POST /secret HTTP/1.0
Content-Length: 599
Content-Type: multipart/form-data; boundary="----=_Part_16_1630301352.1427210994371"
Host: 127.0.0.1:9999
MIME-Version: 1.0
------=_Part_16_1630301352.1427210994371
Content-Type: application/octet-stream; name=test.csv
Content-Transfer-Encoding: binary
Content-Disposition: form-data; name="test.csv"; filename="test.csv"
<data>
------=_Part_16_1630301352.1427210994371--
|
The IBM supplied message model - MIME - gets serialized as XML when using the HTTPRequestNode (it is not a perfect match anyway since content-disposition is missing).
The posts I have found here seem to have given up and implemented it using Java which is dead simple. (But then I wouldn't use an IIB if having to do this in Java I would run Spring Boot and Apache Camel instead.)
Seems strange that the broker doesn't implement out-of-the-box functionality for this for something this simple and common. Any decent browser has support for this since more than a decade ago...
I'm on IIB FP3 Express Edition, (meaning no ESQL is available, put pretty much everything else).
Am I missing something or will I have to make my own DFDL model to support multipart/form-data?
(Back here again after doing other things for quite a while) |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Mar 26, 2015 4:54 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The MIME parser shouldn't be serializing anything as XML.
Can you show a trace node output of the tree before you call the HTTPRequest node? |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 26, 2015 4:59 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
This is probably one of the edge cases and I would check with Hursley if the HTTPRequest node supports this standard... I certainly would not expect the node to be able to send a 2 GB file that way... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mapa |
| Posted: Thu Mar 26, 2015 5:25 am Post subject: |
|
|
Master
Joined: 09 Aug 2001
Posts: 257
Location: Malmö, Sweden
|
I have made a quick-and-dirty work-around by modelling a DFDL message model that works I guess.
The size of the file is not that large, it is a CSV file that is at most 150kb.
The msgflow is:
MQInput -- Mapping Node -- HTTP Add header -- Remove MQ header -- HTTPRequestNode
(Omitting error handling as of now)
I will get back with a trace, need to revert the code from version control.
It is not the MIME parser, the Message Model (not message set) produces XMLNSC, it is the only alternative working after a Map node.
If I try to use RCD to MIME it gives an exception.
On the wire it looks pretty much like this (only had a test without setting all elements)
| Code: |
<MIME_Msg><MIME-Version>1.0</MIME-Version><Data><BLOB>74657374</BLOB></Data></MIME_Msg>
|
Maybe I should try to use the MRM Mime instead to see if that helps? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Thu Mar 26, 2015 5:34 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
So you are creating a document in the XMLNSC domain, not the MIME domain.
I don't know if you can use the mapping node to build a tree in the MIME domain - So that does leave you with using Java or PHP or .NET instead of the mapping node.
Unless I'm wrong, and you can use the mapping node to build a tree in the MIME domain. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Mar 26, 2015 5:36 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Why not just map to BLOB, then use a complete new message and set the MIME parser on it, and map in the program?
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| mapa |
| Posted: Mon Mar 30, 2015 12:11 am Post subject: |
|
|
Master
Joined: 09 Aug 2001
Posts: 257
Location: Malmö, Sweden
|
Thanks for your input.
As the pressure to deliver was high I ended up doing a work-around that maybe is the proper solution if done properly.
I created a DFDL Message Model for the multipart in my case.
| Code: |
<xsd:element name="Multipart" type="MultipartType"/>
<xsd:complexType name="MultipartType">
<xsd:sequence dfdl:separator="" dfdl:sequenceKind="ordered">
<xsd:element name="Header" type="HeaderType"/>
<xsd:element name="Payload" type="CSVPayloadType"/>
<xsd:element name="Footer" type="FooterType"/>
</xsd:sequence>
</xsd:complexType>
|
The header fixes this
| Code: |
------=_Part_16_1630301352.1427210994371
Content-Type: application/octet-stream; name=file.csv
Content-Transfer-Encoding: binary
Content-Disposition: form-data; name="file.csv"; filename="file.csv"
|
The footer this:
| Code: |
------=_Part_16_1630301352.1427210994371
|
|
|
| Back to top |
|
|
|
|
