Archived Forum Post
Index of archived forum posts
Question:
Archived Forum PostQuestion:
If I send a HTTP request to a SOAP-webservice in the LAN, it takes a long time for SynchronousRequest to return and I get a false response. With version 9.4.1.26 it works.
I checked the traffic with Wireshark and with version 9.5.0.40 at the client side, the first response of the server is status "100 continue" and the second response is the "200 OK". With the old version of the library at the client, the first response of the server is "200 OK". This should be both ok, but the new version seems in this case not handle the status 100 correctly and waits until timeout.
I can reproduce this effect with three different SOAP webservices in our LAN.
The Chilkat log:
SynchronousRequest:
DllDate: Jun 10 2014
ChilkatVersion: 9.5.0.40
UnlockPrefix: IPRODEHttp
Username: SExxxxxx:Rxxxxx
Architecture: Little Endian; 32-bit
Language: Visual C++ 10.0 (32-bit)
VerboseLogging: 1
domain: icom999999
port: 63306
ssl: 0
httpRequest:
httpVersion: 1.1
verb: POST
path: /icom
contentType: text/xml;charset=utf-8
charset: windows-1252
sendCharset: 0
mimeHeader: SOAPAction: http://www.zeiss.de/icom/2009/pms/http/GetVersion
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; MANM; rv:11.0) IProExt 2.0 (9.5.0.40)
--httpRequest
readTimeout: 300
connectTimeout: 10
fullRequest:
httpRequest:
httpVersion: 1.1
verb: POST
path: /icom
contentType: text/xml;charset=utf-8
charset: windows-1252
sendCharset: 0
mimeHeader: SOAPAction: http://www.zeiss.de/icom/2009/pms/http/GetVersion
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; MANM; rv:11.0) IProExt 2.0 (9.5.0.40)
--httpRequest
HttpOptions:
AddHostHeader: 1
AllowCookieResponseCaching: 0
AllowGzip: 1
ConnectTimeoutMs: 10000
CookieDir:
FollowRedirects: 1
Login:
LoginDomain:
AuthMethod:
MaxResponseSize: 0
MaxUrlLen: 2000
PasswordLen: 0
ProxyHostname:
ProxyLogin:
ProxyLogin:
ProxyAuthDomain:
ProxyPasswordLen: 0
ProxyPort: 80
ReadTimeoutMs: 300000
RequiredContentType:
ResumePoint: 0
SaveCookies: 1
SendBufferSize: 65535
SendCookies: 1
SslProtocol: 0
UnavailableRetryCount: 0
UnavailableRetryWaitMs: 2000
--HttpOptions
a_synchronousRequest:
generateRequest:
httpRequestGenStartLine:
authOnly: 0
hasMimeBody: 1
genStartLine:
startLine: POST /icom HTTP/1.1
--genStartLine
--httpRequestGenStartLine
genHeaderSb:
getMimeHeaderHttp:
headerField: SOAPAction: http://www.zeiss.de/icom/2009/pms/http/GetVersion
headerField: User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; MANM; rv:11.0) IProExt 2.0 (9.5.0.40)
--getMimeHeaderHttp
--genHeaderSb
addCookies:
Not auto-adding cookies.
--addCookies
addHostHeader: icom999999
--generateRequest
fullHttpRequest:
domain: icom999999
port: 63306
ssl: 0
openHttpConnection:
Opening connection directly to HTTP server.
httpHostname: icom999999
httpPort: 63306
ssl: 0
bUsingHttpProxy: 0
httpProxyAuthMethod:
socket2Connect:
connect2:
hostname: icom999999
port: 63306
ssl: 0
connectSocket:
domainOrIpAddress: icom999999
port: 63306
connectTimeoutMs: 300000
connect_ipv6_or_ipv4:
Multi-threaded domain to IP address resolution
AddrInfoList:
AddrInfo:
ai_flags: 0
ai_family: 2
ai_socktype: 0
ai_protocol: 0
ai_addrlen: 16
ai_canonname: (NULL)
--AddrInfo
--AddrInfoList
connecting to IPV4 address...
ipAddress: 172.16.1.153
connect:
Waiting for the connect to complete...
myIP: 172.16.1.58
myPort: 3105
socket connect successful.
--connect
--connect_ipv6_or_ipv4
--connectSocket
--connect2
--socket2Connect
connectElapsedMs: 480
HTTP connection succeeded.
--openHttpConnection
connectTime: Elapsed time: 520 millisec
startLine: POST /icom HTTP/1.1
requestHeader:
requestHeader: Content-Type: text/xml;charset=utf-8
SOAPAction: http://www.zeiss.de/icom/2009/pms/http/GetVersion
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; MANM; rv:11.0) IProExt 2.0 (9.5.0.40)
Host: icom999999:63306
Content-Length: 372
--requestHeader
sendRequestHeader:
sendHeaderElapsedMs: 0
--sendRequestHeader
sendRequestBody:
sendBodyElapsedMs: 0
--sendRequestBody
readResponseHeader:
responseHeader: HTTP/1.1 100 Continue
--readResponseHeader
statusCode: 100
statusText: Continue
readResponseBody:
Response has no Content-Length header.
Non-chunked response with no Content-Length.
readingUntilServerClosesConnection:
Any errors reported within this context are not actual errors...
WindowsError: Eine vorhandene Verbindung wurde vom Remotehost geschlossen.
WindowsErrorCode: 0x2746
numBytesRequested: 4096
Failed to receive data on the TCP socket
readNToOutput: Socket fatal error.
--readingUntilServerClosesConnection
--readResponseBody
--fullHttpRequest
success: 1
--a_synchronousRequest
--fullRequest
totalTime: Elapsed time: 126793 millisec
Success.
--SynchronousRequest
--ChilkatLog
Your web server is sending a "100 Continue" response unexpectedly. Chilkat should've handled it, and this can be fixed. However, the workaround is to add the "Expect: 100-continue" to your request header. When this is done, Chilkat will expect the "100 continue" response, and everything should work.
To add the the "Expect: 100-continue" header, do this:
req.AddHeader("Expect","100-continue");
where req is your CkHttpRequest object.