HTTP transport separation

[GoogleCodeExporter]

Thank you Mariano for this library. I have made small tests with it and the 
speed is incredible (in comparison with suds)

Let me suggest, as suds does, that it would be a good idea to completely 
separate the "transport" from the generation and parsing of SOAP messages.

Right now (at least in the client) there is urllib, urllib2 and httplib2 code 
mixed with the SOAP parts. And the proxy parameter seems to be too tightly 
coupled to httplib2 where it should be more generic.

Additionally the URL will fail to be fetched if the client has to do that over 
a proxy.

A transport abstraction would allow any HTTP library (httplib2, urllib2 or 
others like my own httxlib) to be plugged in and keep the network code separate 
from the SOAP code.

I am playing a bit around with the sources and will attach an update to this 
"Enhancement Request" for your consideration.

Once again thank you and best regards

Original issue reported on code.google.com by danj...@gmail.com on 5 Aug 2011 at 12:10

[GoogleCodeExporter]

That would be nice if we can get the HTTP code out of the client, but think 
that there could be legacy code around (I have a lot of that), so some backward 
compatible interface is needed.

Allan Croock did some reorganization in revision fa2b83a02f69

BTW, I'm thinking of adding support to urrlib3, as it seem more capable than 
httplib2 (regarding proxy and ssl verification support), your library is better?

Original comment by reingart@gmail.com on 5 Aug 2011 at 2:43

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

I don't know (should I be the judge?) if my own httxlib is better than httplib2 
and/or urllib3. At the time I looked at both they were missing important things 
(urllib3 seemed to be abandoned and it was just and embryo) and that's why I 
went to create something different.

Some things have changed but except for the "caching" functionality I 
personally don't like httplib2 and urllib3 seems still an experiment.

Nevertheless, the separation of "network" code in your library should allow 
anyone to use whatever library. I have had a look at the change from Allan, but 
in my opinion the first thing to do is to take the HTTP code out of the 
client.py file and not increase the entropy of the client.py.

Moreover, users should be able to plug their own version of a "transport" if 
they wish so. And fetching the wdsl over a proxy would still fail with those 
changes, which is obviously not desired.

I will come back with a proposal.

Best regards

Original comment by danj...@gmail.com on 8 Aug 2011 at 9:30

[GoogleCodeExporter]

Further on the changes from Allan I fail to understand why a missing 
functionality has to raise an Exception and urllib2 (no matter if I don't like 
it) has full proxy  and timeout support.

Original comment by danj...@gmail.com on 9 Aug 2011 at 7:39

[GoogleCodeExporter]

Now Http is more sparated in transport.py, and now wsdl fetch uses the http 
wrapper.

Please feel free to suggest any further change, your httxlib seems promising.

Original comment by reingart@gmail.com on 8 Jan 2012 at 1:03

[GoogleCodeExporter]

danjrod - I was working in a Python 2.5 environment, and urllib2 didn't support 
socket timeouts in that version, which is why I wrote the code that way. I'm 
now working in a Python 2.6 environment, and I've got a commit which will now 
properly accept the socket timeout value.

The reason why we raise an exception (and not just ignore the value) is because 
I thought it was better for client code to know immediately that the behaviour 
that they are expecting will not work (rather than wondering why something 
which they expect to work doesn't appear to). They can manually then set a 
compatible transport before they use the class.

Original comment by allan.cr...@yougov.com on 11 Jan 2012 at 4:23

[GoogleCodeExporter]

I think this is already commited, this library now supports currently multiple 
transports (including urllib, httplib2, pycurl, etc. IIRC), they are separated 
in transports.py and so on.

Please attach a patch if you need a new transport.
Thanks everyone for the contributions

Original comment by reingart@gmail.com on 22 Jan 2014 at 2:27

• Changed state: Fixed