HTTPSecureSocket error code on some adresses


i bumped into some error accesing some url adresses on the web. error 102 and some error 400.

i just do :

myHttps = new HTTPSecureSocket
myHttps.Secure = True
myHttps.ConnectionType = SSLSocket.SSLv23

and i uses web pages adresses. usually works good. except on one case :
return error 102.

plus in general, if i send a xojo forum link like :
i have a error 400, bad request
so i’m wondering in general what’s the difference when webkit sends a request to a request send by httpsocket ? do i have to send headers, user agent or something ?

SSL version 2/3 is over 10 years old and newer servers don’t accept it any more.
Please use TLS 1.2.

[quote=387487:@Christian Schmitz]SSL version 2/3 is over 10 years old and newer servers don’t accept it any more.
Please use TLS 1.2.[/quote]
SSLv23 is actually a “negotiated” connection mode that will start with TLS and work it’s way down until it finds one that works.

My guess is that they require a user-agent header to make them think you’re a browser.

[quote=387487:@Christian Schmitz]SSL version 2/3 is over 10 years old and newer servers don’t accept it any more.
Please use TLS 1.2.[/quote]

I used .ConnectionType = SSLSocket.SSLv23 because it says in the doc :

A TLS/SSL connection established with this constant may understand the SSLv3, TLSv1, TLSv1.1 and TLSv1.2 protocols.

yes well didn’t find how make the request work yet.

i tried the link

in a sample xojo app, still error 102.

i use Paw to test get/post http apis, and Paw can get the page. so i examined the headers of paw and copy them in xojo :

raw headers in paw :

GET /Debats/Chroniques/guerre-mort-culture-contre-lart-2018-05-02-1200935951 HTTP/1.1
Cookie: device_view=full; lcx_read_articles=%5B1200935951%5D
Connection: close
User-Agent: Paw/3.1.6 (Macintosh; OS X/10.13.4) GCDHTTPRequest

in xojo :
DataSocket.SetRequestHeader(“User-Agent”,“Paw/3.1.6 (Macintosh; OS X/10.13.4) GCDHTTPRequest”)

i’ve noticed that in xojo there is 2 more headers at first
Accept : /
Accept-Language en

so i tried to remov them and and only what is needed, still doesn’t work.

so technically, do browser send other infos others that that ?

Did you try my MBS Xojo CURL Plugin with CURLSMBS class?
It may show more details in debug log.

And it allows to use a client side SSL certificate.

yes lol just done that before seeing your messagte:), just did it it worked. i just paste into the example
“CURLS get and put web” my probematic url :

dim c as new CURLSMBS
c.OptionURL = “
c.CollectDebugData = True
c.CollectOutputData = true



and boom without any more settings i had the html result ! :slight_smile:

yes maybe it’s time for curl :wink:

What is reported in debug data property?

Connected to ( port 443 (#0)
ALPN, offering http/1.1
TLSv1.2 (OUT), TLS handshake, Client hello (1):
TLSv1.2 (IN), TLS handshake, Server hello (2):
TLSv1.2 (IN), TLS handshake, Certificate (11):
TLSv1.2 (IN), TLS handshake, Server key exchange (12):
TLSv1.2 (IN), TLS handshake, Server finished (14):
TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
TLSv1.2 (OUT), TLS change cipher, Client hello (1):
TLSv1.2 (OUT), TLS handshake, Finished (20):
TLSv1.2 (IN), TLS handshake, Finished (20):
SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
ALPN, server accepted to use http/1.1
Server certificate:
subject: OU=Domain Control Validated; OU=PositiveSSL Multi-Domain;
start date: Sep 20 00:00:00 2017 GMT
expire date: Sep 20 23:59:59 2019 GMT
issuer: C=FR; ST=Paris; L=Paris; O=Gandi; CN=Gandi Standard SSL CA 2
SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
GET /Debats/Chroniques/guerre-mort-culture-contre-lart-2018-05-02-1200935951 HTTP/1.1
Accept: /

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Access-Control-Allow-Origin: *
Cache-Control: no-cache
Cache-Control: no-cache
Date: Sun, 13 May 2018 22:00:37 GMT
Server: Apache
Set-Cookie: lcx_read_articles=%5B1200935951%5D; expires=Mon, 14-May-2018 22:00:37 GMT; Max-Age=86400; path=/; httponly
Set-Cookie: device_view=full; expires=Wed, 13-Jun-2018 22:00:00 GMT; Max-Age=2678363; path=/; httponly
Strict-Transport-Security: max-age=63072000;
X-Front: 1
Vary: Accept-Encoding
X-Cache: Miss from cloudfront
Via: 1.1 (CloudFront)
X-Amz-Cf-Id: Z071nDFaKFfpDRBAkmhfZAWmd5IcwkB7fD6xfy8R7DEj0LRQYJusKQ==

Connection #0 to host left intact

I’ve tested the two urls with the classic HTTPSecureSocket:

1 Like

thanks a lot for those explanation, by the way if you are on the mac side, what are the tools to see those types of information ? thx

Yes, I’m using macOS. Most tests I do with curl from the Terminal. To mimic what the HTTPSecureSocket is doing, I start with parameters like the following:

curl --head --location --http1.0 --tls-max 1.2 --ipv4 --verbose --insecure

Here does --insecure / -k disable the SNI extension, tls-max mimics the SSLv23. In my tests, --tlsv1.2 and --tlsv1.1 seem broken and imply --tlsv1.0 but --tlsv1 / -1 may be worth a try.
Further comparing the traffic a browser, curl and the Xojo Socket produces with Wireshark can help to track down several issues.

1 Like

just to say that today I too have got the same problem (HTTPSecureSocket error code 102).