curl-library
transfer closed with outstanding read data remaining with Expect: 100-continue
Date: Thu, 16 Oct 2008 16:49:06 -0700
Hi,
this is my first post to this list so first I would like to thank the
libcurl team for developing such an excellent library!
We are using libcurl in an application to call web services. One of our
main usages is calling SalesForce web services.
This has been working fine for a long time, several years actually.
This week there was a sudden problem with a post and I would like to
figure out what the problem is.
There has been no change on our side that I'm aware of.
This is the debug output from libcurl (generated by setting
CURLOPT_VERBOSE, CURLOPT_DEBUGFUNCTION and CURLOPT_DEBUGDATA)
I have removed some irrelevant headers such as SSL handshake:
CURL DEBUG TEXT: About to connect() to na4-api.salesforce.com port 443 (#0)
CURL DEBUG TEXT: Trying 204.14.234.86...
CURL DEBUG TEXT: connected
CURL DEBUG TEXT: Connected to na4-api.salesforce.com (204.14.234.86)
port 443 (#0)
CURL DEBUG HEADER_OUT: POST /services/Soap/c/9.0/4d0700D300000006D0P
HTTP/1.1
Host: na4-api.salesforce.com
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml; charset="utf-8"
SOAPAction: ""
Content-Length: 1291
Expect: 100-continue
CURL DEBUG HEADER_IN: HTTP/1.1 100 Continue
CURL DEBUG HEADER_IN: Server:
CURL DEBUG HEADER_IN: Content-Length: 0
CURL DEBUG HEADER_IN: Date: Wed, 15 Oct 2008 17:57:36 GMT
CURL DEBUG DATA_OUT: <?xml version="1.0" encoding="UTF-8"
standalone="no" ?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ens="urn:sobject.enterprise.soap.sforce.com"
xmlns:fns="urn:fault.enterprise.soap.sforce.com"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="urn:enterprise.soap.sforce.com"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Header><tns:SessionHeader
xmlns:tns="urn:enterprise.soap.sforce.com">
<tns:sessionId xsi:type="xsd:string">qwert</tns:sessionId>
</tns:SessionHeader><tns:QueryOptions
xmlns:tns="urn:enterprise.soap.sforce.com">
<tns:batchSize xsi:type="xsd:int">2000</tns:batchSize>
</tns:QueryOptions><tns:MruHeader
xmlns:tns="urn:enterprise.soap.sforce.com">
<tns:updateMru xsi:type="xsd:boolean">0</tns:updateMru>
</tns:MruHeader></soapenv:Header><soapenv:Body><tns:query
xmlns:tns="urn:enterprise.soap.sforce.com">
<tns:queryString xsi:type="xsd:string">Select Id, AccountNumber,
BillingStreet, BillingCity, BillingState, BillingCountry, Fax, Name,
Phone FROM Account</tns:queryString>
</tns:query></soapenv:Body></soapenv:Envelope>
CURL DEBUG HEADER_IN: HTTP/1.1 200 OK
CURL DEBUG HEADER_IN: Content-Encoding: gzip
CURL DEBUG HEADER_IN: Server:
CURL DEBUG HEADER_IN: Content-Type: text/xml; charset=utf-8
CURL DEBUG HEADER_IN: Transfer-Encoding: chunked
CURL DEBUG HEADER_IN: Date: Wed, 15 Oct 2008 17:57:37 GMT
CURL DEBUG HEADER_IN:
CURL DEBUG TEXT: transfer closed with outstanding read data remaining
CURL DEBUG TEXT: Closing connection #0
CURL DEBUG TEXT: SSLv3, TLS alert, Client hello (1):
CURL DEBUG UNKNOWN:
If I send the "Transfer-Encoding: chunked" header instead of
"Content-Length: 1291" it all works fine.
In that case the debug output is the following:
CURL DEBUG TEXT: About to connect() to na4-api.salesforce.com port 443 (#0)
CURL DEBUG TEXT: Trying 204.14.234.86...
CURL DEBUG TEXT: connected
CURL DEBUG TEXT: Connected to na4-api.salesforce.com (204.14.234.86)
port 443 (#0)
CURL DEBUG HEADER_OUT: POST /services/Soap/c/9.0/4d0700D300000006D0P
HTTP/1.1
Host: na4-api.salesforce.com
Accept: */*
Accept-Encoding: deflate, gzip
Content-Type: text/xml; charset="utf-8"
SOAPAction: ""
Transfer-Encoding: chunked
CURL DEBUG DATA_OUT: 50b
<?xml version="1.0" encoding="UTF-8" standalone="no" ?><soapenv:Envelope
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:ens="urn:sobject.enterprise.soap.sforce.com"
xmlns:fns="urn:fault.enterprise.soap.sforce.com"
xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="urn:enterprise.soap.sforce.com"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><soapenv:Header><tns:SessionHeader
xmlns:tns="urn:enterprise.soap.sforce.com">
<tns:sessionId xsi:type="xsd:string">qwerty</tns:sessionId>
</tns:SessionHeader><tns:QueryOptions
xmlns:tns="urn:enterprise.soap.sforce.com">
<tns:batchSize xsi:type="xsd:int">2000</tns:batchSize>
</tns:QueryOptions><tns:MruHeader
xmlns:tns="urn:enterprise.soap.sforce.com">
<tns:updateMru xsi:type="xsd:boolean">0</tns:updateMru>
</tns:MruHeader></soapenv:Header><soapenv:Body><tns:query
xmlns:tns="urn:enterprise.soap.sforce.com">
<tns:queryString xsi:type="xsd:string">Select Id, AccountNumber,
BillingStreet, BillingCity, BillingState, BillingCountry, Fax, Name,
Phone FROM Account</tns:queryString>
</tns:query></soapenv:Body></soapenv:Envelope>
CURL DEBUG DATA_OUT: 0
CURL DEBUG HEADER_IN: HTTP/1.1 200 OK
CURL DEBUG HEADER_IN: Content-Encoding: gzip
CURL DEBUG HEADER_IN: Server:
CURL DEBUG HEADER_IN: Content-Type: text/xml; charset=utf-8
CURL DEBUG HEADER_IN: Transfer-Encoding: chunked
CURL DEBUG HEADER_IN: Date: Wed, 15 Oct 2008 18:02:36 GMT
CURL DEBUG HEADER_IN:
CURL DEBUG DATA_IN: 09d4
CURL DEBUG DATA_IN: kxy A_hyOmPa
PVF{cX1--_nU@h`T
@\g7k؛pdZð0r<9hP35hǻ[-WjZbq5bX:x!S*LKҷjH"lZq^5AJT7܃µ`䕸|ԭi¦j]L,Uz2^1slZO^ّp;6ɏn@dDxK]x/$R+ǒi£-xӌFQ
|i9_ʚY2L|QE2qhH0RUePekEfӭ(6~&d
CURL DEBUG DATA_IN:
0
CURL DEBUG TEXT: Connection #0 to host na4-api.salesforce.com left intact
CURL DEBUG TEXT: Closing connection #0
CURL DEBUG TEXT: SSLv3, TLS alert, Client hello (1):
CURL DEBUG UNKNOWN:
So the difference is that instead of sending
Content-Length: 1291
Expect: 100-continue
we send
Transfer-Encoding: chunked
In both cases the server is sending back
Transfer-Encoding: chunked
Could this throw curl off? Our work-around is to use chunked
Transfer-Encoding but I'm just curious if this is a problem in libcurl
or if the server we are posting to is doing something wrong. I have seen
some similar problems on the list but that was with older versions of
libcurl and I found no resolution.
I am using libcurl version 7.18.2 on Windows. Version 7.19.0 has a bug
fix "unexpected 1xx responses hung transfers", not sure if this is
related as my transfer is not hanging it just aborts the transfer.
/Thanks
Emanuel
Received on 2008-10-17