Mailing-List: contact commons-dev-help@ws.apache.org; run by ezmlm
Precedence: bulk
Reply-To: commons-dev@ws.apache.org
Message-ID: <969905451.1204733380703.JavaMail.jira@brutus>
Date: Wed, 5 Mar 2008 08:09:40 -0800 (PST)
From: "Rich Scheuerle (JIRA)" <jira@apache.org>
To: commons-dev@ws.apache.org
Subject: [jira] Resolved: (WSCOMMONS-290) Improve compatibility of MIME
 Mutlipart/Related Content-Type
In-Reply-To: <23256375.1199902774178.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/WSCOMMONS-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rich Scheuerle resolved WSCOMMONS-290.
--------------------------------------

    Resolution: Fixed

> 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
>            Priority: Blocker
>         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:D63C1DBB2B25C318FC1187277157503@apache.org>"; 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:D63C1DBB2B25C318FC1187277157503@apache.org>"; 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:D63C1DBB2B25C318FC1187277157503@apache.org>"; 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: commons-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: commons-dev-help@ws.apache.org