# Visual Basic > Visual Basic 6 and Earlier >  MSXML2.ServerXMLHTTP60 with TLS 1.2 support XP POSReady

## Montclair

I've got an XP POSReady system with all the correct registry keys, applied updates, and the IE TLS 1.2 checkbox set. I've got a simple test application that's returning my connection as TLS 1.2 in the IDE. When I compile the application to an executable, however, the program returns TLS 1.0 as my connection result when using ServerXMLHTTP60.

I'm having a tough time tracking down why. I've run registry and file monitors to make sure the IDE and the executable are referencing the same dlls and keys, and can't find a reason for this. I've tried with references and without (late binding) and both return the same results.

Incidentally, I tested Msxml2.XMLHTTP60, which works correctly in both the IDE and application. It's only MSXML.ServerXMLHTTP60 that doesn't work in the executable.



```
Private Sub Command1_Click()
       
    ' Create a reference to MSXML6 if you want to use the next line,
    ' and rem out the two lines that follow this
    ' Dim objhttp As New MSXML2.ServerXMLHTTP60
    
    Dim objhttp As Object
    Set objhttp = CreateObject("Msxml2.ServerXMLHTTP.6.0")
    objhttp.open "GET", "https://howsmyssl.com/a/check", False
    objhttp.setRequestHeader "User-Agent", "Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0"
    objhttp.setRequestHeader "Content-type", "text/html"
    objhttp.send
    Debug.Print objhttp.getAllResponseHeaders
    Debug.Print objhttp.responseText
    Text1.Text = Text1.Text & vbCrLf & objhttp.getAllResponseHeaders & vbCrLf & objhttp.responseText
    Set objhttp = Nothing
End Sub
```

I did check my path to make sure only MSXML6.dll, MSXML6r.dll, and WinHttp.dll in System32 are being utilized, and not some copies in some other directories in the path, so I'm not sure why this is happening.

Also, I prefer to use the XML library and not Winhttp.dll directly, as I'm dealing with XML data from the server that my actual program is connecting, and the application is already fully written. The service provider is just enforcing TLS 1.2 very shortly.

Here's the VB6 project if you want to download and test for yourself.

tls.zip

----------


## dilettante

We can't always get what we want.

I don't think the MSXML wrapper around the WinHttp exposes access to the necessary option to use TLS 1.2:



```
:
    Set HTTPRequest = New WinHttp.WinHttpRequest
    With HTTPRequest
        .Open "GET", "http://www.google.com/", True
        .Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1_2
        .Option(WinHttpRequestOption_EnableRedirects) = True
        .Send
:
:
```

No idea why you are worried about fiddling with paths though.  ActiveX libraries are located via their class registration, and the path stored there gets used.

----------


## wqweto

> I've got an XP POSReady system with all the correct registry keys, applied updates, and the IE TLS 1.2 checkbox set. I've got a simple test application that's returning my connection as TLS 1.2 in the IDE. When I compile the application to an executable, however, the program returns TLS 1.0 as my connection result when using ServerXMLHTTP60.


Are running your IDE on the same XP POSReady box or is this a separate machine?

cheers,
</wqw>

----------


## Montclair

Don't see how to delete a duplicate post, but this was a duplicate.

----------


## Montclair

> I don't think the MSXML wrapper around the WinHttp exposes access to the necessary option to use TLS 1.2:


If that's true, then it shouldn't work in the IDE, which it does.




> No idea why you are worried about fiddling with paths though. ActiveX libraries are located via their class registration, and the path stored there gets used.


I'm not interested in fiddling with the path. I stated that I ensured the correct dlls were being  accessed in the IDE and run-time by the OS, by checking the path for the dlls. I was simply eliminating a possibility as to what's causing this odd behavior.

Lastly, I'm not interested in calling winhttp directly as explained. I appreciate the code, but I'd prefer to not use that. The post is about why MSXML2.ServerHTTP connects via TLS 1.2 in the IDE, but not in the run-time.

----------


## Montclair

> Are running your IDE on the same XP POSReady box or is this a separate machine?
> 
> cheers,
> </wqw>


Same box, which makes this very strange.

----------


## westconn1

on testing with the sample project (no changes)

both seemed to work the same for me in ide or compiled exe

IDE

```
{"given_cipher_suites":["TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384","TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_256_GCM_SHA384","TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_3DES_EDE_CBC_SHA"],"ephemeral_keys_supported":true,"session_ticket_supported":true,"tls_compression_supported":false,"unknown_cipher_suite_supported":false,"beast_vuln":false,"able_to_detect_n_minus_one_splitting":false,"insecure_cipher_suites":{},"tls_version":"TLS 1.2","rating":"Probably Okay"}
```

EXE


> {"given_cipher_suites":["TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_W  ITH_AES_256_GCM_SHA384","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SH  A384","TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384","TLS_ECDHE_R  SA_WITH_AES_128_CBC_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_CBC  _SHA","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_25  6_GCM_SHA384","TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA256","TLS_RSA_WITH_AES_  128_CBC_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_3DES_EDE  _CBC_SHA"],"ephemeral_keys_supported":true,"session_ticket_supported":true,"tls_compression_supported":false,"  unknown_cipher_suite_supported":false,"beast_vuln":false,"able_to_detect_n_minus_one_splitting":fals  e,"insecure_cipher_suites":{},"tls_version":"TLS 1.2","rating":"Probably Okay"}

----------


## Montclair

> on testing with the sample project (no changes)
> 
> both seemed to work the same for me in ide or compiled exe
> 
> IDE
> 
> ```
> {"given_cipher_suites":["TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384","TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384","TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256","TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA","TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA","TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA","TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_AES_256_GCM_SHA384","TLS_RSA_WITH_AES_128_GCM_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA256","TLS_RSA_WITH_AES_128_CBC_SHA256","TLS_RSA_WITH_AES_256_CBC_SHA","TLS_RSA_WITH_AES_128_CBC_SHA","TLS_RSA_WITH_3DES_EDE_CBC_SHA"],"ephemeral_keys_supported":true,"session_ticket_supported":true,"tls_compression_supported":false,"unknown_cipher_suite_supported":false,"beast_vuln":false,"able_to_detect_n_minus_one_splitting":false,"insecure_cipher_suites":{},"tls_version":"TLS 1.2","rating":"Probably Okay"}
> ```
> ...


What operating system are you running?

----------


## westconn1

w10 pro

i can test it on xp later

edit: on testing in xp, i also got the same results for both the ide and an exe, both returned TLS1.0

----------


## Montclair

> w10 pro
> 
> i can test it on xp later
> 
> edit: on testing in xp, i also got the same results for both the ide and an exe, both returned TLS1.0


Right, which is what you should get on standard XP, and is also what I get on other machines running XP. I'm running the POSReady patches to enable TLS 1.2 on this machine before I deploy to the others.

Does anyone have the POSReady version running who can test this? It's very, very odd.

----------


## westconn1

are you running either the ide or the exe elevated? that could possible account for the difference in version

----------


## Montclair

> are you running either the ide or the exe elevated? that could possible account for the difference in version


Not that I'm aware of.  I'm using an admin account and running both under that.

----------


## Montclair

Well something weird just happened. The first time I ran it from the IDE, I got "TLS 1.0", the same as the executable. When I ran it again from the IDE, I got "TLS 1.2". I'm able to duplicate that every time by closing VB and re-opening it.  

As a matter of fact, if I click the MSXML2.ServerXMLHTTP.6.0 button a second time after getting "TLS 1.0", it then returns "TLS 1.2".

So, if I unload VB and reopen, I get TLS 1.0 on the first call, and TLS 1.2 on every subsequent call.  If I leave VB running, end the program, and start it again, I get TLS 1.2 on every call after the first one from the first time I ran the program.

What the heck?!

----------


## wqweto

Btw, you are missing www in the URL and both requests currently first redirect to https://www.howsmyssl.com/a/check 

This might not be the solution but in any case redirection might fail w/ access denied (for some reason) depending on Internet security zone settings.

cheers,
</wqw>

----------


## ahenry

I tried on Windows 7 and both IDE and exe came back with TLS 1.0...

----------


## Montclair

> Btw, you are missing www in the URL and both requests currently first redirect to https://www.howsmyssl.com/a/check 
> 
> This might not be the solution but in any case redirection might fail w/ access denied (for some reason) depending on Internet security zone settings.
> 
> cheers,
> </wqw>


I tried with www and got the same results.

However, those results now confirm that both the executable and the IDE perform identically. Both calls with MSXML2.ServerXMLHTTP return TLS 1.0 on their first calls, and TLS 1.2 on all subsequent calls -- which is wrong.  It should be TLS 1.2 on all calls.

I'm starting to think that maybe a registry key might be the issue. I will do more investigation and report my results.

----------


## Montclair

Registry settings appear to be the issue, but I can't seem to get them working. I tried disabling all protocols in the registry except TLS 1.2, and the program fails immediately with error 80090331, stating "The client and server cannot communicate, because they do not possess a common algorithm."  These keys are:



```
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client]
"DisabledByDefault"=dword:000000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
```

I also tried both A00 and 800 for this key, as detailed in https://support.microsoft.com/en-us/...ols-on-winhttp:



```
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800
```

And the results are the same. If I don't leave TLS 1.0 enabled, the program can't communicate at all with this test URL. Additionally, I tested all of this with the actual server I need to connect with and the results are identical. TLS 1.0 connections are rejected by that server, but subsequent calls use TLS 1.2. If TLS 1.0 is disabled, I get the same error about no common algorithm.

I'm unclear on why TLS 1.0 needs to be enabled and attempted first and fail, then TLS 1.2 will be used on subsequent attempts, but I fear that this discussion may now be out of the scope of a VB forum, unless anyone out there has any insight.

----------


## Montclair

More info. I tried adding a call using WinHTTP and setting the protocols to only accept TLS 1.2, which immediately and properly connects using TLS 1.2.  Subsequent to that, calls using MSXML2.ServerXMLHTTP also connect using TLS 1.2.  

While definitely not ideal, this could be a workaround to get MSXML2.ServerXMLHTTP to connect using TLS 1.2.

In the end, I will likely re-code the connection to use WinHTTP entirely, which I was hoping to avoid, and MSXML to handle the actual XML data.

I'd still like to know why the OS or MSXML2.ServerXMLHTTP object calls fail to attempt TLS 1.2 first.

Updated project attached.
tls.zip

----------


## Montclair

It was, surprisingly, easy to convert my existing code in the actual application to use WinHTTP, which appears to work properly enforcing TLS 1.2 on all calls from XP POSReady and Windows 10 (the OS's where this application will be deployed).

While this isn't an answer as to why POSReady and XMLServerHTTP calls try to use TLS 1.0 on the first call (despite the registry stating that's not desirable), it is an acceptable workaround.

For others who may stumble upon this and are hesitant, converting my code was as simple as this:



```
Set XMLReceive = CreateObject("Msxml2.DOMDocument.6.0")
Set XMLServer = CreateObject("Msxml2.ServerXMLHTTP.6.0")
XMLServer.setTimeouts ResolveTimeoutMs, ConnectTimeoutMs, SendTimeoutMs, ReceiveTimeoutMs
XMLServer.setRequestHeader "User-Agent", "My XML App V1.0"
XMLServer.setRequestHeader "Content-type", "text/xml"
XMLServer.Open "POST", Server_Address, False
XMLServer.send (My_XML_Request_String_or_XML_Document)
Failure = (XMLServer.Status <> 200)
If Not Failure Then XMLReceive.loadXML (XMLServer.ResponseXML.XML)
```

to



```
Set XMLServer = CreateObject("WinHttp.WinHttpRequest.5.1")
Set XMLReceive = CreateObject("Msxml2.DOMDocument.6.0")
XMLServer.setTimeouts ResolveTimeoutMs, ConnectTimeoutMs, SendTimeoutMs, ReceiveTimeoutMs

'force TLS 1.2
XMLServer.Option(9) = 2048
XMLServer.Option(6) = True

XMLServer.Open "POST", Server_Address, False
XMLServer.setRequestHeader "User-Agent", "My XML App V1.0"
XMLServer.setRequestHeader "Content-type", "text/xml"
XMLServer.send (My_XML_Request_String_or_XML_Document)
Failure = (XMLServer.Status <> 200)
If Not Failure Then XMLReceive.loadXML (XMLServer.ResponseText)
```

It would, nonetheless, be interesting to understand why such odd behavior arises from the XMLServerHTTP object, but that may never be found, as I'm moving on with the project using the WinHTTP object.

----------


## wqweto

Glad you nailed it. I was fiddling with Option(9) on ServerXMLHTTP/XMLHTTP and it was always failing w/ "invalid option" or similar, doh :-))

Probably XMLServer.Option(9) = XMLServer.Option(9) Or 2048 would be safer, i.e. instead of "forcing" TLS 1.2 just "allowing" it (if available on server endpoint).

cheers,
</wqw>

----------


## Montclair

> Glad you nailed it. I was fiddling with Option(9) on ServerXMLHTTP/XMLHTTP and it was always failing w/ "invalid option" or similar, doh :-))
> 
> Probably XMLServer.Option(9) = XMLServer.Option(9) Or 2048 would be safer, i.e. instead of "forcing" TLS 1.2 just "allowing" it (if available on server endpoint).
> 
> cheers,
> </wqw>


Ah, very clever comment on the option! I'll try that and see if it performs incorrectly and report back.

As for setting those options on the MSXML objects, they don't exist -- which is why you would get that error. There's no mechanism to specify what's allowed and what's not, other than the registry, when dealing with MSXML, AFAIK.

It's still all very curious. If I tell the OS to use TLS 1.2, then XMLServerHTTP calls fail on the first try,  using the lowest available protocol but it refuses to use TLS 1.2 on that first try.  XMLHTTP works every time connecting with TLS 1.2. Very weird.

Another interesting tidbit -- if I make the first call through WinHTTP, then XMLServerHTTP will correctly use TLS 1.2 on its first call! It just seems like these options have to be set on the WinHTTP object, as XMLServerHTTP defaults to the lower security protocols first and just won't use TLS 1.2 on it's first call regardless of registry settings. So strange!

It's probably a bug in the MSXML library for XP POSReady for the XMLServerHTTP object. None of this weird stuff happens on Windows 10.

----------


## Montclair

> Probably XMLServer.Option(9) = XMLServer.Option(9) Or 2048 would be safer, i.e. instead of "forcing" TLS 1.2 just "allowing" it (if available on server endpoint).


Results in error 5, "Invalid procedure call or argument".  Apparently, you can't actually read the value set in HttpRequestOption (in VB6 on XP anyway). Even this fails:



```
    
    Dim HTTPRequest As Object
    Set HTTPRequest = CreateObject("WinHttp.WinHttpRequest.5.1")
    With HTTPRequest
        .Option(9) = 2048
        Debug.Print .Option(9)
        .Option(6) = True
        .Open "GET", "https://www.howsmyssl.com/a/check", True
        .Send
        .WaitForResponse = 5
        Text1.Text = Text1.Text & .ResponseText
    End With
```

The bold line results in error 5. Weird.

You do bring up a valid point though. When TLS 1.2 is invalidated some time in the future, this program will fail. Not sure how I would even code for some unknown future value anyway, other than how you suggested.

----------


## wqweto

Debug.Print .Option(2) works so apparently 9 is write-only option.

You can self-document the code by using the actual constant names (w/o winhttp typelib reference) like this:


thinBasic Code:
' consts copy/pasted from `Microsoft WinHTTP Services, version 5.1` typelib
    Const WinHttpRequestOption_SecureProtocols = 9
    Const SecureProtocol_TLS1 = 128
    Const SecureProtocol_TLS1_1 = 512
    Const SecureProtocol_TLS1_2 = 2048
    With HTTPRequest
        .Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1_2 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1
        . . .
    End With
cheers,
</wqw>

----------


## Montclair

> Debug.Print .Option(2) works so apparently 9 is write-only option.
> 
> You can self-document the code by using the actual constant names (w/o winhttp typelib reference) like this:
> 
> 
> thinBasic Code:
> ' consts copy/pasted from `Microsoft WinHTTP Services, version 5.1` typelib    Const WinHttpRequestOption_SecureProtocols = 9    Const SecureProtocol_TLS1 = 128    Const SecureProtocol_TLS1_1 = 512    Const SecureProtocol_TLS1_2 = 2048    With HTTPRequest        .Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1_2 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1        . . .    End With
> cheers,
> </wqw>


Interesting that 9 is write-only despite the documentation. I know about the constants, and my actual code was already updated to use them. Still, no way to future proof this, though, which is expected I suppose. I'll deal with that hurdle when it actually becomes one.

Thanks for the conversation. I enjoyed it!  :Smilie:

----------


## Montclair

For the sake of completeness, attached is the final, cleaned up version of this TLS tester. It will tell you whether your system successfully negotiates a TLS 1.2 connection with the test server at https://www.howsmyssl.com/a/check using the various connection methods of WinHttp51, XMLServerHTTP60, and XMLHTTP60.

Feel free to modify and use for whatever you want.

tls.zip

----------


## vb6locked

> For the sake of completeness, attached is the final, cleaned up version of this TLS tester. It will tell you whether your system successfully negotiates a TLS 1.2 connection with the test server at https://www.howsmyssl.com/a/check using the various connection methods of WinHttp51, XMLServerHTTP60, and XMLHTTP60.
> 
> Feel free to modify and use for whatever you want.
> 
> tls.zip


Thank you Montclair... This is exactly what i've been looking for.  I was using the MSXML2.ServerXMLHTTP.6.0 and been having issues with certain HTTPS sites, and knew it was because of ciphers etc not up to date.

I will now be able to implement this to update my program to start supporting those sites again i couldn't connect with.

----------


## Montclair

> Thank you Montclair... This is exactly what i've been looking for.  I was using the MSXML2.ServerXMLHTTP.6.0 and been having issues with certain HTTPS sites, and knew it was because of ciphers etc not up to date.
> 
> I will now be able to implement this to update my program to start supporting those sites again i couldn't connect with.


You're very welcome!  I'm glad I could help out.  Us old VB guys gotta stick together.  :Smilie:

----------


## Montclair

Duplicate post content deleted. Wish this site allowed me to delete duplicate posts.

----------


## vb6locked

I have SO many libraries and controls i have written, its hard for me to give up Vb6 because i can write some very complex GUI programs in days, rather than months.  I have written in other languages, but i always try and tie it to Vb6.  For example, i wrote a Cuda C program to do some heavy lifting for my VPU.  I then used older versions of visual studio to be able to call those Cuda C functions through my vb6 program.

----------


## xiaoyao

You can use winhttp, 99% of the usage is the same. When I develop some crawlers or post submission, generally commonly used xmlhttp, serverxmlhttp, winhttp, all can be set and selected in the same module.
chinese:你可以使用winhttp，99%的用法都是相同的，我开发一些爬虫或者post提交的时候,一般常用xmlhttp,serverxmlhttp,winhttp,都在同一个模块里面可以任意设  置选择。

----------


## xiaoyao

In China, we use the simplified version of the win7 installation package 200 MB, after installation, there is only 800 MB to a g. The volume is very small and can completely replace XP. Now the system I use is windows8.1, which has the appearance of win10, and has the mini speed of win7.
I installed the entire system in a 10g-size memory disk. Ramos is very easy to use. The hard disk read speed is 8000 megabits per second.
chinese:在中国，我们使用精简版本win7安装包200兆，装好之后也只有800兆到一个g。体积非常迷你，完全可以替代xp,现在我使用的系统是windows8.1,拥有win10的外观，又有win  7的迷你快速。
我把整个系统安装在10g大小的内存盘里面，ramos,非常好用，硬盘读取速度8000兆每秒。

----------


## vb6locked

Okay, i updated a couple of my programs and i have TLS 1.2 working now.  Thanks again Montclair..  let's hope they don't start blocking TLS 1.2 any time soon.

Ps.
On my Win 10 machine, i get tls 1.2 on all buttons.
On my Win 7 machine, i only can get 1.2 on the 3'rd button - MSXML2.XMLHTTP.6.0 - TLS Max Version : 1.2

Is this the same for everyone, or am i missing something?

Extra Info : I added all the registry entries...

----------


## vb6locked

Update to last message.  I was able to get two of the three working within Windows7:

MSXML2.ServerXMLHTTP.6.0 - TLS Max Version : 1.2
MSXML2.XMLHTTP.6.0 - TLS Max Version : 1.2

But, from what i read, i should be able to get the WinHttp to work, and i cannot.

WinHttp.WinHTTPRequest.5.1 - TLS Max Version : 1

Installing IE 11 for Windows7 got *MSXML2.XMLHTTP.6.0* working.
Installing KB3140245 got *MSXML2.ServerXMLHTTP.6.0* working.

No Success with WinHttp

----------


## vb6locked

Got IT!

Here is the offender :


```
.Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1_2
```

Even thou all the patches and registry entries have been added, apparently, on Windows7 the option to set the secureprotocols fails on any value beyond TLS1.0 (128).  If i completely remove the option, i then get full TLS 1.2 support.

I have also updated the code to show the max TLS supported line, and removed the .option(WinHttpRequestOption_SecureProtocols) line

WinHttp.WinHTTPRequest.5.1 - TLS Max Version : 1.2
MSXML2.ServerXMLHTTP.6.0 - TLS Max Version : 1.2
MSXML2.XMLHTTP.6.0 - TLS Max Version : 1.2

Works every-time in both IDE and EXE

----------


## Montclair

> Got IT!
> 
> Here is the offender :
> 
> 
> ```
> .Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1_2
> ```
> 
> ...


That's good news!

The point of the lines you rem'd out, however, was to test TLS 1.2, then 1.1, then 1.0 to see what your system supports.  It's odd that fails on Windows 7 as your registry settings appear to be correct, based on the .reg file you added to the zip, although you left out the TLS 1.x\Server keys (maybe they're not necessary - not sure -- see post #17).

I verified that my original version works in Windows 10, so it's very strange that it doesn't in 7.

I'd probably leave the code in there that you rem'd out because in XP POS Ready with your version, WinHTTP fails on the first click, going immediately back to TLS 1.0.

You could put an OS check using the code found here, then use the result to code around windows 7 implementing the checks or not.  I bet it's some other registry setting, though, not set in your system's registry.

Bottom line, your version doesn't work in XP POS Ready which was the original point of the post, but it does appear to work in 7+ (works in Windows 10 verified).

Just for completeness, I'm re-attaching the original version just in case anyone else using XP POS Ready comes across this.

----------


## Montclair

Unfortunately, after several months, I need to revisit this topic, but this time for a Vista installation.  Neither my original version of TLS nor vb6locked's is able to negotiate TLS 1.2 using WinHttp.WinHttpRequest.5.1 and MSXML2.ServerXMLHTTP.6.0.  Only MSXML2.XMLHTTP.6.0 is able to make a TLS 1.2 connection.

In doing a lot of research, there is a patch for Windows Server 2008 that could be applied to Vista to allow TLS 1.2 connections, which I've applied. More about that here: https://johnhaller.com/useful-stuff/...-windows-vista

I have all the registry keys correct, and if I disable TLS 1.0 and lower protocols, I can't get VB to make a TLS 1.1 or TLS 1.2 connection via the two methods above.  For whatever reason, only one method works, but I've already rewritten all of my various projects to use WinHTTP, as that works on XP POS Ready and Windows 10.

Specifically, setting this results in error 5, as vb6locked noted on his Windows 7 matchine:


```
Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1_2
```

The supposed solution to this is to not set the option at all, and instead let the registry keys define which protocol is the default option for WinHTTP, which is what vb6locked had to do to get WinHTTP to connect via TLS 1.2 on Windows 7.

However, no matter what I try, I just can't get Vista and VB6 to do this. I've combed through stackexchange, google, youtube, etc., and just can't find the answer.  IE9 is installed and does make a TLS 1.2 connection to https://www.howsmyssl.com/, so I know it is supported and should be working, as it works with the MXSML2.HTTP request as well.

I tried turning on WinHTTP tracing, but honestly, I don't find the logs to be very useful in figuring out why VB6 calls to WinHTTP won't use the default protocol. In fact, if I disable all other protocols in the registry with only TLS 1.2 enabled, and do not set the Option(WinHttpRequestOption_SecureProtocols) to anything, VB refuses to connect at all. Otherwise, I always get connected via TLS 1.0

Wondering if anyone knows what I'm missing?

----------


## wqweto

> Unfortunately, after several months, I need to revisit this topic, but this time for a Vista installation.  Neither my original version of TLS nor vb6locked's is able to negotiate TLS 1.2 using WinHttp.WinHttpRequest.5.1 and MSXML2.ServerXMLHTTP.6.0.  Only MSXML2.XMLHTTP.6.0 is able to make a TLS 1.2 connection.


I had this same behavior on Win7 here but I fixed this very easily. Here is my root cause analysis of the problem.

When you set .Option(WinHttpRequestOption_SecureProtocols) = protocol_selection it is the WinHttp.WinHttpRequest COM object that does some kind of "client-side" validation of the allowed bits being set in the protocol_selection value. For XP, Vista and Win7 you can't go to anything beyond SecureProtocol_TLS1 so testing for TLS 1.2 (and TLS 1.1) protocol availability with by error trapping the property assignment is not very accurate (at all).

For TLS 1.2 Microsoft directly slip-streamed updated SSPI (Schannel) DLLs on XP SP3 (POS Ready only), Vista (actually Server 2008) and Win7 but did not update the pre-installed WinHttp.WinHttpRequest COM object so now we have capabilities mismatch between WinHttp and the actual SSPI protocol implementation because of the "client-side" validation on the Option property.

Here comes DefaultSecureProtocols registry into play. For this to be used by SSPI the WinHttpRequest object has to leave grbitEnabledProtocols member of the SCHANNEL_CRED structure empty when calling AcquireCredentialsHandle API and this happens when you *manually* assign .Option(WinHttpRequestOption_SecureProtocols) = 0 in VB6 -- it is not enough to *not* set .Option(WinHttpRequestOption_SecureProtocols) to anything.

With this comes a strategy for TLS 1.2 best effort solution -- test for TLS 1.2 "client-side" availability as it's done at present in your code with  .Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1 Or SecureProtocol_TLS1_1 Or SecureProtocol_TLS1_2 but if this fails just stop and assign .Option(WinHttpRequestOption_SecureProtocols) = 0.

You have to instruct/guide users out-of-band to set DefaultSecureProtocols to 0xA00 (which is exactly SecureProtocol_TLS1_1 Or SecureProtocol_TLS1_2) as *the* permanent solution to TLS 1.2 issues on their machines.

cheers,
</wqw>

----------


## Montclair

> Here comes DefaultSecureProtocols registry into play. For this to be used by SSPI the WinHttpRequest object has to leave grbitEnabledProtocols member of the SCHANNEL_CRED structure empty when calling AcquireCredentialsHandle API and this happens when you *manually* assign .Option(WinHttpRequestOption_SecureProtocols) = 0 in VB6 -- it is not enough to *not* set .Option(WinHttpRequestOption_SecureProtocols) to anything.
> 
> </wqw>


Wow. What a great post!  This was thorough and very well written.  I will try this out on the Vista machine and report my results.  Thanks for the detailed explanation!

----------


## Montclair

Unfortunately, this doesn't work for me.  Setting WinHttpRequestOption_SecureProtocols to 0 initially doesn't get me any connection results at all via WinHTTP.  No matter how long I wait, testing .ResponseText gets me error -2147483638 The data necessary to complete this operation is not yet available.

If I try the others first, descending all the way down to SecureProtocol_TLS1, then set it to 0 as a last resort, I get error -2147012721 A security error occurred.  I've verified that DefaultSecureProtocols is set to 0xA00, and that these are also set:



```
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server]
"DisabledByDefault"=dword:00000000
"Enabled"=dword:00000001
```

So, while this may work on Windows 7, it seems to essentially do nothing on Vista. :Frown:

----------


## wqweto

> So, while this may work on Windows 7, it seems to essentially do nothing on Vista.


True!

Unfortunately KB3140245 (Update to enable TLS 1.1 and TLS 1.2 as default secure protocols in WinHTTP in Windows) is for Win7 only (and is included in Win7 SP1). This fixes the "client-side" validation bug in WinHttp.WinHttpRequest object I'm talking about.

In fact the Server 2008 hacked update you mentioned does slip-stream SSPI DLLs and TLS 1.2 is available from the base APIs and also updating IE to version 9 does bring TLS 1.2 to MSXML2.XMLHTTP. It's the WinHttp that cannot be updated short of randomly copy/pasting the DLL from Win7 and calling regsvr32. . .

I generally always prefer to use MSXML2.XMLHTTP instead of MSXML2.ServerXMLHTTP and WinHttp.WinHttpRequest for one simple reason -- it's a client component while the latter are server components. What this means in practical terms is that ServerXMLHTTP and WinHttpRequest pump messages in some of their syncronous calls while XMLHTTP never does. And this random pumping is *very* dangerous for a client application as it allows re-entrancy in most peculiar ways (the end user can click on the UI while fetching data from internet). While for server apps (think of ASP or any other IIS technology) it does not matter if there is a random DoEvents anywhere in client or system code -- it simply cannot re-enter on the same thread.

cheers,
</wqw>

----------


## Montclair

> In fact the Server 2008 hacked update you mentioned does slip-stream SSPI DLLs and TLS 1.2 is available from the base APIs and also updating IE to version 9 does bring TLS 1.2 to MSXML2.XMLHTTP. It's the WinHttp that cannot be updated short of randomly copy/pasting the DLL from Win7 and calling regsvr32. . .


Not sure how crazy I am about Frankensteining this Vista installation, but knowing me, I might give it a shot.  It would be easier than recoding my application, and it's only for me on this one particular machine anyway. Is it just winhttp.dll that I would need off a Win7 SP1 or later install or are there some other dependencies as well, do you know?  :Confused: 




> I generally always prefer to use MSXML2.XMLHTTP instead of MSXML2.ServerXMLHTTP and WinHttp.WinHttpRequest for one simple reason -- it's a client component while the latter are server components...


That is the only method that will work on Vista with the server 2008 hack applied, and I have verified that per previous posts.  However, that means more code in my actual application to determine which of these methods gets me a connection, then dealing with all that entails based upon what connected.

Regardless, *I must say, you know your sh*t*, and I've learned something from your posts. I thought for sure my installation was screwed up somehow on this Vista box and spent hours and hours trying to get this figured out. Nowhere on the Internet did I find anyone who knew why this didn't work.

Thank you, sir. A++ would interact again.  :Thumb:

----------


## wqweto

I'm currently working on a pure VB6 based WinHttpRequest replacement class based on TLS 1.3 support in VbAsyncSocket project. This will be a source-compatible replacement class that will bring TLS 1.3 (and legacy TLS 1.2) support on all Windows back to NT4.

I'm using this thread to gather requirements kind of :-))

cheers,
</wqw>

----------


## Montclair

Oh wow, that is awesome! I've put myself on the watch list for when that wrapper is implemented.  I suppose making a custom dll  using your library would be trivial so this could be used in VBA for example (in my case Access 97) without having to use the source class modules and re-write whatever incompatibilities exist.  Very very cool!

Last thing from the previous post: In the interim, if I want to try using the Win 7 dlls on this vista installation, do you know what other dependencies I'd need to bring over other than winhttp.dll?  It's okay if you don't.  Thanks again, and great posts!

----------


## wqweto

> Last thing from the previous post: In the interim, if I want to try using the Win 7 dlls on this vista installation, do you know what other dependencies I'd need to bring over other than winhttp.dll?


I didn't try this hack on the Vista VM here (I was speaking only hypothetically) but might try it later if time permits.

cheers,
</wqw>

----------


## tmighty2

> It was, surprisingly, easy to convert my existing code in the actual application to use WinHTTP, which appears to work properly enforcing TLS 1.2 on all calls from XP POSReady and Windows 10 (the OS's where this application will be deployed).
> 
> While this isn't an answer as to why POSReady and XMLServerHTTP calls try to use TLS 1.0 on the first call (despite the registry stating that's not desirable), it is an acceptable workaround.
> 
> For others who may stumble upon this and are hesitant, converting my code was as simple as this:
> 
> 
> 
> ```
> ...


Please show me your declaration of "IMXMLServer".

Thank you!

----------


## Montclair

> Please show me your declaration of "IMXMLServer".
> 
> Thank you!


That's a typo from old code I removed.  Anywhere you see IMXMLServer, it should be XMLServer, which is declared right there.  For example, if using Winhttp, it's this:



```
Set XMLServer = CreateObject("WinHttp.WinHttpRequest.5.1")
```

converted from when I was using MSXML object, which was this:



```
Set XMLServer = CreateObject("Msxml2.ServerXMLHTTP.6.0")
```

I've updated the original post to remove the typos.

As a side note, I've actually re-written the connection routine to detect the version of Windows that's running, and use whatever object will get me TLS 1.2 based on my tests.  It was rather trivial to do this, and I got my code working to get TLS 1.2 on XP, Vista, 7, and 10.

----------


## wqweto

Btw, VbAsyncSocket effort has a pure VB6 implementation for both TLS 1.2 and TLS 1.3 client and server-side support complete with no dependancy on SSPI/Schannel (or openssl) so this should work the same on any Windows since NT4.

cheers,
</wqw>

----------


## Montclair

> Btw, VbAsyncSocket effort has a pure VB6 implementation for both TLS 1.2 and TLS 1.3 client and server-side support complete with no dependancy on SSPI/Schannel (or openssl) so this should work the same on any Windows since NT4.
> 
> cheers,
> </wqw>


You finished it?!  Awesome! Could you post example code that replaces what I've provided here?

----------


## wqweto

Better late than never. 

Just committed the first cut of cHttpRequest class that is a source-compatible WinHttpRequest replacement class which should allow accessing web APIs and web sites using TLS 1.3 using VB6 on everything down to NT 4.0 (incl. XP, Vista and Win7).

It's not 100% complete yes (e.g. no client certificates are implemented) but on your howsmyssl.com test above prints this:




> Content-Length: 925
> Access-Control-Allow-Origin: *
> Connection: close
> Content-Type: application/json
> Date: Tue, 09 Nov 2021 11:39:00 GMT
> Strict-Transport-Security: max-age=631138519; includeSubdomains; preload
> {
> given_cipher_suites: [
> "TLS_AES_128_GCM_SHA256",
> ...


Edit: Client certificates are implemented as of commit 342c4b0.

Edit 2: Everything but SetAutoLogonPolicy method is re-implemented now, incl. http/https proxies support.

In addition cHttpRequest class supports gzip decompression on Win10 and newer which is missing in the original WinHttpRequest object.

cheers,
</wqw>

----------


## Montclair

> Better late than never. 
> 
> Just committed the first cut of cHttpRequest class that is a source-compatible WinHttpRequest replacement class which should allow accessing web APIs and web sites using TLS 1.3 using VB6 on everything down to NT 4.0 (incl. XP, Vista and Win7).</wqw>


Assuming this works, *major kudos to you!*  I'm going to give it a shot today, as I'm having difficulty getting the XP machines to connect to a particular API today, and my original TLS program is also failing on them.  I'll be *thrilled* to get away from Microsoft's API.  I'll report back after I do some testing.  Thank you!!

----------


## Montclair

The only code samples that works for me are \test\BareboneTls\Project1 and \test\BareboneTls\Project3

None of the samples in \test\Secure work and all come back with errors.

Project2 comes back with:  "Error: The message received was unexpected or badly formatted. Handshake failure."

I assume that fails since it uses the native encryption stuff.

Project1 and Project3 come back with:

"Error: The revocation status of the certificate or one of the certificates in the certificate chain is unknown"

Here's the debug window log:

699.060 [INFO] Listening on 127.0.0.1:10443 [Form1.Form_Load]
700.855 [INFO] IpAddress=34.71.45.200 [Form1.m_oSocket_OnResolve]
701.029 [INFO] Using ECDHE-ECDSA-CHACHA20-POLY1305 from www.howsmyssl.com [mdTlsThunks.pvTlsParseHandshakeServerHello]
701.029 [INFO] With exchange group X25519 [mdTlsThunks.pvTlsParseHandshake]
701.034 [INFO] Valid ECDSA_SECP256R1_SHA256 signature [mdTlsThunks.pvTlsSignatureVerify]
701.169 [ERROR] The revocation status of the certificate or one of the certificates in the certificate chain is unknown &H80040000 [Form1.m_oSocket_OnError, cTlsSocket.pvHandleReceive, cTlsSocket.pvPkiCertValidate]

I'm getting similar errors with test\Basic\ projects.

*Edit - Fix Found:*  I spent several hours trying to figure this out and located \lib\ISRG_Root_X1.cer in the project.  Double clicking on it told me it was untrusted and there were options to install the certificate.  Doing that resolved the problems above.

You may want to put that in the README.MD for the project to save people a lot of effort trying to figure out why the code doesn't work.

It would be nice to not have to use that file at all (a lot of this is above my knowledge level so IDK if that's even possible).

I'll do more testing and report back with some sample code if I can generate something that works and is less complex than what I see in the samples.

----------


## Montclair

Wow, dude -- this thing is great!  This is basically a drop in replacement for winhttp, changing Option to Option_ and Method to Method_.  I'm getting TLS1.3 to howmyssl in Windows XP now.  Great job!

I also uninstalled that \lib\ISRG_Root_X1.cer from the PCs certificates.  It isn't necessary to get a TLS connection in my original TLS program.  I basically made 3 edits and the original program works.  It is necessary and must be installed as a trusted certificate to get your samples working though.

I'm impressed.  This was super easy.  Just for anyone else reading this, it's this simple to use:



```
    Dim objhttp As cHttpRequest
    Set objhttp = New cHttpRequest
    objhttp.Open_ "GET", "https://howsmyssl.com/a/check", False
    objhttp.SetRequestHeader "User-Agent", "Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0"
    objhttp.SetRequestHeader "Accept-Encoding", "gzip"
    objhttp.Send
    Debug.Print objhttp.GetAllResponseHeaders
    Debug.Print objhttp.ResponseText
```

----------


## Montclair

I'm running into some kind of parsing error when loading an XML document from an API call using VbAsyncSocket's cHttpRequest.  It's duplicating the first 3389 to 3390 bytes, at least in this test URL.  I sent you a PM on this.

*Edit:* I'm getting all kinds of errors with this, unfortunately.  Incomplete files, empty responses, etc.  I think it's mostly incomplete responses.  I tried this, for example, and only get either 7143 or 8192 bytes:



```
    Dim objhttp As cHttpRequest
    Set objhttp = New cHttpRequest
   
    With objhttp       
        
        'Allow redirects
        .Option_(WinHttpRequestOption_EnableRedirects) = True
        'Enable Https To Http Redirects
        .Option_(WinHttpRequestOption_EnableHttpsToHttpRedirects) = True
        'Enable Http 1.1
        .Option_(WinHttpRequestOption_EnableHttp1_1) = True
        'Ignore all certificate errors
        .Option_(WinHttpRequestOption_SslErrorIgnoreFlags) = SslErrorFlag_Ignore_All
        'Allow 15 seconds for everything to do what it has to do
        .SetTimeouts 15000, 15000, 15000, 15000
        .Open_ "GET", "https://clienttest.ssllabs.com:8443/ssltest/viewMyClient.html", False
        .SetRequestHeader "User-Agent", "Mozilla/5.0 (Windows NT 5.1; rv:31.0) Gecko/20100101 Firefox/31.0"
        .SetRequestHeader "Content-type", "text/html"
        .Send
        Debug.Print "RESPONSE LENGTH: "; Len(.ResponseText)
        Debug.Print "RESPONSE: "; .ResponseText
    End With

    Set objhttp = Nothing
```

If I connect to that using WinHttp, I get a response length of 19571.  You should be able to duplicate the issue with this code.

----------


## wqweto

Yes, this issue must be fixed in commit b4c25fa.

The root certificate for Let's Encrypt CA is missing on XP and it's used as trust anchor for 5-10% of the active TLS certificates nowadays.

There are other root certificates which are missing from XP's root certificate store as the OS is not maintained for quite some time now.

cheers,
</wqw>

----------


## Montclair

Not sure where to continue this -- here or on Github.

Getting Subscript out of Range raised in cHttpReuest's Send subroutine. m_vLastError(1) = cHttpRequest.pvRecvBody

Tracing the code, the error is being generated in pvArrayWriteBlob, with this line being the offender:



```
Call CopyMemory(baArray(lPos), ByVal lPtr, lSize)
```

This happening with a call to the API that I PM'd you about.

lpos = -1, which is causing the error
lptr = 83849144
lsize = 4096

*EDIT:  Issues fixed*
ALL of the issues I reported appear to be fixed by wqweto in the June 4 2022 commits on Github.  Thanks, wqweto!

----------


## Montclair

I'm very happy to report that I was able to create a DLL from wqweto's project, without typing a line of code, and rolled this out to my VBA applications that were using WinHTTP.  I only had to make very minimal changes to them and it works flawlessly. This project of yours is a lifesaver! +1000

----------


## etc6849

Any chance you can share the dll?  Thanks!




> I'm very happy to report that I was able to create a DLL from wqweto's project, without typing a line of code, and rolled this out to my VBA applications that were using WinHTTP.  I only had to make very minimal changes to them and it works flawlessly. This project of yours is a lifesaver! +1000

----------


## wqweto

Just published a compiled DLL under HRR-1.0 tag under releases in the repo, this is not Montclair's DLL but a separate compilation.

The single public multi-use class is named *HttpRequest.cHttpRequest* and this VBScript will use TLS 1.3 all the way down to ancient NT 4.0:



```
Const WinHttpRequestOption_SslErrorIgnoreFlags = 4
Const SslErrorFlag_UnknownCA = 256

With CreateObject("HttpRequest.cHttpRequest")
    .Open_ "GET", "https://www.howsmyssl.com/a/check"
    .Option_(WinHttpRequestOption_SslErrorIgnoreFlags) = SslErrorFlag_UnknownCA
    .Send
    WScript.echo Replace(.ResponseText, ",", vbCrLf)
End With
```




> {"given_cipher_suites":["TLS_AES_128_GCM_SHA256"
> "TLS_AES_256_GCM_SHA384"
> "TLS_CHACHA20_POLY1305_SHA256"
> "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
> "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
> "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
> "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
> "TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256"
> "TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256"
> ...


cheers,
</wqw>

----------


## Montclair

Nice work, wqweto!  Thanks for this!

----------


## therentabrain

OMG thank you so much for this!  

I have a VBS script that works great on newer Windows but not on XP because the server I'm POSTing to requires TLS 1.2+.

I registered the DLL and it began to work right away.  
First the script sends a GET and successfully gets a reply, no problem.
Then the script sends a POST or a DELETE
and when it is successful, which would be a code 204 with no other content, I eventually get a Timeout 80072ee2.
I check the server - the intended action is successful, but the script waits and then errors.

But, when the POST or DELETE successfully reaches the server, and the responds with an error e.g. 403 or 422, because my request is not possible for the server to execute at the moment, the script has no problem immediately telling me so.  No timeout problem for 403s or 422s, which do contain JSON.

Is it possible the DLL isn't handling 204, because it expects 200?
Or is it confused because there is no content?

Is there a way I can get around this?

Thanks again, let me know anything to try.  I'm a noob on github so I thought I'd ask here.  :Smilie:

----------


## therentabrain

For some reason I don't see an edit button, so I'll add here:

FYI The first (GET) request that works perfectly is receiving a 200, with data, as a reply.

----------


## wqweto

> Or is it confused because there is no content?


Could be a problem if 204 does not send *Content-Length* header.

Do you reuse the request object or create a fresh instance on each request?

Edit: Try latest 1.0.2 release for fixed status 204 handling

cheers,
</wqw>

----------


## therentabrain

Amazingness - it works beautifully <3 <3

FTR, I tried both making a new instance and reusing the existing one with the previous DLL, and had the same timeout results.

And now I tried both ways and it worked fine both times.  :Smilie: 

So fwiw it works great in VBScript to retrieve a value from one API, get the values out of a JSON array which comes in called 'data', and then plug it into another API:

(For anyone else poking at it in VBScript, hope this will give some useful clues)



```
Option Explicit

const apioauth = "myoauth"
const clientid = "myclientid"

Dim URL, userid

Const WinHttpRequestOption_SslErrorIgnoreFlags = 4
Const SslErrorFlag_UnknownCA = 256

With createObject("HttpRequest.cHttpRequest")
  URL = "https://xxxxxx/variable=" & WScript.Arguments(1)
  .open_ "GET",URL,false
  .Option_(WinHttpRequestOption_SslErrorIgnoreFlags) = SslErrorFlag_UnknownCA
  .setRequestHeader "Client-Id", clientid
  .setRequestHeader "Authorization", "Bearer " & apioauth
  .send

      msgbox "response: " & .responseText

      Dim y, html : Set html = CreateObject("htmlfile")
      Dim w : Set w = html.parentWindow
      w.execScript "var json=" & .responseText & ";var e=new Enumerator(json.data);", "JScript"
      While Not w.e.atEnd()
          Set y = w.e.item()
          userid=y.id
          w.e.moveNext
      Wend

  URL = "https://xxxxx"
  If WScript.Arguments(0) = 1 Then
    .open_ "POST",URL,false
  Else
    .open_ "DELETE",URL,false
  End If
  .Option_(WinHttpRequestOption_SslErrorIgnoreFlags) = SslErrorFlag_UnknownCA
  .setRequestHeader "Content-Type", "application/x-www-form-urlencoded"
  .setRequestHeader "Authorization", "Bearer " & apioauth
  .setRequestHeader "Client-ID", clientid
  .send "var=value&var=" & userid

  msgbox "response: " & .responseText

End With
```


(Of course a Const OAuth is like a jumbo shrimp, it might be a thing but eh?  ... it's just for testing)

----------

