We're facing the same issue with suds & soaplib..
we've ended up with a solution that we're using FileCache for suds so after implementing caching suds side, we're facing BadStatusLine problem very rarely...
On Wed, Dec 7, 2011 at 1:32 PM, Dieter Maurer dieter@handshake.de wrote:
贾晓磊 wrote at 2011-12-7 15:38 +0800:
... 1:By the url " http://webservice.webxml.com.cn/WebServices/WeatherWS.asmx?wsdl" , we can get the words :
<wsdl:definitions xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tm="http://microsoft.com/wsdl/mime/textMatching/%22xmlns:soapenc=" http://schemas.xmlsoap.org/soap/encoding/" xmlns:mime=" http://schemas.xmlsoap.org/wsdl/mime/" xmlns:tns="http://WebXml.com.cn/" xmlns:s="http://www.w3.org/2001/XMLSchema" xmlns:soap12=*" http://schemas.xmlsoap.org/wsdl/soap12/*%22xmlns:http=" http://schemas.xmlsoap.org/wsdl/http/" xmlns:wsdl=" http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://WebXml.com.cn/
">
<wsdl:documentation xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/%22%3E
Maybe it's the fault of soap1.2
This tells us (only), that namespace prefixes are defined for both "SOAP" (1.1) as well as "SOAP1.2".
The WSDL may define two different ports, one destined for "SOAP" clients another one for "SOAP1.2" clients. In such a case, ensure that "suds" is using the port for "SOAP" clients.
The "suds" documentation tells you how to specify the use of a specific port.
In the cases, where I have seen different ports for "SOAP" and "SOAP1.2" in a WSDL, the port name has distinguished between the two protocols. I have not seen a more formal difference (but I may not have looked with sufficient intensity).
2: I once did a webservice server-side using suds. Most of time, they work together well. While, sometimes, suds returns some message like the exception mentioned above. If idle, wish you have a look and give me some points. Thanks in advance.
I am not idle ;-)
#NOTE: the code can also be found in " http://soaplib.github.com/soaplib/2_0/pages/helloworld.html" ... Sometimes, it returns exceptions as follows. most of time it return the result successfully after 2 or 3 minutes
Traceback (most recent call last): ... File "/usr/lib/python2.6/httplib.py", line 391, in begin version, status, reason = self._read_status() File "/usr/lib/python2.6/httplib.py", line 355, in _read_status raise BadStatusLine(line)
# okay, the problem is why sometimes the client return the exception and most of time return the correct results some minutes later?
When it works sometimes, this excludes a WSDL problem.
Nethertheless, the problem does not look client side -- but server side. You are getting a very low level exception: "httplib" (responsible for the elementary http request/response exchange) complaining about a bad status line (the first line of an HTTP response). The error information (the other part, aside from the traceback) should tell you which "line" has been received. You will find that it does not correspond to the HTTP specification.
To understand in details what happens between a client and a server, a TCP logger (e.g. "etherreal", "wireshark", ...) can be used. It protocols the communication between server and client and you can see precisely which side is responsible for bad behavior.
-- Dieter _______________________________________________ Soap mailing list Soap@python.org http://mail.python.org/mailman/listinfo/soap