I am making a soap request which is returning the following:
HTTP/1.1 200 OK
Content-Length: 7048
Content-Type: multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:dc2ee0dc-fd91-40ef-949d-2c1b02108e23+id=4";start-info="text/xml"
Server: Microsoft-HTTPAPI/2.0
MIME-Version: 1.0
Date: Tue, 25 Oct 2011 12:56:17 GMT
--uuid:dc2ee0dc-fd91-40ef-949d-2c1b02108e23+id=4
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
<s:Envelope details />
Everything is good except that the section
--uuid:dc2ee0dc-fd91-40ef-949d-2c1b02108e23+id=4
Content-ID: <http://tempuri.org/0>
Content-Transfer-Encoding: 8bit
Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
Is being considered part of the body which it throwing off xml parsing. I'm wondering what this uuid information id and why is it coming down as part of the body rather than the header? (Along with the content-id, content-transfer-encoding and content-type?)
Figured it out based on Ladislav Mrnkas MTOM comment. In my app.config I changed:
<binding name="BindingName" messageEncoding="Mtom" maxReceivedMessageSize="1006710886">
To
<binding name="BindingName" messageEncoding="Text" maxReceivedMessageSize="1006710886">
This is important for anyone running ksoap2 as it will not process the mtom message and will throw an xml parsing exception.
If SOAP UI client is used for running the SOAP request, set the TestRequest Properties: Inline Response Attachments to "false". This will fix the uuid being appended in the SOAP response.
[Note :The TestRequest Properties is unique to every Test step in a Test Suite.]
Related
I am implementing a client that receives SOAP MTOM+XOP messages. (XDS.b Consumer to retrieve documents)
I know that for small attachments the attached file will be base64 encoded into the body and for big ones the binary data will be attached in a separate MIME part and a as my Client proxy class.
After I get the Message, the binary data already been encoded into the body as base64, so I implemented CustomEncoded and IncommingInspector and I was able to see the buffer and dumping the message before returning it to the client.
My question: I would like to prevent the process of Encoding/Decoding to Base64 if possible. I would like to get the binary part, write it to the file (for example) and if possible to return a file location in the message body instead of the huge base64 encoded string.
Is this possible?
Following is a sample of message I am trying to process (binary part replaced with ...)
HTTP/1.1 200 OK
Date: Tue, 02 Dec 2014 11:07:55 GMT
Server: Apache
Set-Cookie: JSESSIONID=005193579FC6F91CC7BD0B671E616CB6; Path=/um
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: multipart/related; start-info="application/soap+xml"; type="application/xop+xml"; boundary="----=_Part_178_590817.1417518476024"
1ff8
------=_Part_178_590817.1417518476024
Content-Type: application/xop+xml; charset=utf-8; type="application/soap+xml"
Content-Id: <http://corp.com/xds_source>
Content-Transfer-Encoding: 8bit
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<wsa:Action xmlns:wsa="http://www.w3.org/2005/08/addressing">urn:ihe:iti:2007:RetrieveDocumentSetResponse</wsa:Action>
<wsa:RelatesTo xmlns:wsa="http://www.w3.org/2005/08/addressing">urn:uuid:123503ce-fba9-4bed-a77f-0cf6d9a51744</wsa:RelatesTo>
</env:Header>
<env:Body>
<xdsb:RetrieveDocumentSetResponse xmlns:xdsb="urn:ihe:iti:xds-b:2007">
<RegistryResponse xmlns="urn:oasis:names:tc:ebxml-regrep:xsd:rs:3.0" status="urn:oasis:names:tc:ebxml-regrep:ResponseStatusType:Success"/>
<xdsb:DocumentResponse><xdsb:RepositoryUniqueId>SAMPLE:12345678</xdsb:RepositoryUniqueId>
<xdsb:DocumentUniqueId>1.2.840.113704.7.1.0.14117819932881.1416384260.2</xdsb:DocumentUniqueId>
<xdsb:mimeType>application/vnd.openxmlformats-officedocument.wordprocessingml.document</xdsb:mimeType>
<xdsb:Document><xop:Include xmlns:xop="http://www.w3.org/2004/08/xop/include" href="cid:1.urn:uuid:179268344.0#corp.org"/>
</xdsb:Document>
</xdsb:DocumentResponse>
</xdsb:RetrieveDocumentSetResponse>
</env:Body>
</env:Envelope>
------=_Part_178_590817.1417518476024
Content-Type: application/octet-stream
Content-ID: <1.urn:uuid:179268344.0#corp.org>
Content-Transfer-Encoding: binary
...
------=_Part_178_590817.1417518476024--
I'm trying create a draft (or send a message) with attachment to gmail using its API. I've read some answers and tried to built the request according to what I've read here: Mail attachment wrong media type Gmail API
Before coding the function itself, I decided to use a Chrome extension (Simple Rest Client) to simulate the API request. Here's the request body:
Content-Type: multipart_mixed; boundary="foo_bar_baz"
MIME-Version: 1.0
to: receiver#gmail.com
from: sender#gmail.com
subject: Testing Subject
--foo_bar_baz
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
This is the testing text
--foo_bar_baz
Content-Type: image/jpeg
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test.jpg"
{
"message":
{
"raw" : "_9j_4AAQSkZJRgABAQEAYABgAAD_2wBDAAIBAQIBAQICAgICAgICAwUDAwMDAwYEBAMFBwYHBwcGBwcICQsJCAgKCAcHCg0KCgsMDAwMBwkODw0MDgsMDAz_2wBDAQICAgMDAwYDAwYMCAcIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAz_wAARCAAJAAsDASIAAhEBAxEB_8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL_8QAtRAAAgEDAwIEAwUFBAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4-Tl5ufo6erx8vP09fb3-Pn6_8QAHwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL_8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3-Pn6_9oADAMBAAIRAxEAPwD9Pfiv-wN4q8cftk3Pji30_wCH9z9v8V6H4ksPiFe3cy-MvAunaeuni68N6bCLR92n3_2G8ErLf2yAeIL_AHW021xdfX9FFAH_2Q**"
}
}
--foo_bar_baz--
The request header parameters are as follows:
Authorization: Bearer *given token*
Content-Type: multipart/mixed; boundary="foo_bar_baz"
Content-Length: 1428
As you can see, it's pretty similar to the example in the link above. However, I keep getting the following response:
"message": "Media type 'application/octet-stream' is not supported. Valid media types: [message/rfc822]"
I know the API docs say the only valid media type is message/rfc822 (https://developers.google.com/gmail/api/v1/reference/users/drafts/create). Nonetheless, this sample (https://developers.google.com/gmail/api/guides/uploads#multipart) and others here in Stackoverflow say otherwise. The author of the question in the link above seem to have solved his problem without using message/rfc822 media type.
I gotta be missing something. Can someone help me with this? I'd really appreciate if someone could help me figure it out.
OK, so if you're using the /upload media feature (works for all messages irregardless of size) then for example it should be something like the following (and looks like i was a bit mistaken):
POST https://www.googleapis.com/upload/gmail/v1/users/me/messages/send
Content-Type: multipart/related; boundary=foo_bar_baz
then your POST body should be something like the following (not encoded, etc):
--foo_bar_baz
Content-Type: application/json; charset=UTF-8
{
}
--foo_bar_baz
Content-Type: message/rfc822
MIME-Version: 1.0
to: receiver#gmail.com
from: sender#gmail.com
subject: Testing Subject
--foo_bar_baz
Content-Type: text/plain; charset="UTF-8"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
This is the testing text
--foo_bar_baz
Content-Type: image/jpeg
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="test.jpg"
--foo_bar_baz--
So things to note are that it's actually "multipart/related" and that has a application/json (for some requests you can add parameters there) part as well as a message/rfc822 part that contains the entire email.
It's not easy for sure--libraries definitely make it less painful if you can use them!
I'm having problems talking to Java WS. I'm using "wsHttpBinding" binding with client certificates for authentication, message encoding is set "Text", .net framework is 4.0. Server side is Java and I have no control over it. Connection is being proxied through Fiddler (this is how I see requests on the wire, much more user friendly than tracing "System.Net").
Exception I get is following:
The content type application/xop+xml; type="application/soap+xml" of the response message does not match the content type of the binding (application/soap+xml; charset=utf-8).
If I change message encoding to "Mtom", then the exception changes:
The content type application/xop+xml; type="application/soap+xml" of the response message does not match the content type of the binding (multipart/related; type="application/xop+xml").
Server is accepting both "Text" and "Mtom" message encodings for request, and response is always the same. This is the raw response that I'm getting from the server:
HTTP/1.1 200 OK
X-Backside-Transport: OK OK
Connection: Keep-Alive
X-Powered-By: Servlet/3.0
SOAPAction: ""
Content-Type: application/xop+xml; type="application/soap+xml"
Content-Language: en-US
Date: Thu, 25 Jul 2013 13:05:09 GMT
Content-Length: 628
<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope ... </env:Envelope>
From all the docs which I have been reading, response that is being returned is somewhere between regular SOAP message and MTOM message. I'm saying this because every example which I've seen says that the MTOM request and response use MIME as an envelope for communication: regular SOAP message is enveloped in XOP package, and then this XOP message is enveloped with MIME. Even the W3C recommendation uses MIME for XOP packages: W3C: XML-binary Optimized Packaging. Excerpt from this link:
Content-Type: Multipart/Related;boundary=...
If I try calling web service using tool "soapUI" (written in Java, available from "www.soapui.org"), service call is successfully executed and response is parsed without any problem.
FYI, this is a cross-post from MSDN WCF forum., but no responses there yet.
Any idea is appreciated, thanks in advance,
Alex
I'm also using CXF, and has a C# client. Try modifying your binding setting, replace textMessageEncoding with mtomMessageEncoding. Something like this:
<binding name="yourSoapBinding">
<mtomMessageEncoding messageVersion="Soap12"/>
<httpTransport />
</binding>
Try setting the message encoding in the binding configuration to messageEncoding="Mtom" and basicHTTPBinding instead of wsHTTP one...
Hope it helps!
I am working with version 4.1.0 of the WSO2 Identity Server. I have used the WSO2 AuthenticationAdmin services (localhost:9443/services/AuthenticationAdmin) to login, check authenticator, etc. There is also an operation for 'logout'.
When soapUI generates the logout request, it does not contain any noteworthy elements, as is confirmed by the schema (xsd) with the namespace http://authentication.services.core.carbon.wso2.org. The SOAP request body is as follows.
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope" xmlns:aut="http://authentication.services.core.carbon.wso2.org">
<soap:Header/>
<soap:Body>
<aut:logout/>
</soap:Body>
</soap:Envelope>
When sending a request, the RAW response is as follows.
HTTP/1.1 202 Accepted
Date: Wed, 26 Jun 2013 08:29:48 GMT
Server: WSO2 Carbon Server
Content-Type: text/xml;charset=UTF-8
Set-Cookie: JSESSIONID=94784CC9FC03E9FA3822CFDDAD0D36F6; Path=/; Secure; HttpOnly
Vary: Accept-Encoding
Content-Encoding: gzip
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
First of all, do I think there is no SOAP message in the response. Also, the HTTP status is 202, which means that the request is accepted for processing, but the processing has not yet been completed.
How do I logout with this service?
What elements should be added to the < aut:logout > ?
Should a JSESSIONID be added to the header of the request?
How can this logout be combined with the loginWithRememberMeOption ?
------- UPDATE
After reviewing the xsd I saw that a wsa:action must be added to the SOAP Header. After doing this, I received the following reply. This reply asks for a MessageID. But I am not sure what this value should be.
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Header xmlns:wsa="http://www.w3.org/2005/08/addressing">
<wsa:Action>http://www.w3.org/2005/08/addressing/fault</wsa:Action>
</soapenv:Header>
<soapenv:Body>
<soapenv:Fault>
<soapenv:Code>
<soapenv:Value>soapenv:Sender</soapenv:Value>
<soapenv:Subcode>
<soapenv:Value xmlns:wsa="http://www.w3.org/2005/08/addressing">wsa:MessageAddressingHeaderRequired</soapenv:Value>
</soapenv:Subcode>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text xml:lang="en-US">A required header representing a Message Addressing Property is not present</soapenv:Text>
</soapenv:Reason>
<soapenv:Detail>
<wsa:ProblemHeaderQName xmlns:wsa="http://www.w3.org/2005/08/addressing">wsa:MessageID</wsa:ProblemHeaderQName>
</soapenv:Detail>
</soapenv:Fault>
</soapenv:Body>
</soapenv:Envelope>
When adding a generated MessageID, the is once again an empty SOAP reply with a HTTP 202 status.
The logout method just invalidates the session.
You just call the logout operation as it is from the soapUI. There are no parameters to it.
If you look at the AuthenticationAdmin WSDL, you can see that there is no output for logout operation. That's why you get HTTP 202 status code.
You can view the WSDL by changing <HideAdminServiceWSDLs> configuration to false in carbon.xml (/repository/conf/carbon.xml)
<HideAdminServiceWSDLs>false</HideAdminServiceWSDLs>
Type following in your browser to view the WSDL.
https://:9443/services/AuthenticationAdmin?wsdl
I hope this helps!
I have a WCF service that has webHttpBinding and has enableWebScript turned on in it's endpoint behavior configuration.
The response from the service looks something like this
HTTP/1.1 200 OK
Date: Fri, 23 Oct 2009 20:09:02 GMT
Server: Microsoft-IIS/6.0
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: application/json; charset=utf-8
Content-Length: 25
{"d":{"__type":"SOMETYPE", ... }}
Its using HTTP 1.1 and so there are the standard headers. The contentType is set to be applciation/json which also makes sense. In the message body (the JSON part), everything is enclosed in an envelope titled "d".
What is that? Who defines that protocol? Is it something specific to WCF?
I couldn't find that defined in any of the protocols involved or the definition of the "application/json" contentType.
Thanks
That is ASP.NET AJAX specific and is caused by applying the WebScriptEnablingBehavior (enableWebScript in config) to your endpoint. The wrapper is required on both input and output and there are also special behaviors added around exception handling.
If you want "pure" JSON, you should remove the WebScriptEnablingBehavior and just use WebHttpBehavior (webHttp in config). Then just make sure you explicitly set the Request/ResponseFormat properties on your WebGet/InvokeAttributes.