[
https://issues.apache.org/jira/browse/WSCOMMONS-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rich Scheuerle reassigned WSCOMMONS-290:
----------------------------------------
Assignee: Rich Scheuerle (was: Nick Gallardo)
> Improve compatibility of MIME Mutlipart/Related Content-Type
> -------------------------------------------------------------
>
> Key: WSCOMMONS-290
> URL: https://issues.apache.org/jira/browse/WSCOMMONS-290
> Project: WS-Commons
> Issue Type: Improvement
> Components: AXIOM
> Reporter: Nick Gallardo
> Assignee: Rich Scheuerle
> Attachments: WSCOMMONS-290-patch.txt
>
>
> In SOAP 1.2/MTOM scenarios, there is a minor issue with the Content-Type that
> is generated from the OMOutputFormat. The "action" attribute should not be
> at the root level, but should be a sub-element of the "start-info".
> The "start-info" is defined by RFC 2387[1] as an attribute of the MIME
> Multipart/Related Content-Type. Within there, the content of the
> "start-info" is left up to the applications using it. In this case, the
> "start-info" content is defined by the XOP spec[2]. In there, it says "The
> "start-info" parameter of the package's media type MUST contain the content
> type associated with the content's XML serialization. (i.e. it will contain
> the same value as the "type" parameter of the root part)."
> That means the content of the "start-info" should match what would have
> existed in the application/soap+xml case. Specifically, this means that the
> "action" attribute should be included.
> Here's an example of what we're generating today:
> Content-Type: multipart/related;
> boundary=MIMEBoundaryurn_uuid_D63C1DBB2B25C318FC1187277157502;
> type="application/xop+xml"; start="<0.urn:uuid:[EMAIL PROTECTED]>";
> start-info="application/soap+xml";action="sendImage";
> Notice how the "start-info" and the "action" are separated
> (start-info="application/soap+xml";action="sendImage";). Note, the
> "start-info" content is created by the OMOutputFormat, but the "action" value
> is added on by Axis2.
> Here's an example of what we should be generating:
> Content-Type: multipart/related;
> boundary=MIMEBoundaryurn_uuid_D63C1DBB2B25C318FC1187277157502;
> type="application/xop+xml"; start="<0.urn:uuid:[EMAIL PROTECTED]>";
> start-info="application/soap+xml; action=\"sendImage\"";
> With that, the "action" is tucked under the "start-info". This reflects what
> is sent in the normal SOAP 1.2 or application/soap+xml content type case.
> To increase our compatibility with runtimes that adhere strictly to the
> specifications, I propose we add the "action" in the second format above. In
> the interest maintaining compatibility with existing clients and services, I
> suggest this information be additive only and that we not remove the position
> of any existing info in the Content-Type. Here's an example of what I
> propose we generate:
> Content-Type: multipart/related;
> boundary=MIMEBoundaryurn_uuid_D63C1DBB2B25C318FC1187277157502;
> type="application/xop+xml"; start="<0.urn:uuid:[EMAIL PROTECTED]>";
> start-info="application/soap+xml; action=\"sendImage\""; action="sendImage";
> It's a little redundant, but allows for the greatest level of flexibility. I
> will provide a patch that will enable this. With that, I will then leverage
> this in Axis2 to make sure we're sending the right content.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
