10:33 p.m.
I'm trying to talk to a service where the SOAP response is returning
Content-Type: multipart/related. This behavior is documented here
http://www.w3.org/TR/SOAP-attachments
All of the current Python SOAP libraries choke on this behavior. It would
be great if suds could handle Content-Type parsing in the transport
adapters. I'm having difficulty getting my head wrapped around all of the
urllib2 abstractions in transport/http.py.
My best guess is that it needs to happen right before Reply is created, and
that Reply needs to have and attachments[] attribute and probably something
to represent the file.
Thanks,
--Karl
1:15 a.m.
First of all, is this a public service? If so, can you provide a WSDL to us?
If not, can you provide a dump of the request and the response (with sensitive
material stripped if needed)?
Regards,
András Veres-Szentkirályi
2011. november 9. szerda 05:33:13 dátummal Karl Putland ezt írta:
I'm trying to talk to a service where the SOAP response is
returning
Content-Type: multipart/related. This behavior is documented here
http://www.w3.org/TR/SOAP-attachments
All of the current Python SOAP libraries choke on this behavior. It would
be great if suds could handle Content-Type parsing in the transport
adapters. I'm having difficulty getting my head wrapped around all of the
urllib2 abstractions in transport/http.py.
My best guess is that it needs to happen right before Reply is created, and
that Reply needs to have and attachments[] attribute and probably something
to represent the file.
Thanks,
--Karl
6:07 p.m.
Sorry for they delay and thank you for looking.
Not public.
WSDL attached.
Output from sample script attached.
From what I can tell... none of the python libraries are currently
supporting SOAP-attachments.
I added some debugging in SoapClient.send
request.headers = self.headers()
reply = transport.send(request)
if DEBUG:
print '*&'*40
print 'raw reply'
print '*&'*40
print reply
print '*&'*40
ctx = plugins.message.received(reply=reply.message)
reply.message = ctx.reply
It may be possible to implement in the plugins, but the headers don't pass
through to the plugin... :/
It seems that the best place for the multipart handling is in
transport/http.py in the Reply object. Pass the headers in as HTTPMessage
instead of the Dict to reconstruct the MimeMessage, then if it's
Content-Type: text="text/xml" dump the body as the reply. otherwise follow
the w3 doc and dump the rootpart ast the reply and create a list of
attachment file-like objects.
Thanks,
--Karl
On Wed, Nov 9, 2011 at 12:15 AM, Veres-Szentkiralyi Andras <vsza(a)vsza.hu>wrote:
First of all, is this a public service? If so, can you provide a WSDL
to
us?
If not, can you provide a dump of the request and the response (with
sensitive
material stripped if needed)?
Regards,
András Veres-Szentkirályi
2011. november 9. szerda 05:33:13 dátummal Karl Putland ezt írta:
> I'm trying to talk to a service where the SOAP response is returning
> Content-Type: multipart/related. This behavior is documented here
>
> http://www.w3.org/TR/SOAP-attachments
>
> All of the current Python SOAP libraries choke on this behavior. It would
> be great if suds could handle Content-Type parsing in the transport
> adapters. I'm having difficulty getting my head wrapped around all of the
> urllib2 abstractions in transport/http.py.
>
> My best guess is that it needs to happen right before Reply is created,
and
> that Reply needs to have and attachments[] attribute and probably
something
> to represent the file.
>
> Thanks,
>
> --Karl
_______________________________________________
suds mailing list
suds(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/suds
1:22 p.m.
Hi,
I created a proof-of-concept patch, that works with the network traffic you
sent, and is available in my GitHub repository:
https://github.com/dnet/suds/commit/4c930c764d8639c5d808609c756466c3e6070976
You can download the single modified file (transport/__init__.py) from the
following URL -- if you replace this with the one in your SUDS installation,
the example you sent to the mailing list should work.
https://github.com/dnet/suds/raw/4c930c764d8639c5d808609c756466c3e6070976...
As you suggested, I put the logic into the Reply class, and the additional
methods check for multipart content. If no such content found, normal program
flow remains undisturbed, so this shouldn't cause any regressions. The part
marked as "start" gets in place of the message, other parts can be accessed
using the "parts" member. As it uses the standard email library, even encoded
parts (e.g. base64) can be decoded, and it should work on any Python 2.4+
install (I tested it on 2.7.2).
Let me know, whether it works in real life, I'm interested in the results.
Regards,
András Veres-Szentkirályi
2011. november 16. szerda 01:07:07 dátummal Karl Putland ezt írta:
Sorry for they delay and thank you for looking.
Not public.
WSDL attached.
Output from sample script attached.
>From what I can tell... none of the python libraries are currently
supporting SOAP-attachments.
I added some debugging in SoapClient.send
request.headers = self.headers()
reply = transport.send(request)
if DEBUG:
print '*&'*40
print 'raw reply'
print '*&'*40
print reply
print '*&'*40
ctx = plugins.message.received(reply=reply.message)
reply.message = ctx.reply
It may be possible to implement in the plugins, but the headers don't pass
through to the plugin... :/
It seems that the best place for the multipart handling is in
transport/http.py in the Reply object. Pass the headers in as HTTPMessage
instead of the Dict to reconstruct the MimeMessage, then if it's
Content-Type: text="text/xml" dump the body as the reply. otherwise follow
the w3 doc and dump the rootpart ast the reply and create a list of
attachment file-like objects.
Thanks,
--Karl
On Wed, Nov 9, 2011 at 12:15 AM, Veres-Szentkiralyi Andras
<vsza(a)vsza.hu>wrote:
> First of all, is this a public service? If so, can you provide a
WSDL to
> us?
> If not, can you provide a dump of the request and the response (with
> sensitive
> material stripped if needed)?
>
> Regards,
> András Veres-Szentkirályi
>
> 2011. november 9. szerda 05:33:13 dátummal Karl Putland ezt írta:
> > I'm trying to talk to a service where the SOAP response is returning
> > Content-Type: multipart/related. This behavior is documented here
> >
> > http://www.w3.org/TR/SOAP-attachments
> >
> > All of the current Python SOAP libraries choke on this behavior. It
> > would be great if suds could handle Content-Type parsing in the
> > transport adapters. I'm having difficulty getting my head wrapped
> > around all of the urllib2 abstractions in transport/http.py.
> >
> > My best guess is that it needs to happen right before Reply is created,
>
> and
>
> > that Reply needs to have and attachments[] attribute and probably
>
> something
>
> > to represent the file.
> >
> > Thanks,
> >
> > --Karl
>
> _______________________________________________
> suds mailing list
> suds(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/suds
1:41 p.m.
Great!
I'll check it out now.
Thanks,
--Karl
On Wed, Nov 16, 2011 at 12:22 PM, Veres-Szentkiralyi Andras <vsza(a)vsza.hu>wrote:
Hi,
I created a proof-of-concept patch, that works with the network traffic you
sent, and is available in my GitHub repository:
https://github.com/dnet/suds/commit/4c930c764d8639c5d808609c756466c3e6070976
You can download the single modified file (transport/__init__.py) from the
following URL -- if you replace this with the one in your SUDS
installation,
the example you sent to the mailing list should work.
https://github.com/dnet/suds/raw/4c930c764d8639c5d808609c756466c3e6070976...
As you suggested, I put the logic into the Reply class, and the additional
methods check for multipart content. If no such content found, normal
program
flow remains undisturbed, so this shouldn't cause any regressions. The part
marked as "start" gets in place of the message, other parts can be accessed
using the "parts" member. As it uses the standard email library, even
encoded
parts (e.g. base64) can be decoded, and it should work on any Python 2.4+
install (I tested it on 2.7.2).
Let me know, whether it works in real life, I'm interested in the results.
Regards,
András Veres-Szentkirályi
2011. november 16. szerda 01:07:07 dátummal Karl Putland ezt írta:
> Sorry for they delay and thank you for looking.
>
> Not public.
> WSDL attached.
> Output from sample script attached.
>
> >From what I can tell... none of the python libraries are currently
>
> supporting SOAP-attachments.
>
>
> I added some debugging in SoapClient.send
> request.headers = self.headers()
> reply = transport.send(request)
> if DEBUG:
> print '*&'*40
> print 'raw reply'
> print '*&'*40
> print reply
> print '*&'*40
> ctx = plugins.message.received(reply=reply.message)
> reply.message = ctx.reply
>
> It may be possible to implement in the plugins, but the headers don't
pass
> through to the plugin... :/
> It seems that the best place for the multipart handling is in
> transport/http.py in the Reply object. Pass the headers in as HTTPMessage
> instead of the Dict to reconstruct the MimeMessage, then if it's
> Content-Type: text="text/xml" dump the body as the reply. otherwise
follow
> the w3 doc and dump the rootpart ast the reply and create a list of
> attachment file-like objects.
>
> Thanks,
>
> --Karl
>
> On Wed, Nov 9, 2011 at 12:15 AM, Veres-Szentkiralyi Andras
<vsza(a)vsza.hu>wrote:
> > First of all, is this a public service? If so, can you provide a WSDL
to
> > us?
> > If not, can you provide a dump of the request and the response (with
> > sensitive
> > material stripped if needed)?
> >
> > Regards,
> > András Veres-Szentkirályi
> >
> > 2011. november 9. szerda 05:33:13 dátummal Karl Putland ezt írta:
> > > I'm trying to talk to a service where the SOAP response is returning
> > > Content-Type: multipart/related. This behavior is documented here
> > >
> > > http://www.w3.org/TR/SOAP-attachments
> > >
> > > All of the current Python SOAP libraries choke on this behavior. It
> > > would be great if suds could handle Content-Type parsing in the
> > > transport adapters. I'm having difficulty getting my head wrapped
> > > around all of the urllib2 abstractions in transport/http.py.
> > >
> > > My best guess is that it needs to happen right before Reply is
created,
> >
> > and
> >
> > > that Reply needs to have and attachments[] attribute and probably
> >
> > something
> >
> > > to represent the file.
> > >
> > > Thanks,
> > >
> > > --Karl
> >
> > _______________________________________________
> > suds mailing list
> > suds(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/suds
_______________________________________________
suds mailing list
suds(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/suds
2:28 p.m.
So the proof works for the calls that aren't including actual files but
fails for the calls downloadLargeXMLFile etc... where a zip file is being
expected.
Further investigation into the definitions in the WSDL leads to
documentation on MTOM.
http://metro.java.net/guide/Binary_Attachments__MTOM_.html
http://axis.apache.org/axis2/java/core/docs/mtom-guide.html
I might be ok for the short term with the multipart parsing... It would be
"a good thing" to support MTOM for interoperability and would surely bring
more users to suds.
--Karl
error on doDownlaodLargeXmlFile
Karl-Putlands-MacBook-Pro:vsxconf karl$ python vsxtest.py
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&
raw reply
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&
CODE: 200
HEADERS: {'transfer-encoding': 'chunked', 'date': 'Wed, 16 Nov
2011
19:52:03 GMT', 'connection': 'close', 'content-type':
'multipart/related;start="<rootpart*
e64255df-09d9-41db-be9b-0b5aa8d90d4f@example.jaxws.sun.com>";type="application/xop+xml";boundary="uuid:e64255df-09d9-41db-be9b-0b5aa8d90d4f";start-info="text/xml"',
'server': 'Apache-Coyote/1.1'}
MESSAGE:
<?xml version="1.0" ?><S:Envelope xmlns:S="
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&
********************************************************************************
Reply:
<?xml version="1.0" ?><S:Envelope xmlns:S="
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
********************************************************************************
No handlers could be found for logger "suds.bindings.multiref"
Traceback (most recent call last):
File "vsxtest.py", line 20, in <module>
result = client.service.doDownloadLargeXmlFile(table="route",
username="xxxxxx", password="xxxxxx")
File "suds/client.py", line 544, in __call__
return client.invoke(args, kwargs)
File "suds/client.py", line 604, in invoke
result = self.send(soapenv)
File "suds/client.py", line 651, in send
result = self.succeeded(binding, reply.message)
File "suds/client.py", line 686, in succeeded
reply, result = binding.get_reply(self.method, reply)
File "suds/bindings/binding.py", line 156, in get_reply
result = self.replycomposite(rtypes, nodes)
File "suds/bindings/binding.py", line 230, in replycomposite
sobject = unmarshaller.process(node, resolved)
File "suds/umx/typed.py", line 66, in process
return Core.process(self, content)
File "suds/umx/core.py", line 48, in process
return self.append(content)
File "suds/umx/core.py", line 63, in append
self.append_children(content)
File "suds/umx/core.py", line 140, in append_children
cval = self.append(cont)
File "suds/umx/core.py", line 61, in append
self.start(content)
File "suds/umx/typed.py", line 80, in start
raise TypeNotFound(content.node.qname())
suds.TypeNotFound: Type not found: 'Include'
vsxconf karl$
On Wed, Nov 16, 2011 at 12:41 PM, Karl Putland <karl(a)klasstek.com> wrote:
Great!
I'll check it out now.
Thanks,
--Karl
On Wed, Nov 16, 2011 at 12:22 PM, Veres-Szentkiralyi Andras <vsza(a)vsza.hu>wrote:
> Hi,
> I created a proof-of-concept patch, that works with the network traffic
> you
> sent, and is available in my GitHub repository:
>
>
> https://github.com/dnet/suds/commit/4c930c764d8639c5d808609c756466c3e6070976
>
> You can download the single modified file (transport/__init__.py) from the
> following URL -- if you replace this with the one in your SUDS
> installation,
> the example you sent to the mailing list should work.
>
>
>
https://github.com/dnet/suds/raw/4c930c764d8639c5d808609c756466c3e6070976...
>
> As you suggested, I put the logic into the Reply class, and the additional
> methods check for multipart content. If no such content found, normal
> program
> flow remains undisturbed, so this shouldn't cause any regressions. The
> part
> marked as "start" gets in place of the message, other parts can be
> accessed
> using the "parts" member. As it uses the standard email library, even
> encoded
> parts (e.g. base64) can be decoded, and it should work on any Python 2.4+
> install (I tested it on 2.7.2).
>
> Let me know, whether it works in real life, I'm interested in the results.
>
> Regards,
> András Veres-Szentkirályi
>
> 2011. november 16. szerda 01:07:07 dátummal Karl Putland ezt írta:
> > Sorry for they delay and thank you for looking.
> >
> > Not public.
> > WSDL attached.
> > Output from sample script attached.
> >
> > >From what I can tell... none of the python libraries are currently
> >
> > supporting SOAP-attachments.
> >
> >
> > I added some debugging in SoapClient.send
> > request.headers = self.headers()
> > reply = transport.send(request)
> > if DEBUG:
> > print '*&'*40
> > print 'raw reply'
> > print '*&'*40
> > print reply
> > print '*&'*40
> > ctx = plugins.message.received(reply=reply.message)
> > reply.message = ctx.reply
> >
> > It may be possible to implement in the plugins, but the headers don't
> pass
> > through to the plugin... :/
> > It seems that the best place for the multipart handling is in
> > transport/http.py in the Reply object. Pass the headers in as
> HTTPMessage
> > instead of the Dict to reconstruct the MimeMessage, then if it's
> > Content-Type: text="text/xml" dump the body as the reply. otherwise
> follow
> > the w3 doc and dump the rootpart ast the reply and create a list of
> > attachment file-like objects.
> >
> > Thanks,
> >
> > --Karl
> >
> > On Wed, Nov 9, 2011 at 12:15 AM, Veres-Szentkiralyi Andras
> <vsza(a)vsza.hu>wrote:
> > > First of all, is this a public service? If so, can you provide a WSDL
> to
> > > us?
> > > If not, can you provide a dump of the request and the response (with
> > > sensitive
> > > material stripped if needed)?
> > >
> > > Regards,
> > > András Veres-Szentkirályi
> > >
> > > 2011. november 9. szerda 05:33:13 dátummal Karl Putland ezt írta:
> > > > I'm trying to talk to a service where the SOAP response is
returning
> > > > Content-Type: multipart/related. This behavior is documented here
> > > >
> > > > http://www.w3.org/TR/SOAP-attachments
> > > >
> > > > All of the current Python SOAP libraries choke on this behavior. It
> > > > would be great if suds could handle Content-Type parsing in the
> > > > transport adapters. I'm having difficulty getting my head wrapped
> > > > around all of the urllib2 abstractions in transport/http.py.
> > > >
> > > > My best guess is that it needs to happen right before Reply is
> created,
> > >
> > > and
> > >
> > > > that Reply needs to have and attachments[] attribute and probably
> > >
> > > something
> > >
> > > > to represent the file.
> > > >
> > > > Thanks,
> > > >
> > > > --Karl
> > >
> > > _______________________________________________
> > > suds mailing list
> > > suds(a)lists.fedoraproject.org
> > > https://admin.fedoraproject.org/mailman/listinfo/suds
> _______________________________________________
> suds mailing list
> suds(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/suds
>
2:29 p.m.
more docs on MTOM
http://en.wikipedia.org/wiki/MTOM
http://www.w3.org/TR/soap12-mtom/
--Karl
On Wed, Nov 16, 2011 at 1:28 PM, Karl Putland <karl(a)klasstek.com> wrote:
So the proof works for the calls that aren't including actual
files but
fails for the calls downloadLargeXMLFile etc... where a zip file is being
expected.
Further investigation into the definitions in the WSDL leads to
documentation on MTOM.
http://metro.java.net/guide/Binary_Attachments__MTOM_.html
http://axis.apache.org/axis2/java/core/docs/mtom-guide.html
I might be ok for the short term with the multipart parsing... It would be
"a good thing" to support MTOM for interoperability and would surely bring
more users to suds.
--Karl
error on doDownlaodLargeXmlFile
Karl-Putlands-MacBook-Pro:vsxconf karl$ python vsxtest.py
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&
raw reply
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&
CODE: 200
HEADERS: {'transfer-encoding': 'chunked', 'date': 'Wed, 16
Nov 2011
19:52:03 GMT', 'connection': 'close', 'content-type':
'multipart/related;start="<rootpart*
e64255df-09d9-41db-be9b-0b5aa8d90d4f@example.jaxws.sun.com>";type="application/xop+xml";boundary="uuid:e64255df-09d9-41db-be9b-0b5aa8d90d4f";start-info="text/xml"',
'server': 'Apache-Coyote/1.1'}
MESSAGE:
<?xml version="1.0" ?><S:Envelope xmlns:S="
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&
********************************************************************************
Reply:
<?xml version="1.0" ?><S:Envelope xmlns:S="
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
********************************************************************************
No handlers could be found for logger "suds.bindings.multiref"
Traceback (most recent call last):
File "vsxtest.py", line 20, in <module>
result = client.service.doDownloadLargeXmlFile(table="route",
username="xxxxxx", password="xxxxxx")
File "suds/client.py", line 544, in __call__
return client.invoke(args, kwargs)
File "suds/client.py", line 604, in invoke
result = self.send(soapenv)
File "suds/client.py", line 651, in send
result = self.succeeded(binding, reply.message)
File "suds/client.py", line 686, in succeeded
reply, result = binding.get_reply(self.method, reply)
File "suds/bindings/binding.py", line 156, in get_reply
result = self.replycomposite(rtypes, nodes)
File "suds/bindings/binding.py", line 230, in replycomposite
sobject = unmarshaller.process(node, resolved)
File "suds/umx/typed.py", line 66, in process
return Core.process(self, content)
File "suds/umx/core.py", line 48, in process
return self.append(content)
File "suds/umx/core.py", line 63, in append
self.append_children(content)
File "suds/umx/core.py", line 140, in append_children
cval = self.append(cont)
File "suds/umx/core.py", line 61, in append
self.start(content)
File "suds/umx/typed.py", line 80, in start
raise TypeNotFound(content.node.qname())
suds.TypeNotFound: Type not found: 'Include'
vsxconf karl$
On Wed, Nov 16, 2011 at 12:41 PM, Karl Putland <karl(a)klasstek.com> wrote:
> Great!
>
> I'll check it out now.
>
> Thanks,
>
> --Karl
>
>
> On Wed, Nov 16, 2011 at 12:22 PM, Veres-Szentkiralyi Andras <vsza(a)vsza.hu
> > wrote:
>
>> Hi,
>> I created a proof-of-concept patch, that works with the network traffic
>> you
>> sent, and is available in my GitHub repository:
>>
>>
>> https://github.com/dnet/suds/commit/4c930c764d8639c5d808609c756466c3e6070976
>>
>> You can download the single modified file (transport/__init__.py) from
>> the
>> following URL -- if you replace this with the one in your SUDS
>> installation,
>> the example you sent to the mailing list should work.
>>
>>
>>
https://github.com/dnet/suds/raw/4c930c764d8639c5d808609c756466c3e6070976...
>>
>> As you suggested, I put the logic into the Reply class, and the
>> additional
>> methods check for multipart content. If no such content found, normal
>> program
>> flow remains undisturbed, so this shouldn't cause any regressions. The
>> part
>> marked as "start" gets in place of the message, other parts can be
>> accessed
>> using the "parts" member. As it uses the standard email library, even
>> encoded
>> parts (e.g. base64) can be decoded, and it should work on any Python 2.4+
>> install (I tested it on 2.7.2).
>>
>> Let me know, whether it works in real life, I'm interested in the
>> results.
>>
>> Regards,
>> András Veres-Szentkirályi
>>
>> 2011. november 16. szerda 01:07:07 dátummal Karl Putland ezt írta:
>> > Sorry for they delay and thank you for looking.
>> >
>> > Not public.
>> > WSDL attached.
>> > Output from sample script attached.
>> >
>> > >From what I can tell... none of the python libraries are currently
>> >
>> > supporting SOAP-attachments.
>> >
>> >
>> > I added some debugging in SoapClient.send
>> > request.headers = self.headers()
>> > reply = transport.send(request)
>> > if DEBUG:
>> > print '*&'*40
>> > print 'raw reply'
>> > print '*&'*40
>> > print reply
>> > print '*&'*40
>> > ctx = plugins.message.received(reply=reply.message)
>> > reply.message = ctx.reply
>> >
>> > It may be possible to implement in the plugins, but the headers don't
>> pass
>> > through to the plugin... :/
>> > It seems that the best place for the multipart handling is in
>> > transport/http.py in the Reply object. Pass the headers in as
>> HTTPMessage
>> > instead of the Dict to reconstruct the MimeMessage, then if it's
>> > Content-Type: text="text/xml" dump the body as the reply.
otherwise
>> follow
>> > the w3 doc and dump the rootpart ast the reply and create a list of
>> > attachment file-like objects.
>> >
>> > Thanks,
>> >
>> > --Karl
>> >
>> > On Wed, Nov 9, 2011 at 12:15 AM, Veres-Szentkiralyi Andras
>> <vsza(a)vsza.hu>wrote:
>> > > First of all, is this a public service? If so, can you provide a
>> WSDL to
>> > > us?
>> > > If not, can you provide a dump of the request and the response (with
>> > > sensitive
>> > > material stripped if needed)?
>> > >
>> > > Regards,
>> > > András Veres-Szentkirályi
>> > >
>> > > 2011. november 9. szerda 05:33:13 dátummal Karl Putland ezt írta:
>> > > > I'm trying to talk to a service where the SOAP response is
>> returning
>> > > > Content-Type: multipart/related. This behavior is documented here
>> > > >
>> > > > http://www.w3.org/TR/SOAP-attachments
>> > > >
>> > > > All of the current Python SOAP libraries choke on this behavior.
It
>> > > > would be great if suds could handle Content-Type parsing in the
>> > > > transport adapters. I'm having difficulty getting my head
wrapped
>> > > > around all of the urllib2 abstractions in transport/http.py.
>> > > >
>> > > > My best guess is that it needs to happen right before Reply is
>> created,
>> > >
>> > > and
>> > >
>> > > > that Reply needs to have and attachments[] attribute and probably
>> > >
>> > > something
>> > >
>> > > > to represent the file.
>> > > >
>> > > > Thanks,
>> > > >
>> > > > --Karl
>> > >
>> > > _______________________________________________
>> > > suds mailing list
>> > > suds(a)lists.fedoraproject.org
>> > > https://admin.fedoraproject.org/mailman/listinfo/suds
>> _______________________________________________
>> suds mailing list
>> suds(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/suds
>>
>
>
3:21 p.m.
Thanks for the response and the links. Can you produce a packet dump (maybe
with tcpdump or Wireshark) of a ZIP transfer excluding sensitive data?
Regards,
András Veres-Szentkirályi
2011. november 16. szerda 21:28:32 dátummal Karl Putland ezt írta:
So the proof works for the calls that aren't including actual
files but
fails for the calls downloadLargeXMLFile etc... where a zip file is being
expected.
Further investigation into the definitions in the WSDL leads to
documentation on MTOM.
http://metro.java.net/guide/Binary_Attachments__MTOM_.html
http://axis.apache.org/axis2/java/core/docs/mtom-guide.html
I might be ok for the short term with the multipart parsing... It would be
"a good thing" to support MTOM for interoperability and would surely bring
more users to suds.
--Karl
error on doDownlaodLargeXmlFile
Karl-Putlands-MacBook-Pro:vsxconf karl$ python vsxtest.py
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
&*&*& raw reply
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
&*&*& CODE: 200
HEADERS: {'transfer-encoding': 'chunked', 'date': 'Wed, 16
Nov 2011
19:52:03 GMT', 'connection': 'close', 'content-type':
'multipart/related;start="<rootpart*
e64255df-09d9-41db-
be9b-0b5aa8d90d4f(a)example.jaxws.sun.com>";type="applicat
ion/xop+xml";boundary="uuid:e64255df-09d9-41db-be9b-0b5aa8d90d4f";start-inf
o="text/xml"', 'server': 'Apache-Coyote/1.1'}
MESSAGE:
<?xml version="1.0" ?><S:Envelope xmlns:S="
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
&*&*&
**************************************************************************
******
Reply:
<?xml version="1.0" ?><S:Envelope xmlns:S="
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
***************************************************************************
***** No handlers could be found for logger "suds.bindings.multiref"
Traceback (most recent call last):
File "vsxtest.py", line 20, in <module>
result = client.service.doDownloadLargeXmlFile(table="route",
username="xxxxxx", password="xxxxxx")
File "suds/client.py", line 544, in __call__
return client.invoke(args, kwargs)
File "suds/client.py", line 604, in invoke
result = self.send(soapenv)
File "suds/client.py", line 651, in send
result = self.succeeded(binding, reply.message)
File "suds/client.py", line 686, in succeeded
reply, result = binding.get_reply(self.method, reply)
File "suds/bindings/binding.py", line 156, in get_reply
result = self.replycomposite(rtypes, nodes)
File "suds/bindings/binding.py", line 230, in replycomposite
sobject = unmarshaller.process(node, resolved)
File "suds/umx/typed.py", line 66, in process
return Core.process(self, content)
File "suds/umx/core.py", line 48, in process
return self.append(content)
File "suds/umx/core.py", line 63, in append
self.append_children(content)
File "suds/umx/core.py", line 140, in append_children
cval = self.append(cont)
File "suds/umx/core.py", line 61, in append
self.start(content)
File "suds/umx/typed.py", line 80, in start
raise TypeNotFound(content.node.qname())
suds.TypeNotFound: Type not found: 'Include'
vsxconf karl$
On Wed, Nov 16, 2011 at 12:41 PM, Karl Putland <karl(a)klasstek.com> wrote:
> Great!
>
> I'll check it out now.
>
> Thanks,
>
> --Karl
>
> On Wed, Nov 16, 2011 at 12:22 PM, Veres-Szentkiralyi Andras
<vsza(a)vsza.hu>wrote:
>> Hi,
>> I created a proof-of-concept patch, that works with the network traffic
>> you
>> sent, and is available in my GitHub repository:
>>
>>
>> https://github.com/dnet/suds/commit/4c930c764d8639c5d808609c756466c3e607
>> 0976
>>
>> You can download the single modified file (transport/__init__.py) from
>> the following URL -- if you replace this with the one in your SUDS
>> installation,
>> the example you sent to the mailing list should work.
>>
>>
>>
https://github.com/dnet/suds/raw/4c930c764d8639c5d808609c756466c3e607097
>> 6/suds/transport/__init__.py
>>
>> As you suggested, I put the logic into the Reply class, and the
>> additional methods check for multipart content. If no such content
>> found, normal program
>> flow remains undisturbed, so this shouldn't cause any regressions. The
>> part
>> marked as "start" gets in place of the message, other parts can be
>> accessed
>> using the "parts" member. As it uses the standard email library, even
>> encoded
>> parts (e.g. base64) can be decoded, and it should work on any Python
>> 2.4+ install (I tested it on 2.7.2).
>>
>> Let me know, whether it works in real life, I'm interested in the
>> results.
>>
>> Regards,
>> András Veres-Szentkirályi
>>
>> 2011. november 16. szerda 01:07:07 dátummal Karl Putland ezt írta:
>> > Sorry for they delay and thank you for looking.
>> >
>> > Not public.
>> > WSDL attached.
>> > Output from sample script attached.
>> >
>> > >From what I can tell... none of the python libraries are currently
>> >
>> > supporting SOAP-attachments.
>> >
>> >
>> > I added some debugging in SoapClient.send
>> >
>> > request.headers = self.headers()
>> > reply = transport.send(request)
>> >
>> > if DEBUG:
>> > print '*&'*40
>> > print 'raw reply'
>> > print '*&'*40
>> > print reply
>> > print '*&'*40
>> >
>> > ctx = plugins.message.received(reply=reply.message)
>> > reply.message = ctx.reply
>> >
>> > It may be possible to implement in the plugins, but the headers don't
>>
>> pass
>>
>> > through to the plugin... :/
>> > It seems that the best place for the multipart handling is in
>> > transport/http.py in the Reply object. Pass the headers in as
>>
>> HTTPMessage
>>
>> > instead of the Dict to reconstruct the MimeMessage, then if it's
>> > Content-Type: text="text/xml" dump the body as the reply.
otherwise
>>
>> follow
>>
>> > the w3 doc and dump the rootpart ast the reply and create a list of
>> > attachment file-like objects.
>> >
>> > Thanks,
>> >
>> > --Karl
>> >
>> > On Wed, Nov 9, 2011 at 12:15 AM, Veres-Szentkiralyi Andras
>>
>> <vsza(a)vsza.hu>wrote:
>> > > First of all, is this a public service? If so, can you provide a
>> > > WSDL
>>
>> to
>>
>> > > us?
>> > > If not, can you provide a dump of the request and the response (with
>> > > sensitive
>> > > material stripped if needed)?
>> > >
>> > > Regards,
>> > > András Veres-Szentkirályi
>> > >
>> > > 2011. november 9. szerda 05:33:13 dátummal Karl Putland ezt írta:
>> > > > I'm trying to talk to a service where the SOAP response is
>> > > > returning Content-Type: multipart/related. This behavior is
>> > > > documented here
>> > > >
>> > > > http://www.w3.org/TR/SOAP-attachments
>> > > >
>> > > > All of the current Python SOAP libraries choke on this behavior.
>> > > > It would be great if suds could handle Content-Type parsing in
>> > > > the transport adapters. I'm having difficulty getting my
head
>> > > > wrapped around all of the urllib2 abstractions in
>> > > > transport/http.py.
>> > > >
>> > > > My best guess is that it needs to happen right before Reply is
>>
>> created,
>>
>> > > and
>> > >
>> > > > that Reply needs to have and attachments[] attribute and
probably
>> > >
>> > > something
>> > >
>> > > > to represent the file.
>> > > >
>> > > > Thanks,
>> > > >
>> > > > --Karl
>> > >
>> > > _______________________________________________
>> > > suds mailing list
>> > > suds(a)lists.fedoraproject.org
>> > > https://admin.fedoraproject.org/mailman/listinfo/suds
>>
>> _______________________________________________
>> suds mailing list
>> suds(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/suds
10:33 a.m.
Can't get a useful packet dump as the service is using ssl.
--Karl
On Wed, Nov 16, 2011 at 2:21 PM, Veres-Szentkiralyi Andras <vsza(a)vsza.hu>wrote:
Thanks for the response and the links. Can you produce a packet dump
(maybe
with tcpdump or Wireshark) of a ZIP transfer excluding sensitive data?
Regards,
András Veres-Szentkirályi
2011. november 16. szerda 21:28:32 dátummal Karl Putland ezt írta:
> So the proof works for the calls that aren't including actual files but
> fails for the calls downloadLargeXMLFile etc... where a zip file is being
> expected.
> Further investigation into the definitions in the WSDL leads to
> documentation on MTOM.
>
> http://metro.java.net/guide/Binary_Attachments__MTOM_.html
> http://axis.apache.org/axis2/java/core/docs/mtom-guide.html
>
> I might be ok for the short term with the multipart parsing... It would
be
> "a good thing" to support MTOM for interoperability and would surely
bring
> more users to suds.
>
> --Karl
>
>
> error on doDownlaodLargeXmlFile
>
> Karl-Putlands-MacBook-Pro:vsxconf karl$ python vsxtest.py
>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
> &*&*& raw reply
>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
> &*&*& CODE: 200
> HEADERS: {'transfer-encoding': 'chunked', 'date': 'Wed,
16 Nov 2011
> 19:52:03 GMT', 'connection': 'close', 'content-type':
> 'multipart/related;start="<rootpart*
> e64255df-09d9-41db-
be9b-0b5aa8d90d4f(a)example.jaxws.sun.com>";type="applicat
>
ion/xop+xml";boundary="uuid:e64255df-09d9-41db-be9b-0b5aa8d90d4f";start-inf
> o="text/xml"', 'server': 'Apache-Coyote/1.1'}
> MESSAGE:
> <?xml version="1.0" ?><S:Envelope xmlns:S="
>
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
>
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
> OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
> href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
>
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
> &*&*&
>
**************************************************************************
> ******
>
> Reply:
> <?xml version="1.0" ?><S:Envelope xmlns:S="
>
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
>
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
> OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
> href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
>
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
>
***************************************************************************
> ***** No handlers could be found for logger "suds.bindings.multiref"
> Traceback (most recent call last):
> File "vsxtest.py", line 20, in <module>
> result = client.service.doDownloadLargeXmlFile(table="route",
> username="xxxxxx", password="xxxxxx")
> File "suds/client.py", line 544, in __call__
> return client.invoke(args, kwargs)
> File "suds/client.py", line 604, in invoke
> result = self.send(soapenv)
> File "suds/client.py", line 651, in send
> result = self.succeeded(binding, reply.message)
> File "suds/client.py", line 686, in succeeded
> reply, result = binding.get_reply(self.method, reply)
> File "suds/bindings/binding.py", line 156, in get_reply
> result = self.replycomposite(rtypes, nodes)
> File "suds/bindings/binding.py", line 230, in replycomposite
> sobject = unmarshaller.process(node, resolved)
> File "suds/umx/typed.py", line 66, in process
> return Core.process(self, content)
> File "suds/umx/core.py", line 48, in process
> return self.append(content)
> File "suds/umx/core.py", line 63, in append
> self.append_children(content)
> File "suds/umx/core.py", line 140, in append_children
> cval = self.append(cont)
> File "suds/umx/core.py", line 61, in append
> self.start(content)
> File "suds/umx/typed.py", line 80, in start
> raise TypeNotFound(content.node.qname())
> suds.TypeNotFound: Type not found: 'Include'
> vsxconf karl$
>
> On Wed, Nov 16, 2011 at 12:41 PM, Karl Putland <karl(a)klasstek.com>
wrote:
> > Great!
> >
> > I'll check it out now.
> >
> > Thanks,
> >
> > --Karl
> >
> > On Wed, Nov 16, 2011 at 12:22 PM, Veres-Szentkiralyi Andras
<vsza(a)vsza.hu>wrote:
> >> Hi,
> >> I created a proof-of-concept patch, that works with the network
traffic
> >> you
> >> sent, and is available in my GitHub repository:
> >>
> >>
> >>
https://github.com/dnet/suds/commit/4c930c764d8639c5d808609c756466c3e607
> >> 0976
> >>
> >> You can download the single modified file (transport/__init__.py) from
> >> the following URL -- if you replace this with the one in your SUDS
> >> installation,
> >> the example you sent to the mailing list should work.
> >>
> >>
> >>
https://github.com/dnet/suds/raw/4c930c764d8639c5d808609c756466c3e607097
> >> 6/suds/transport/__init__.py
> >>
> >> As you suggested, I put the logic into the Reply class, and the
> >> additional methods check for multipart content. If no such content
> >> found, normal program
> >> flow remains undisturbed, so this shouldn't cause any regressions. The
> >> part
> >> marked as "start" gets in place of the message, other parts can
be
> >> accessed
> >> using the "parts" member. As it uses the standard email library,
even
> >> encoded
> >> parts (e.g. base64) can be decoded, and it should work on any Python
> >> 2.4+ install (I tested it on 2.7.2).
> >>
> >> Let me know, whether it works in real life, I'm interested in the
> >> results.
> >>
> >> Regards,
> >> András Veres-Szentkirályi
> >>
> >> 2011. november 16. szerda 01:07:07 dátummal Karl Putland ezt írta:
> >> > Sorry for they delay and thank you for looking.
> >> >
> >> > Not public.
> >> > WSDL attached.
> >> > Output from sample script attached.
> >> >
> >> > >From what I can tell... none of the python libraries are
currently
> >> >
> >> > supporting SOAP-attachments.
> >> >
> >> >
> >> > I added some debugging in SoapClient.send
> >> >
> >> > request.headers = self.headers()
> >> > reply = transport.send(request)
> >> >
> >> > if DEBUG:
> >> > print '*&'*40
> >> > print 'raw reply'
> >> > print '*&'*40
> >> > print reply
> >> > print '*&'*40
> >> >
> >> > ctx = plugins.message.received(reply=reply.message)
> >> > reply.message = ctx.reply
> >> >
> >> > It may be possible to implement in the plugins, but the headers
don't
> >>
> >> pass
> >>
> >> > through to the plugin... :/
> >> > It seems that the best place for the multipart handling is in
> >> > transport/http.py in the Reply object. Pass the headers in as
> >>
> >> HTTPMessage
> >>
> >> > instead of the Dict to reconstruct the MimeMessage, then if it's
> >> > Content-Type: text="text/xml" dump the body as the reply.
otherwise
> >>
> >> follow
> >>
> >> > the w3 doc and dump the rootpart ast the reply and create a list of
> >> > attachment file-like objects.
> >> >
> >> > Thanks,
> >> >
> >> > --Karl
> >> >
> >> > On Wed, Nov 9, 2011 at 12:15 AM, Veres-Szentkiralyi Andras
> >>
> >> <vsza(a)vsza.hu>wrote:
> >> > > First of all, is this a public service? If so, can you provide a
> >> > > WSDL
> >>
> >> to
> >>
> >> > > us?
> >> > > If not, can you provide a dump of the request and the response
(with
> >> > > sensitive
> >> > > material stripped if needed)?
> >> > >
> >> > > Regards,
> >> > > András Veres-Szentkirályi
> >> > >
> >> > > 2011. november 9. szerda 05:33:13 dátummal Karl Putland ezt
írta:
> >> > > > I'm trying to talk to a service where the SOAP response
is
> >> > > > returning Content-Type: multipart/related. This behavior is
> >> > > > documented here
> >> > > >
> >> > > > http://www.w3.org/TR/SOAP-attachments
> >> > > >
> >> > > > All of the current Python SOAP libraries choke on this
behavior.
> >> > > > It would be great if suds could handle Content-Type parsing
in
> >> > > > the transport adapters. I'm having difficulty getting my
head
> >> > > > wrapped around all of the urllib2 abstractions in
> >> > > > transport/http.py.
> >> > > >
> >> > > > My best guess is that it needs to happen right before Reply
is
> >>
> >> created,
> >>
> >> > > and
> >> > >
> >> > > > that Reply needs to have and attachments[] attribute and
probably
> >> > >
> >> > > something
> >> > >
> >> > > > to represent the file.
> >> > > >
> >> > > > Thanks,
> >> > > >
> >> > > > --Karl
> >> > >
> >> > > _______________________________________________
> >> > > suds mailing list
> >> > > suds(a)lists.fedoraproject.org
> >> > > https://admin.fedoraproject.org/mailman/listinfo/suds
> >>
> >> _______________________________________________
> >> suds mailing list
> >> suds(a)lists.fedoraproject.org
> >> https://admin.fedoraproject.org/mailman/listinfo/suds
_______________________________________________
suds mailing list
suds(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/suds
11:48 a.m.
If you have access to the private key, you can decrypt the SSL/TLS stream
using Wireshark: http://wiki.wireshark.org/SSL
Regards,
András Veres-Szentkirályi
2011. november 21. hétfő 17:33:46 dátummal Karl Putland ezt írta:
Can't get a useful packet dump as the service is using ssl.
--Karl
On Wed, Nov 16, 2011 at 2:21 PM, Veres-Szentkiralyi Andras
<vsza(a)vsza.hu>wrote:
> Thanks for the response and the links. Can you produce a packet
dump
> (maybe with tcpdump or Wireshark) of a ZIP transfer excluding sensitive
> data?
>
> Regards,
> András Veres-Szentkirályi
>
> 2011. november 16. szerda 21:28:32 dátummal Karl Putland ezt írta:
> > So the proof works for the calls that aren't including actual files but
> > fails for the calls downloadLargeXMLFile etc... where a zip file is
> > being expected.
> > Further investigation into the definitions in the WSDL leads to
> > documentation on MTOM.
> >
> > http://metro.java.net/guide/Binary_Attachments__MTOM_.html
> > http://axis.apache.org/axis2/java/core/docs/mtom-guide.html
> >
> > I might be ok for the short term with the multipart parsing... It would
>
> be
>
> > "a good thing" to support MTOM for interoperability and would surely
>
> bring
>
> > more users to suds.
> >
> > --Karl
> >
> >
> > error on doDownlaodLargeXmlFile
> >
> > Karl-Putlands-MacBook-Pro:vsxconf karl$ python vsxtest.py
>
>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
> &*
>
> > &*&*& raw reply
>
>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
> &*
>
> > &*&*& CODE: 200
> > HEADERS: {'transfer-encoding': 'chunked', 'date':
'Wed, 16 Nov 2011
> > 19:52:03 GMT', 'connection': 'close',
'content-type':
> > 'multipart/related;start="<rootpart*
> > e64255df-09d9-41db-
>
> be9b-0b5aa8d90d4f(a)example.jaxws.sun.com>";type="applicat
>
>
ion/xop+xml";boundary="uuid:e64255df-09d9-41db-be9b-0b5aa8d90d4f";start-i
> nf
>
> > o="text/xml"', 'server': 'Apache-Coyote/1.1'}
> > MESSAGE:
> > <?xml version="1.0" ?><S:Envelope xmlns:S="
> >
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
> >
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
> > OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
> > href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
> >
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
>
>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
> &*
>
> > &*&*&
>
> *************************************************************************
> *
>
> > ******
> >
> > Reply:
> > <?xml version="1.0" ?><S:Envelope xmlns:S="
> >
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
> >
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
> > OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
> > href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
> >
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
>
> *************************************************************************
> **
>
> > ***** No handlers could be found for logger "suds.bindings.multiref"
> >
> > Traceback (most recent call last):
> > File "vsxtest.py", line 20, in <module>
> >
> > result = client.service.doDownloadLargeXmlFile(table="route",
> >
> > username="xxxxxx", password="xxxxxx")
> >
> > File "suds/client.py", line 544, in __call__
> >
> > return client.invoke(args, kwargs)
> >
> > File "suds/client.py", line 604, in invoke
> >
> > result = self.send(soapenv)
> >
> > File "suds/client.py", line 651, in send
> >
> > result = self.succeeded(binding, reply.message)
> >
> > File "suds/client.py", line 686, in succeeded
> >
> > reply, result = binding.get_reply(self.method, reply)
> >
> > File "suds/bindings/binding.py", line 156, in get_reply
> >
> > result = self.replycomposite(rtypes, nodes)
> >
> > File "suds/bindings/binding.py", line 230, in replycomposite
> >
> > sobject = unmarshaller.process(node, resolved)
> >
> > File "suds/umx/typed.py", line 66, in process
> >
> > return Core.process(self, content)
> >
> > File "suds/umx/core.py", line 48, in process
> >
> > return self.append(content)
> >
> > File "suds/umx/core.py", line 63, in append
> >
> > self.append_children(content)
> >
> > File "suds/umx/core.py", line 140, in append_children
> >
> > cval = self.append(cont)
> >
> > File "suds/umx/core.py", line 61, in append
> >
> > self.start(content)
> >
> > File "suds/umx/typed.py", line 80, in start
> >
> > raise TypeNotFound(content.node.qname())
> >
> > suds.TypeNotFound: Type not found: 'Include'
> > vsxconf karl$
> >
> > On Wed, Nov 16, 2011 at 12:41 PM, Karl Putland <karl(a)klasstek.com>
>
> wrote:
> > > Great!
> > >
> > > I'll check it out now.
> > >
> > > Thanks,
> > >
> > > --Karl
> > >
> > > On Wed, Nov 16, 2011 at 12:22 PM, Veres-Szentkiralyi Andras
>
> <vsza(a)vsza.hu>wrote:
> > >> Hi,
> > >> I created a proof-of-concept patch, that works with the network
>
> traffic
>
> > >> you
>
> > >> sent, and is available in my GitHub repository:
> https://github.com/dnet/suds/commit/4c930c764d8639c5d808609c756466c3e607
>
> > >> 0976
> > >>
> > >> You can download the single modified file (transport/__init__.py)
> > >> from the following URL -- if you replace this with the one in your
> > >> SUDS installation,
> > >> the example you sent to the mailing list should work.
>
> https://github.com/dnet/suds/raw/4c930c764d8639c5d808609c756466c3e607097
>
> > >> 6/suds/transport/__init__.py
> > >>
> > >> As you suggested, I put the logic into the Reply class, and the
> > >> additional methods check for multipart content. If no such content
> > >> found, normal program
> > >> flow remains undisturbed, so this shouldn't cause any
regressions.
> > >> The part
> > >> marked as "start" gets in place of the message, other parts
can be
> > >> accessed
> > >> using the "parts" member. As it uses the standard email
library,
> > >> even encoded
> > >> parts (e.g. base64) can be decoded, and it should work on any Python
> > >> 2.4+ install (I tested it on 2.7.2).
> > >>
> > >> Let me know, whether it works in real life, I'm interested in the
> > >> results.
> > >>
> > >> Regards,
> > >> András Veres-Szentkirályi
> > >>
> > >> 2011. november 16. szerda 01:07:07 dátummal Karl Putland ezt írta:
> > >> > Sorry for they delay and thank you for looking.
> > >> >
> > >> > Not public.
> > >> > WSDL attached.
> > >> > Output from sample script attached.
> > >> >
> > >> > >From what I can tell... none of the python libraries are
> > >> > >currently
> > >> >
> > >> > supporting SOAP-attachments.
> > >> >
> > >> >
> > >> > I added some debugging in SoapClient.send
> > >> >
> > >> > request.headers = self.headers()
> > >> > reply = transport.send(request)
> > >> >
> > >> > if DEBUG:
> > >> > print '*&'*40
> > >> > print 'raw reply'
> > >> > print '*&'*40
> > >> > print reply
> > >> > print '*&'*40
> > >> >
> > >> > ctx = plugins.message.received(reply=reply.message)
> > >> > reply.message = ctx.reply
> > >> >
> > >> > It may be possible to implement in the plugins, but the headers
>
> don't
>
> > >> pass
> > >>
> > >> > through to the plugin... :/
> > >> > It seems that the best place for the multipart handling is in
> > >> > transport/http.py in the Reply object. Pass the headers in as
> > >>
> > >> HTTPMessage
> > >>
> > >> > instead of the Dict to reconstruct the MimeMessage, then if
it's
> > >> > Content-Type: text="text/xml" dump the body as the
reply.
> > >> > otherwise
> > >>
> > >> follow
> > >>
> > >> > the w3 doc and dump the rootpart ast the reply and create a list
> > >> > of attachment file-like objects.
> > >> >
> > >> > Thanks,
> > >> >
> > >> > --Karl
> > >> >
> > >> > On Wed, Nov 9, 2011 at 12:15 AM, Veres-Szentkiralyi Andras
> > >>
> > >> <vsza(a)vsza.hu>wrote:
> > >> > > First of all, is this a public service? If so, can you
provide a
> > >> > > WSDL
> > >>
> > >> to
> > >>
> > >> > > us?
> > >> > > If not, can you provide a dump of the request and the
response
>
> (with
>
> > >> > > sensitive
> > >> > > material stripped if needed)?
> > >> > >
> > >> > > Regards,
> > >> > > András Veres-Szentkirályi
> > >> > >
> > >> > > 2011. november 9. szerda 05:33:13 dátummal Karl Putland ezt
írta:
> > >> > > > I'm trying to talk to a service where the SOAP
response is
> > >> > > > returning Content-Type: multipart/related. This
behavior is
> > >> > > > documented here
> > >> > > >
> > >> > > > http://www.w3.org/TR/SOAP-attachments
> > >> > > >
> > >> > > > All of the current Python SOAP libraries choke on this
> > >> > > > behavior. It would be great if suds could handle
Content-Type
> > >> > > > parsing in the transport adapters. I'm having
difficulty
> > >> > > > getting my head wrapped around all of the urllib2
> > >> > > > abstractions in
> > >> > > > transport/http.py.
> > >> > > >
> > >> > > > My best guess is that it needs to happen right before
Reply is
> > >>
> > >> created,
> > >>
> > >> > > and
> > >> > >
> > >> > > > that Reply needs to have and attachments[] attribute
and
>
> probably
>
> > >> > > something
> > >> > >
> > >> > > > to represent the file.
> > >> > > >
> > >> > > > Thanks,
> > >> > > >
> > >> > > > --Karl
> > >> > >
> > >> > > _______________________________________________
> > >> > > suds mailing list
> > >> > > suds(a)lists.fedoraproject.org
> > >> > > https://admin.fedoraproject.org/mailman/listinfo/suds
> > >>
> > >> _______________________________________________
> > >> suds mailing list
> > >> suds(a)lists.fedoraproject.org
> > >> https://admin.fedoraproject.org/mailman/listinfo/suds
>
> _______________________________________________
> suds mailing list
> suds(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/suds
1:03 p.m.
I believe there's also a Linux package called 'ssldump' that doesn't
require the server key.
--Alex
On Nov 21, 2011, at 9:48 AM, Veres-Szentkiralyi Andras <vsza(a)vsza.hu> wrote:
If you have access to the private key, you can decrypt the SSL/TLS
stream
using Wireshark: http://wiki.wireshark.org/SSL
Regards,
András Veres-Szentkirályi
2011. november 21. hétfő 17:33:46 dátummal Karl Putland ezt írta:
> Can't get a useful packet dump as the service is using ssl.
>
> --Karl
>
> On Wed, Nov 16, 2011 at 2:21 PM, Veres-Szentkiralyi Andras
<vsza(a)vsza.hu>wrote:
>> Thanks for the response and the links. Can you produce a packet dump
>> (maybe with tcpdump or Wireshark) of a ZIP transfer excluding sensitive
>> data?
>>
>> Regards,
>> András Veres-Szentkirályi
>>
>> 2011. november 16. szerda 21:28:32 dátummal Karl Putland ezt írta:
>>> So the proof works for the calls that aren't including actual files but
>>> fails for the calls downloadLargeXMLFile etc... where a zip file is
>>> being expected.
>>> Further investigation into the definitions in the WSDL leads to
>>> documentation on MTOM.
>>>
>>> http://metro.java.net/guide/Binary_Attachments__MTOM_.html
>>> http://axis.apache.org/axis2/java/core/docs/mtom-guide.html
>>>
>>> I might be ok for the short term with the multipart parsing... It would
>>
>> be
>>
>>> "a good thing" to support MTOM for interoperability and would
surely
>>
>> bring
>>
>>> more users to suds.
>>>
>>> --Karl
>>>
>>>
>>> error on doDownlaodLargeXmlFile
>>>
>>> Karl-Putlands-MacBook-Pro:vsxconf karl$ python vsxtest.py
>>
>>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
>> &*
>>
>>> &*&*& raw reply
>>
>>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
>> &*
>>
>>> &*&*& CODE: 200
>>> HEADERS: {'transfer-encoding': 'chunked', 'date':
'Wed, 16 Nov 2011
>>> 19:52:03 GMT', 'connection': 'close',
'content-type':
>>> 'multipart/related;start="<rootpart*
>>> e64255df-09d9-41db-
>>
>> be9b-0b5aa8d90d4f(a)example.jaxws.sun.com>";type="applicat
>>
>>
ion/xop+xml";boundary="uuid:e64255df-09d9-41db-be9b-0b5aa8d90d4f";start-i
>> nf
>>
>>> o="text/xml"', 'server': 'Apache-Coyote/1.1'}
>>> MESSAGE:
>>> <?xml version="1.0" ?><S:Envelope xmlns:S="
>>>
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
>>>
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
>>> OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
>>> href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
>>>
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
>>
>>
*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*&*
>> &*
>>
>>> &*&*&
>>
>> *************************************************************************
>> *
>>
>>> ******
>>>
>>> Reply:
>>> <?xml version="1.0" ?><S:Envelope xmlns:S="
>>>
http://schemas.xmlsoap.org/soap/envelope/"><S:Body><down...
>>>
xmlns="http://ws.sansay.com"><retCode>200</retCode><msg>200
>>> OK</msg><binfile><Include
xmlns="http://www.w3.org/2004/08/xop/include"
>>> href="cid:d13ecec6-f10c-40be-941d-50288e41f0d4@example.jaxws.sun.com
>>>
"/></binfile></downloadLargeResult></S:Body></S:Envelope>
>>
>> *************************************************************************
>> **
>>
>>> ***** No handlers could be found for logger
"suds.bindings.multiref"
>>>
>>> Traceback (most recent call last):
>>> File "vsxtest.py", line 20, in <module>
>>>
>>> result = client.service.doDownloadLargeXmlFile(table="route",
>>>
>>> username="xxxxxx", password="xxxxxx")
>>>
>>> File "suds/client.py", line 544, in __call__
>>>
>>> return client.invoke(args, kwargs)
>>>
>>> File "suds/client.py", line 604, in invoke
>>>
>>> result = self.send(soapenv)
>>>
>>> File "suds/client.py", line 651, in send
>>>
>>> result = self.succeeded(binding, reply.message)
>>>
>>> File "suds/client.py", line 686, in succeeded
>>>
>>> reply, result = binding.get_reply(self.method, reply)
>>>
>>> File "suds/bindings/binding.py", line 156, in get_reply
>>>
>>> result = self.replycomposite(rtypes, nodes)
>>>
>>> File "suds/bindings/binding.py", line 230, in replycomposite
>>>
>>> sobject = unmarshaller.process(node, resolved)
>>>
>>> File "suds/umx/typed.py", line 66, in process
>>>
>>> return Core.process(self, content)
>>>
>>> File "suds/umx/core.py", line 48, in process
>>>
>>> return self.append(content)
>>>
>>> File "suds/umx/core.py", line 63, in append
>>>
>>> self.append_children(content)
>>>
>>> File "suds/umx/core.py", line 140, in append_children
>>>
>>> cval = self.append(cont)
>>>
>>> File "suds/umx/core.py", line 61, in append
>>>
>>> self.start(content)
>>>
>>> File "suds/umx/typed.py", line 80, in start
>>>
>>> raise TypeNotFound(content.node.qname())
>>>
>>> suds.TypeNotFound: Type not found: 'Include'
>>> vsxconf karl$
>>>
>>> On Wed, Nov 16, 2011 at 12:41 PM, Karl Putland <karl(a)klasstek.com>
>>
>> wrote:
>>>> Great!
>>>>
>>>> I'll check it out now.
>>>>
>>>> Thanks,
>>>>
>>>> --Karl
>>>>
>>>> On Wed, Nov 16, 2011 at 12:22 PM, Veres-Szentkiralyi Andras
>>
>> <vsza(a)vsza.hu>wrote:
>>>>> Hi,
>>>>> I created a proof-of-concept patch, that works with the network
>>
>> traffic
>>
>>>>> you
>>
>>>>> sent, and is available in my GitHub repository:
>> https://github.com/dnet/suds/commit/4c930c764d8639c5d808609c756466c3e607
>>
>>>>> 0976
>>>>>
>>>>> You can download the single modified file (transport/__init__.py)
>>>>> from the following URL -- if you replace this with the one in your
>>>>> SUDS installation,
>>>>> the example you sent to the mailing list should work.
>>
>> https://github.com/dnet/suds/raw/4c930c764d8639c5d808609c756466c3e607097
>>
>>>>> 6/suds/transport/__init__.py
>>>>>
>>>>> As you suggested, I put the logic into the Reply class, and the
>>>>> additional methods check for multipart content. If no such content
>>>>> found, normal program
>>>>> flow remains undisturbed, so this shouldn't cause any
regressions.
>>>>> The part
>>>>> marked as "start" gets in place of the message, other parts
can be
>>>>> accessed
>>>>> using the "parts" member. As it uses the standard email
library,
>>>>> even encoded
>>>>> parts (e.g. base64) can be decoded, and it should work on any Python
>>>>> 2.4+ install (I tested it on 2.7.2).
>>>>>
>>>>> Let me know, whether it works in real life, I'm interested in
the
>>>>> results.
>>>>>
>>>>> Regards,
>>>>> András Veres-Szentkirályi
>>>>>
>>>>> 2011. november 16. szerda 01:07:07 dátummal Karl Putland ezt írta:
>>>>>> Sorry for they delay and thank you for looking.
>>>>>>
>>>>>> Not public.
>>>>>> WSDL attached.
>>>>>> Output from sample script attached.
>>>>>>
>>>>>>> From what I can tell... none of the python libraries are
>>>>>>> currently
>>>>>>
>>>>>> supporting SOAP-attachments.
>>>>>>
>>>>>>
>>>>>> I added some debugging in SoapClient.send
>>>>>>
>>>>>> request.headers = self.headers()
>>>>>> reply = transport.send(request)
>>>>>>
>>>>>> if DEBUG:
>>>>>> print '*&'*40
>>>>>> print 'raw reply'
>>>>>> print '*&'*40
>>>>>> print reply
>>>>>> print '*&'*40
>>>>>>
>>>>>> ctx = plugins.message.received(reply=reply.message)
>>>>>> reply.message = ctx.reply
>>>>>>
>>>>>> It may be possible to implement in the plugins, but the headers
>>
>> don't
>>
>>>>> pass
>>>>>
>>>>>> through to the plugin... :/
>>>>>> It seems that the best place for the multipart handling is in
>>>>>> transport/http.py in the Reply object. Pass the headers in as
>>>>>
>>>>> HTTPMessage
>>>>>
>>>>>> instead of the Dict to reconstruct the MimeMessage, then if
it's
>>>>>> Content-Type: text="text/xml" dump the body as the
reply.
>>>>>> otherwise
>>>>>
>>>>> follow
>>>>>
>>>>>> the w3 doc and dump the rootpart ast the reply and create a list
>>>>>> of attachment file-like objects.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> --Karl
>>>>>>
>>>>>> On Wed, Nov 9, 2011 at 12:15 AM, Veres-Szentkiralyi Andras
>>>>>
>>>>> <vsza(a)vsza.hu>wrote:
>>>>>>> First of all, is this a public service? If so, can you
provide a
>>>>>>> WSDL
>>>>>
>>>>> to
>>>>>
>>>>>>> us?
>>>>>>> If not, can you provide a dump of the request and the
response
>>
>> (with
>>
>>>>>>> sensitive
>>>>>>> material stripped if needed)?
>>>>>>>
>>>>>>> Regards,
>>>>>>> András Veres-Szentkirályi
>>>>>>>
>>>>>>> 2011. november 9. szerda 05:33:13 dátummal Karl Putland ezt
írta:
>>>>>>>> I'm trying to talk to a service where the SOAP
response is
>>>>>>>> returning Content-Type: multipart/related. This behavior
is
>>>>>>>> documented here
>>>>>>>>
>>>>>>>> http://www.w3.org/TR/SOAP-attachments
>>>>>>>>
>>>>>>>> All of the current Python SOAP libraries choke on this
>>>>>>>> behavior. It would be great if suds could handle
Content-Type
>>>>>>>> parsing in the transport adapters. I'm having
difficulty
>>>>>>>> getting my head wrapped around all of the urllib2
>>>>>>>> abstractions in
>>>>>>>> transport/http.py.
>>>>>>>>
>>>>>>>> My best guess is that it needs to happen right before
Reply is
>>>>>
>>>>> created,
>>>>>
>>>>>>> and
>>>>>>>
>>>>>>>> that Reply needs to have and attachments[] attribute and
>>
>> probably
>>
>>>>>>> something
>>>>>>>
>>>>>>>> to represent the file.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> --Karl
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> suds mailing list
>>>>>>> suds(a)lists.fedoraproject.org
>>>>>>> https://admin.fedoraproject.org/mailman/listinfo/suds
>>>>>
>>>>> _______________________________________________
>>>>> suds mailing list
>>>>> suds(a)lists.fedoraproject.org
>>>>> https://admin.fedoraproject.org/mailman/listinfo/suds
>>
>> _______________________________________________
>> suds mailing list
>> suds(a)lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/suds
_______________________________________________
suds mailing list
suds(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/suds
4548
days inactive
4560
days old
10 comments
3 participants
participants (3)
-
Alex Gottschalk -
Karl Putland -
Veres-Szentkiralyi Andras