Forum Discussion

sirclaudio's avatar
sirclaudio
New Contributor
14 years ago

MTOM and soap 1.2 .net service -> Bad Request

I'm trying to invoke a .net web service with soap 1.2, WS-A and MTOM using SoapUI 3.5.1 and 3.6 open source, but the answer is always 400 - Bad Request.

Looking at the exception thrown, .net is complaining about the type that is in the content-type of the root mime part, that received "application/soap+xml; action=\"SendFile\"", but expected "application/soap+xml" - i wanted to put here the right message, but i'tm at a different pc right now and the error that appears now is "MTOM messages must have type 'application/xop+xml'.", looking at the message, it really is quite different from the others.

Using a .net client, the type has only "application/soap+xml", both in the root mime part and in the message header, in the start-info tag. In the message sent by soapui, that tag has "application/soap+xml" and the type of the root mime part has "application/soap+xml; action=\"SendFile\"", which may be what is causing this.

Looking at the W3C http://www.w3.org/TR/2005/REC-xop10-20050125/#mime_xop_packages, i think that start-info must contain the same value as the type parameter of the root mime part.

Can you look into this?

Here is the message from the http log. 

POST ############## HTTP/1.1
Accept-Encoding: gzip,deflate
Content-Type: multipart/related; type="application/xop+xml"; start="<rootpart@soapui.org>"; start-info="application/soap+xml"; action="SendFile"; boundary="----=_Part_10_7396679.1285664994648"
MIME-Version: 1.0
User-Agent: Jakarta Commons-HttpClient/3.1
Host: ##########
Content-Length: 3830

------=_Part_10_7396679.1285664994648

Content-Type: application/xop+xml; charset=UTF-8; type="application/soap+xml; action=\"SendFile\""

Content-Transfer-Encoding: 8bit

Content-ID: <rootpart@soapui.org>

<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:urn="########" xmlns:mtom="http://schemas.datacontract.org/2004/07/MtomService">
   <soap:Header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:Action>SendFile</wsa:Action><wsa:To>###########################</wsa:To></soap:Header>
   <soap:Body>
      <urn:SendFile>
         <urn:sendInput>
            <mtom:CorrelationID>96</mtom:CorrelationID>
            <mtom:OperationID>23</mtom:OperationID>
            <mtom:BusinessProcessID>24</mtom:BusinessProcessID>
            <mtom:RequiresDeliveryConfirmation>true</mtom:RequiresDeliveryConfirmation>
           <mtom:RequiresTransmissionSecurity>false</mtom:RequiresTransmissionSecurity>
            <mtom:IncludesAttachment>true</mtom:IncludesAttachment>
            <mtom:Attachment><inc:Include href="cid:file.zip" xmlns:inc="http://www.w3.org/2004/08/xop/include"/></mtom:Attachment>
            <mtom:FileFormat>zip</mtom:FileFormat>
         </urn:sendInput>
      </urn:SendFile>
   </soap:Body>
</soap:Envelope>

------=_Part_10_7396679.1285664994648

Content-Type: application/zip; name=file.zip

Content-Transfer-Encoding: binary

Content-ID: <file.zip>

Content-Disposition: attachment; name="file.zip"; filename="file.zip"

### binary data ###

------=_Part_10_7396679.1285664994648--

8 Replies

Sort By
  • sirclaudio's avatar
    sirclaudio
    New Contributor
    13 years ago
    I've downloaded soapui 4.0.0 source and changed a line in file com.eviware.soapui.impl.wsdl.submit.transports.http.support.attachments.AttachmentUtils:



    line 382:

     public static String buildMTOMContentType( String header, String action, SoapVersion soapVersion )
     {
      int ix = header.indexOf( "boundary" );
      String contentType = "multipart/related; type=\"application/xop+xml\"; start=\"" + ROOTPART_SOAPUI_ORG + "\"; "
        + "start-info=\"" + soapVersion.getContentType();

      if( soapVersion == SoapVersion.Soap12 && action != null )
      {
       //contentType += "\"; action=\"" + action;
       contentType += "; action=\\\"" + action + "\\\"";
      }
      // nested or not? see
      // http://www.eviware.com/forums/index.php?topic=2866.new#new
      // contentType += "; action=\\\"" + action + "\\\"\"; action=\"" + action;

      return contentType + "\"; " + header.substring( ix );
     }


    With this, root mime part is equal to the start-info tag, which is what the standard says, making invocations to .Net Mtom services successful
  • SmartBear_Suppo's avatar
    SmartBear_Suppo
    SmartBear Alumni (Retired)
    13 years ago
    Hi,

    thanks for this - I'll report it internally and hopefully we can get your fix into the codebase..

    best regards,

    /Ole
    SmartBear Stockholm
  • soapuiUser123's avatar
    soapuiUser123
    New Contributor
    12 years ago
    Hi,

    I am facing a similar issue with MTOM enabled .net service. I am using SOAPUIv4.5.0 free version and enabling MTOM in soapui for a soap1.2 .net service gets me a HTTP 400 bad request from the IIS7.5 server.
    A simple java client works fine sending/receiving MTOM messages to/from the service.

    I was wondering if the issue mentioned in this topic could be a possible cause. Is the code change mentioned above, in the any of the release yet.

    Appreciate any help.

    Thanks.
  • solidstore's avatar
    solidstore
    New Contributor
    12 years ago
    Could we have an update in this issue? It still occurs in soapUI Pro 4.5.1 (Build [internal], Build Date 2012/06/27 14:05)
  • jnotion's avatar
    jnotion
    12 years ago
    Any update on this issue. Or is there a suitable workaround. This is a big blocking issue to testing WCF MTOM services
  • CRicketts's avatar
    CRicketts
    Occasional Contributor
    11 years ago
    Any update on this issue. Or is there a suitable workaround.

    This still seems to be an issue with SoapUI Pro 4.5.2, including the nightly builds.

    Could someone from SmartBear please comment?
  • balind's avatar
    balind
    11 years ago
    This is still broken in soapUI 4.6.0. In addition to the Content-Type of the SOAP part being messed up (the action embedded inside the type quotes), the line endings are just LF in Fiddler's hex view inspector. This is not valid MIME. Line endings should always be CRLF. In my scenario, I fixed the Content-Type in Fiddler, but WCF still couldn't parse the MTOM encoded response from soapUI. I'm assuming its because of the line ending issue I'm seeing.