• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

A question on MTOM message Header parameters

 
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Friends,

Can anyone please explain me the following from the below MTOM message from MK's note:
1) In first Content-Type
Content-Type: multipart/related;
start="<rootpart*b0ef6adc-44fa-47ba-a7a7-95915eb54d9e@example.jaxws.sun.com>";
type="application/xop+xml";
boundary="uuid:b0ef6adc-44fa-47ba-a7a7-95915eb54d9e";
start-info="text/xml"

what purpose does "type" and "start-info" solves when we already have value for Content-Type as "multipart/related".

Can you please explain all three a) Content-Type b) type c) start-info

2) What is boundary used for ?

3) In the following:
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"

what purpose does "type" solves when we already have value for Content-Type as "application/xop+xml".

COMPLETE MTOM MSG:
#################################################################

POST /mtomService/mtomPort HTTP/1.1
SOAPAction: ""
Accept: text/xml, multipart/related, text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Content-Type: multipart/related;
start="<rootpart*b0ef6adc-44fa-47ba-a7a7-95915eb54d9e@example.jaxws.sun.com>";
type="application/xop+xml";
boundary="uuid:b0ef6adc-44fa-47ba-a7a7-95915eb54d9e";
start-info="text/xml"
User-Agent: JAX-WS RI 2.1.4.1-hudson-346-
Host: localhost:9088
Connection: keep-alive
Content-Length: 890

--uuid:b0ef6adc-44fa-47ba-a7a7-95915eb54d9e
Content-Id: <rootpart*b0ef6adc-44fa-47ba-a7a7-95915eb54d9e@example.jaxws.sun.com>
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
Content-Transfer-Encoding: binary

<?xml version='1.0' encoding='UTF-8'?>
<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body>
<ns2:mtomOperation xmlns:ns2="http://j2ee.netbeans.org/wsdl/mtomBP/mtom">
<part1>hello</part1>
<part2>
<xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include"
href="cid:2f3a859b-6cdb-4eba-8163-0365521f094c@example.jaxws.sun.com" />
</part2>
</ns2:mtomOperation>
</S:Body>
</S:Envelope>
--uuid:b0ef6adc-44fa-47ba-a7a7-95915eb54d9e
Content-Id: <2f3a859b-6cdb-4eba-8163-0365521f094c@example.jaxws.sun.com>
Content-Type: application/octet-stream
Content-Transfer-Encoding: binary

[BINARY ATTACHMENT]

--uuid:b0ef6adc-44fa-47ba-a7a7-95915eb54d9e--


#################################################################

 
jigar singh
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also, in MK's notes , i did not understand below line. In the above post we using MTOM by sending binary data which is not encoded "Content-Transfer-Encoding: binary ". then why it is said we need to encode your binary data as xs:base64Binary content. ??

###################################
11.2. Use MTOM on the client.

11.2.1. Use MTOMFeature with getPort() methods.

If you want to use MTOM, you should encode your binary data as xs:base64Binary content.
###################################
 
Creator of Enthuware JWS+ V6
Posts: 3411
320
Android Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


what purpose does "type" and "start-info" solves when we already have value for Content-Type as "multipart/related".

Can you please explain all three a) Content-Type b) type c) start-info


These are specified by the MTOM specification


3.2 Serialization of a SOAP message

When sending a SOAP message using the MIME Multipart/Related Serialization, the SOAP envelope Infoset is serialized as specified in [XML-binary Optimized Packaging] 3.1 Creating XOP packages. Specifically:

  • The content-type of the outer package MUST be multipart/related.
  • The type parameter of the content-type header of the outer package MUST have a value of "application/xop+xml"
  • The startinfo parameter of the content-type header of the outer package MUST specify a content-type for the root part of "application/soap+xml".
  • The content-type of the root part MUST be application/xop+xml
  • The type parameter of the content-type header of the root part MUST specify a content-type of "application/soap+xml".

  • The result is a MIME Multipart/Related XOP package: one body part, the root, containing an XML representation of the modified SOAP envelope, with an additional part used to contain the binary representation of each element that was optimized.


    The startinfo should be "application/soap+xml", probably MZ's notes are showing an older version of MTOM.

    2) What is boundary used for ?


    To separate the different MIME parts

    3) In the following:
    Content-Type: application/xop+xml;charset=utf-8;type="text/xml"

    what purpose does "type" solves when we already have value for Content-Type as "application/xop+xml".


    Again: this is how it is specified.

    To correct the line according to the latest MTOM specifications:

    Content-Type: application/xop+xml;charset=utf-8;type="application/soap+xml"



    Also, in MK's notes , i did not understand below line. In the above post we using MTOM by sending binary data which is not encoded "Content-Transfer-Encoding: binary ". then why it is said we need to encode your binary data as xs:base64Binary content. ??


    I guess what he wants to say is: "Optimization is available only for element content that is in a canonical lexical representation of the xs:base64Binary data type"
     
    jigar singh
    Greenhorn
    Posts: 15
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thank you so much Frits. Very good explanation.

    Best Regards.
     
    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
    reply
      Bookmark Topic Watch Topic
    • New Topic