I have C++ Win32 app that uses HttpSendRequest to request some URL (via https). It worked OK earlier; but then errors ERROR_INTERNET_INCORRECT_HANDLE_STATE began happen. Why these ones? Any ideas?
I stumbled across something very similar recently. It suggests that your HttpOpenRequest has either failed or not yet completed, or during the HttpSendRequest() call the connection died for some reason (SSL handshake problems, Certificate problems, or just simple TCP connection problems).
I specifically saw the problem when developing an app using the asynchronous WinINET process, and my calls to HttpQueryInfo and InternetReadFile were failing with that return code.
In my case, I wasn't correctly waiting for the async notifications from HttpSendRequest to be received before calling the other methods, and also in cases where I wasn't correctly dealing with failures during the connection.
I know its a year late, but hopefully that helps.
It seems trivial but,
did you have flag INTERNET_FLAG_SECURE in making HttpOpenRequest?
as described in:
http://support.microsoft.com/kb/168151
For I myself was stuck here for hours until I found above knowledge base entry.
I got the same error on Windows XP for HTTPS connection (all flags correct) for the HTTP2 server endpoint, I wonder if it can't properly handle HTTP2 connection or the certificate.
Related
I'm not really an EWS user, just trying to help debug a mailing application that stopped working last year.
We get an error message when trying to send() that the connection was forcibly closed. Reading up on the issue it seems like a lot of folks are saying it's a TLS version problem.
Someone here think it's because we are using Basic Authentication (instead of Modern Authentication with OAuth 2.0). We don't see any issues directly related to authentication.
By still using Basic Authentication, can that cause the connection closed issue when we try to execute the send() method?
No a connection being forcibly closed is most likely either TLS, bad ip reputation (eg a lot of spam/fraud coming from a certain IP that has been blacklisted) or your sending a message with a very large attachment in a single request. If it was a Basic Authentication disabled issue you would get a 401 error, if its was that EWS had been disabled (eg via set-casMailbox) you could get a 403.
Chrome seems to have released an update over the past week. This has caused at least 50 of our internal applications to throw the exception shown below. The solutions I have researched over the Internet, talk about updating the application server with a stronger cipher. However, our applications are spread out over IIS, tomcat, jboss, weblogic and websphere. Its not practical to expect all of these application servers to be updated. Is there no way to get Chrome to allow an "exception" for these sites ? Since these sites are all internal, the security is not really a concern.
Apparently, Firefox throws the same exception but there is a documented fix for that (by changing some settings in Firefox). Is anyone aware of a similar fix in Chrome.
Error
Server has a weak ephemeral Diffie-Hellman public key
ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY
I found a temporary workaround that should disable the security check in Chrome that is causing that error. It goes without saying that you do NOT want to use this while browsing the open web.
Try adding the following command argument to Chrome when you start it up:
--cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013
I found this solution at this google forum post. Hopefully it will help!
While Maximillian's workaround might work for you at the moment, there is no supported way to add an exception.
The only safe solution is to upgrade the servers, and a less fragile workaround might be to put better proxies right in front of some of the servers.
This problem I found because of the JDK version running on App Server.
If your weblogic/apache server running on java JRockit version "1.6.0_33" & "1.6.0_45" or below you will face this issue.
A solution is to upgrade java to higher version like "1.6.0_101" and higher and restart app server.
I've solved this problem without upgrading jrockit but configuring the ssl section like this
<ssl>
<enabled>true</enabled>
<hostname-verifier xsi:nil="true"></hostname-verifier>
<hostname-verification-ignored>false</hostname-verification-ignored>
<export-key-lifespan>500</export-key-lifespan>
<client-certificate-enforced>false</client-certificate-enforced>
<two-way-ssl-enabled>false</two-way-ssl-enabled>
<ssl-rejection-logging-enabled>true</ssl-rejection-logging-enabled>
<inbound-certificate-validation>BuiltinSSLValidationOnly</inbound-certificate-validation>
<outbound-certificate-validation>BuiltinSSLValidationOnly</outbound-certificate-validation>
<allow-unencrypted-null-cipher>false</allow-unencrypted-null-cipher>
<use-server-certs>false</use-server-certs>
<jsse-enabled>true</jsse-enabled>
</ssl>
Can't tell you exactly whats makes the difference but it solved many different problems on SSL with chrome
Annoying issue...
OS : Linux
I am trying to connect to couchbase server but its causingfollowing exception. Problem is that everything was working fine and this issue has starting coming from no where. I hope its nothing to do with some port configuration or related to it...
If some one have any useful information over this, Please share with me. in the mean time, I am also looking into the issue.
Exception Stack Trace :
2014-11-16 07:57:00.946 WARN com.couchbase.client.CouchbaseConnection: Problem handling Couchbase IO
java.io.IOException: Invalid argument
at sun.nio.ch.DevPollArrayWrapper.poll0(Native Method)
at sun.nio.ch.DevPollArrayWrapper.poll(DevPollArrayWrapper.java:170)
at sun.nio.ch.DevPollSelectorImpl.doSelect(DevPollSelectorImpl.java:68)
at sun.nio.ch.SelectorImpl.lockAndDoSelect(SelectorImpl.java:69)
at sun.nio.ch.SelectorImpl.select(SelectorImpl.java:80)
at net.spy.memcached.MemcachedConnection.handleIO(MemcachedConnection.java:398)
at com.couchbase.client.CouchbaseConnection.run(CouchbaseConnection.java:288)
I tried connecting to the same couchbase server from a sample program from my local windows box, It worked as expected.
Got the reason. I was using -d64 option while calling my java program. unfortunately, the couchbase sdk I am using was only supporting 32 bit.
I removed the -d64 option and it ran fine.
I have a Policy File service written in Node.js (Windows 7 environment). I simply want to test that the service returns the policy when a request is made over port 843, but without using Flash (i.e. Telnet, Browser, Powershell, Python, anything really.)
I've looked extensively but can't find any solution that does this. I have attempted with Telnet, but on connection, any keypress at all causes the server to return a bad response (presumably because the request didn't contain the requisite <policy-file-request/>\0 data.)
Is this possible?
You need to rebuild your service to wait for more data if there is incomplete data. Then you will be able to use Telnet to debug the service.
I'm facing a problem with a 3-tier application. It uses IIS and SQL Server. And the problem is that sometimes (longer requests cause higher probability) client does not receive response from IIS. It hangs when there is no activity ON SQL Server, and when even when I kill an SQL Process I get no response with an exception. When I examine data after these hangs I find that my SQL requests have succeeded, so the problem appears to be on IIS. Unfotunately I don't have much control over the place where the application is hosted and I cannot reproduce the problem. There can be many answers to this question, but at least I need a hint in what direction I should investigate.
UPDATE: I also have an app running on the same server that does a small job: it inserts around a 100 lines line-by-line into a database. Artificially I made it run for about 10 minutes (by putting xlock on the table). After removing the xlock the process on IIS continued running and successfully inserted those 100 lines. However, control never returned to the client thereafter, it just waited indefinitely. It looks like this is a problem when returning a response to the client after a long running process.
BTW, this is not a website, but a WinForms app that uses Remoting.
If you're sure that SQL Server is returning to IIS, then you might want to check the IIS logs to see what might be happening to the request. The normal location for these logs is %SystemRoot%\system32\Logfiles\<service_name>.
If you're not sure about SQL Server, you might access the SQL logs, run Profiler, or check the Windows system logs for errors, run your site in debug in Visual Studio or add your own logging to your app to figure out which step it's hanging on.
I have finally figured out where the problem is. The application is run on a web farm and there is a balancer server between the client and IIS. There was a too small timeout on the balancer. For some reason it is not quite friendly with .net remoting and it doesn't return any timeout exceptions to the client. The issue has been solved by increasing the timeout.