| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MTOM |
View previous topic :: View next topic |
| Author |
Message
|
| JT |
 Posted: Fri Feb 06, 2009 11:26 am Post subject: MTOM |
 |
|
Padawan
Joined: 27 Mar 2003
Posts: 1564
Location: Hartford, CT.
|
I'm in a pickle and need some theories.
Yesterday, a vendor I'm working with made a change that resulted in a WMB 6.1.0.2 SOAPInput node to fail to automatically reincorporate an MTOM attachment back into the body of the message. This had been working just fine for several months. I know, I know. “Have the vendor tell you what changed”. But you know as well as I do we have to play the "blame game" for awhile before we start to make progress towards a resolution. Thus my plea. I'm looking for any insight you may have as to how the SOAPInput node recognizes the attachment and re-incorporates it back into the body of the message. What could the vendor have broken to cause WMB not to find (or recognize) the attachment?
The base64 field in the body of the message is now seen as this:
| Code: |
AttachmentData64Binary
Include
xop:CHARACTER:http://www.w3.org/2004/08/xop/include
href:CHARACTER:cid:4726310526.1228950033456.IBM.WEBSERVICES@ww4248 |
when it should look like this (shortened for your benefit):
| Code: |
| AttachmentData64Binary:CHARACTER:SUkqAAgAAAAUAP4ABAABAAAAAAAAAAABBAABAAAAoAYAAAEBBAABAAAAhwgAAAIBAwABAAAAAQAAAAMBAwABAAAABAAAAAYBAwABAAAAAAAAAAcBAwABAAAAAQAAA |
Here’s some insight that was provided to the vendor by another software vendor that discovered the issue in their software:
| Quote: |
I think I found the problem with the latest java client request that you sent in. Basically I created a simple client that uses System.Net objects to construct a request that uses the same headers as the Java request and then simply copied the body of that message and streamed that to the connection. By doing this I was able to emulate your failing java client. I tested the application multiple times and each time that I sent the request, a HTTP 400 would be logged to the IIS event log and no errors would show up in the Windows Event logs.
I then attached a debugger to your sample WCF service that was hosted in IIS. When I did this and then re-ran the client I got the following exception:
System.Xml.XmlException
Unexpected type 'text/xml;' found in root MIME part. Message header specifies 'text/xml; charset=utf-8'.
This error then got wrapped up into a System.ServiceModel.CommunicationException object with the error message text of "Error creating a reader for the MTOM message". Basically this error message tells us that we're unable to properly process the client request. The root cause of this XmlException is because of a mis-match of types in the customers java client request. The customer had the following headers in their request:
HTTP Method: POST
HTTP Raw URL: /Attach/AttachmentService/AttachmentService.svc
Connection: keep-alive
Content-Length: 18742
Content-Type: multipart/related; type="application/xop+xml";start-info="text/xml; charset=utf-8"; start="<1842026614189.1232731018211.IBM.WEBSERVICES@swappu40>"; boundary="----=_Part_55277_1114615213.1232731018211"
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Host: testautomation.jhannuities.com
User-Agent: Java/1.4.2
SOAPMethodName: AttachmentService
SOAPAction: AttachmentService
You'll see in the Content-Type header that we're telling MTOM that we'll have a start-info section with the type of "text/xml;charset=utf-8". So we start to parse the request body by reading in the MTOM data and this is where we choke. Take a look at the MTOM data for their failing request…
------=_Part_55277_1114615213.1232731018211
Content-type: application/xop+xml; charset=utf-8; type="text/xml;"
Content-Transfer-Encoding: binary
Content-Id: <1842026614189.1232731018211.IBM.WEBSERVICES@swappu40>
This is a conflict that is causing your current failure. The Content-type of the root mtom part must match the start-info parameter of the Content-Type header. Please have your java client developers modify their request so that these two highlight strings above match. I made a change to my repro client application so that it modified the Content-type of the root mtom part like so….
HTTP Method: POST
HTTP Raw URL: /Attach/AttachmentService/AttachmentService.svc
Connection: keep-alive
Content-Length: 18742
Content-Type: multipart/related; type="application/xop+xml";start-info="text/xml; charset=utf-8"; start="<1842026614189.1232731018211.IBM.WEBSERVICES@swappu40>"; boundary="----=_Part_55277_1114615213.1232731018211"
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Host: testautomation.jhannuities.com
User-Agent: Java/1.4.2
SOAPMethodName: AttachmentService
SOAPAction: AttachmentService
------=_Part_55277_1114615213.1232731018211
Content-type: application/xop+xml; charset=utf-8; type="text/xml; charset=utf-8"
Content-Transfer-Encoding: binary
Content-Id: <1842026614189.1232731018211.IBM.WEBSERVICES@swappu40>
After I made this change then I got past the HTTP 400 Bad Request problem but got another error message related to the EnterpriseLibrary assembly because it was trying to call Logger.Write but I don't have the EnterpriseLibrary installed and configured. I think that as soon as your java client makes this change then we should have better results. |
|
|
| Back to top |
|
 |
|
|
|
|
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
