Code I have used for years has just started to die
Ive tracked it down to checking the status code returned by an httpsocket
I always checked for code 200 - all OK
Suddenly its getting 301, assuming no website, and bombing out.
Does 301 mean ‘I cant find your stuff’, or should I treat it as ‘all OK, stuff just isnt where you thought it was’ , and carry on regardless?
HTTP status 301 indicates that the resource has moved permanently to a new URL. The new URL is sent as the Location header in the response headers.
Sub HeadersReceived(headers as internetHeaders, httpStatus as integer)
If HTTPStatus = 301 Then
Dim url As String = headers.CommaSeparatedValues("Location")
Me.Get(url)
End If
End SubHow would you do this synchronously?
If I do this:
dim h as new HTTPSocket
h.yield = true
dim aboutweb , thefile as string
aboutweb = "https://mywebsite.com/index.html"
thefile = h.Get(aboutweb1, 6)
then I get a code of 301, and thefile holds a message saying permanent redirect, not the actual data.
I cant find any property of the httpsocket that exposes a working
CommaSeparatedValues(“Location”)
msgbox h.requestHeaders.CommaSeparatedValues("Location")
gives an empty string
http://documentation.xojo.com/api/deprecated/httpsocket.html#httpsocket-pageheaders
You need the Response (pageHeaders) instead of the Request headers (requestHeaders)
Nope.
A browser opens the page.
An http socket just gives me a 301 code and no apparent way to get to ‘the right place’
This has happened due to cloudflare or caching or something by my provider, who refuse to help me with my socket issues because ‘the actual website’ works properly so they feel their work is done
Any reason you’re not using URLConnection which handles redirects automatically?
Yep.
never heard of it. 
Now that I have, I note that Im using 2018 r3 and it came in in 2018r4
I dont like to move up Xojo versions unless there is a gun to my head.
For example, for my desktop stuff, 2018r3 has been fine, but I was forced to used 2021 for iOS
I’ll look into URLConnection and spend a day setting up 2018r4 to see if it breaks anything.
Is the Location header missing?
Dim url As String = myHTTPSocket.PageHeaders.CommaSeparatedValues("Location")
dim h as new HTTPSocket
h.yield = true
dim aboutweb , thefile as string
aboutweb = "https://mywebsite.com/index.html"
While true
thefile = h.Get(aboutweb1, 6)
If h.httpstatus = 301 or h.httpstatus = 302 then
AboutWeb = h.responseheader("Location")
Continue
End if
Exit
Wend
This should do it… mind you I typed this from memory…
It should be noted though that it’s entirely possible that this redirect is to force you to use HTTPS in which case this still isn’t going to work because HTTPSocket doesn’t support that.
This might be a good time to update that code to URLConnection because you’ll get all this for free
dim h as new URLConnection
dim aboutweb , thefile as string
aboutweb = "https://mywebsite.com/index.html"
thefile = h.sendSync("GET", aboutweb, 60)yes, by the looks of it.
Im kinda tied here.
I think it may be that Im being forced to the https version of the site.
If HTTPSocket doesnt do it, what does in pre-2018r4 ?
HTTPSecureSocket sounds like it ought to be the answer, but …
I wonder of CurlsMBS might be the way to go
(without forcing me to upgrade my Windows environment to 2018r4 which introduces all sorts of DLL and graphics issues I also want to avoid)
Seems like a good answer to me, especially if making the same request using HTTPS succeeds.
There’s also my open source libcurl binding which is designed to be compatible as far back as RS2011r4.3. Either way, curl is always a better choice than the built-in Xojo socketry if you need to replicate web browser-like behavior (redirects, cookies, etc.)
Random fact: 2011r4.3 was the last RS version that could (with coaxing) produce single-file exe’s for Windows. Of course using curl in any form will introduce several dlls your app will depend on.
Im getting a 102 error when I do that.
Im getting old.
(Remember when we used to be able to fix our own cars?)
When I set up my original website, you uploaded a bunch of HTML pages via FTP , registered a name, and set up a DNS entry so people could find it.
Easy
Now, (like everything), its all wrapped up in layer after layer of guff.
LetsEncrypt has been added so the pages appear as https:
Cloudflare gets in there and says ‘come to me’
NGINX does page caching
And apparently there is a difference between
mywebsite.com and www.mywebsite.com
which ‘something’ is resolving somewhere.
All of which leads me to ’ I know where my pages are supposed to be, but I dont know where my pages actually are’.
Browsers seem fine with this… the site works - so support people wont speak to me about anything else.
Ive been told to speak to ‘the developer’. (Thats me)
HTTP Socket gets me 301 with no location header
HTTPSecureSocket gets me error 102 with every variation of page address I can think of.
(I suspect ‘the truth’ will turn our to be cloudflare.com.mysite or something)
CurlsMBS finds the file and reports the file size.
Thats progress, I just havent been able to access the content yet. 
Try fiddling with the SSL/TLS version. Many servers on the net are configured to refuse connections that use TLSv1.0 and older (due to the “Heartbleed” bug in OpenSSL), but HTTPSecureSocket uses TLSv1.0 as its default.
You’re right that it used to be simpler, but thanks to abuse, it’s not anymore. There’s no use complaining about it.
Modern HTTP communication really, really should be done with CURL via MBS or with URLConnection. The original HTTPSocket (and the HTTPSecureSocket) are just Xojo code you could write yourself. They can only handle HTTP 1.0, which more and more servers are deciding to not support. We’re moving into HTTP 3 for the record. As mentioned TLS is also an issue. Servers should not be accepting TLS 1.0 connections anymore, nor any of the SSL versions. You don’t need to worry about this stuff with a socket that can keep up with standards. HTTPSocket is ancient and it’s no surprise you’re running into trouble.
Your options are not fantastic here. URLConnection will be most similar to your existing code. It was designed that way intentionally, but its usage is only similar, not identical. The downside is URLConnection uses system libraries to do its work, which basically means you’ll get a nice reliable socket on macOS, but on Windows… well WinHTTP kind of sucks. CURLNMBS will behave exactly the same on all platforms, but its usage is not similar to HTTPSocket at all and there will be trouble adapting.
URLConnection requiring a newer Xojo may be the deciding factor, but sticking with an old version of anything will not work forever. This may be one of those cases.
Edit: Oh I forgot to mention that HTTPSecureSocket with ConnectionType set to TLSv12 will probably get you connected in the short term. But consider your code on borrowed time. Make a plan for migrating to newer classes so you can make the change on your schedule. If you stay with HTTPSecureSocket, you will be bitten again in the future. It’s only a matter of time, and you don’t want to be scrambling for a fix when it happens.
Just as an example of why I prefer to hang on to ‘a version I know’, for my main app I code in 2018 on the Mac but take the code and compile using 2015 on my PC, even though I can build for Windows on the Mac
The 2015-compiled 32bit windows app uses 100K of memory when it runs.
The same code, compiled to 32bit using Xojo 2018 on the mac, immediately grabs over 2Gb memory when it runs. I cant live with that.
Im going through the same pain now that dozens of Kaju users reported in the middle of this thread from 2019
I can resolve my short term issues by switching traffic to my ‘backup’ website , and making use of CurlsMBS
I absolutely understand. The devil you know is better than the devil you don’t. Updating the IDE brings with it bugs and changes that you don’t know. Changes might at least be predictable if you were to read through all those release notes, but new bugs are pretty much impossible. So I do the same thing, only updating my IDE when releasing a new major version. I can’t fault you for not wanting to update immediately.
But you can’t stay with an old version forever. For example, you’re sacrificing native Apple Silicon support by not updating. At the moment, that’s not such a big deal, but it’ll become a bigger issue with each passing month as more and more users upgrade and Apple eventually pulls the plug on Rosetta. And of course, all the unknown possibilities in the future that could make updating necessary.
So all I’m saying is to find your short term solution, but it’s probably getting time for a version update and you should include that in your plans.
No, I am up to date.
If I want to build for Silicon, I can.
I just don’t choose to use anything newer because I don’t want anything after 2015 on Windows.
Cross Platform is a pain to juggle.
That type of issue should never be the case IMO in an Xplatform product for non UI things … REALbasic used to be more concerned about such things…
-Karen