HttpSecureSocket issue

This is probably an error between keyboard and chair but have to ask. I use using HTTPSecureSocket to get a “salt” for encryption from a website. When I past the URL into Firefox/Chrome/etc it works perfectly. Everytime. When I use Insomia (like PAW but on Windows - not as slick but similar), it works perfectly every time.

When I use Xojo, I dont get anything back from the website. zero bytes.

dim strURL as string = self.kURLBase + "getsalt.json" + "?email_or_username=" + userID
dim h as new HTTPSecureSocket
h.Secure=true
h.ConnectionType=h.TLSv12
h.SetRequestHeader("User-Agent:", "curl/7.21.0 (i686-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18")
dim str as string
str = h.get( strURL,60 )

userID is equal to “the_sboss” in the test case.

str is always empty.
LastErrorCode is 102
mErroCode is 0
_httpStatusCode is 0
_pageComplete is True
_pageheaders is NIL
_totalLength is 0
_processingURL is https://keybase.io/_/api/1.0/getsalt.json?email_or_username=the_sboss

I started with much more complicated code and stripped it down to the above code and get no where.

Any pointers/advice would be appreciated.

sb

Have you tried Xojo.Net.HTTPSocket to see if you get different results?

I have not tried the new framework. I will try it next. Why not.

I have think I can make the new framework work. it is much much more complicated than the old framework. Is there ever going to be synchronous requests in the new framework? I have to pause my application because I cant do anything until I get the response back from the API.

why does the new framework work but not the old one? what is the big difference?

Synchronous requests lock up your app, so I hope they never allow that again.

The big difference is HTTP 1.0 in the old framework HTTP 1.1 in the new.

You can make the new socket appear to be synchronous to your application with just a little work by subclassing the socket.

for some of us, we have to lock up the app as we cant do anything at all until the API replies. If we do anything until the API replies, we get blocked from the API. So synchronous would be PERFECT in this case.

that is good to know. that is probably the issue at hand.

I’m not just talking about preventing other code from running.

The UI locks up, and the app becomes “not responding” to the OS.
This is bad user experience.

If you’re heart-set on it though, I believe there’s a class around that makes the old framework HTTPSocket respond to servers as if it’s HTTP 1.1. You might be able to use it to get a synchronous HTTPSocket that the server will talk to.

the last time I used the new framework for the HTTP*Socket I got myself locked out of the API. The enterprise APIs I normally work with are very sensitive until you have completed the authentication process. (2-3 synchronous calls to the API - the API documentation states to do synchronous calls vs async). Once you have gone through those steps, then you can make calls as you wish to the API. if your IP address does any API calls before you finish the 2-3 step process, they block your IP address from the API for 15-30 minutes (depends on which API). Then they extend it another 15-30 minutes per call until you are authenticated. One of my IPs for my desktop (I was issued a couple due to this issue - that I switch between) is blocked until thanksgiving day.

So yeah I understand aync gives a better UX but I have to disable every control anyways when using this locked down APIs until after I do the synchronous calls (or async with a bunch of timers) to get the APIs unlocked.

If you think that is bad, the in-house written APIs are worse.

I will have to go this route.

thanks everyone.