Yeah. If I put an HTTPSocket on a Window and call the URL it has the HeadersReceived event fires with the new Location.
I just tried the Kaju test app (Mac 64-bit) without issue, fwiw.
With a 301 or 302?
I suspect there’s an issue with the SSL certificate on the website we’re using.
Just to add to this conversation I am working on some minor tweaks to Kaju which I will submit a pull request for. I am switching the HTTPSocket’s to the new Xojo.Net.HTTPSocket for two reasons:
- I want the app to check for updates asynchronously so as not to lock up the app while checking.
- I need the update checker to follow SSL redirects so that updates and the JSON can be used behind SSL.
Sounds good, I’m happy to take a look.
Alright. I sell a significant number of packages on Amazon on CD. The big issue some of the users are utterly unable to download themselves. So I am going to try and implement Kaju for on CD software.
I am sure I will have questions very soon 
I just tried the test app on Windows 10 with 2016R3.
When I check I get the update page, but then all I get is a beep when I click anywhere.
After quitting, I get
An error has occured. Would you like to try again now or later ?
The update data cannot be read - Webkit HTMLViewer is not currently supported for 64-bit
Note that I cannot build in 64 bit anyway.
After clicking Try Again, I get the update page, and again the same error. After another Try again, I was able to download the update.
Now I get “The downloaded file appears to be corrupted” 
I don’t recall when WebKit was made 64-bit compatible, but there was a point when it wasn’t. I’ve no idea why you’d see that message if you’re not compiling in 64-bit though.
To be sure, compile the test app in 32-bit and try it that way. Running through the ide doesn’t work right.
I did compile 32 bits. That’s why I was wondering.
Are you using the latest version of the project?
I got it from the git.
I could use some advice for the next version…
Right now, you can create a background image in one of two ways: you can specify it within the app, or you can specify a URL to download the image for a version, but this was done in the days before hi-res was common.
Modifying the former is easy. Instead of giving Kaju an image, you can give it an image set and Xojo will do the right thing. I’m updating the test app accordingly.
The latter is trickier because you don’t know if the user is using hi-res or not, so here are the choices:
- Allow you to specify an ImageURL (same as now) and Image2xURL, which will be optional. If only ImageURL is specified, the behavior won’t change. If only Image2xURL is specified, it will be scaled. If both are specified, the ImageURL dimensions will be used and an image set created.
- Keep just ImageURL and specify a Scale key, assumed to be 1 for backwards compatibility. You can specify any number and the image dimensions will be calculated within Kaju.
The advantage of (1) is that you might get better looking images on each type of screen, but the software will have to download each image whether it needs it or not.
The advantage of (2) is simplicity but you are relying on Xojo to scale the image where needed.
Thoughts? Preferences?
I was given the advice “do the simplest thing”, and I think that’s sound. The simplest is to introduce the “Scale” key. Eventually most people will be on hi-res and we won’t have to worry about it anyway.
simplest and most straight forward path is the best way to go.
So I’ve finally gotten an SSL certificate for my main websites. Now Kaju (I think the current version still uses 1.x) complains about an incorrect packet marker on this code here:
dim sig as string = firstLine.Left( Kaju.kUpdatePacketMarker.Len )
if StrComp( sig, Kaju.kUpdatePacketMarker, 0 ) <> 0 then
if HandleError( KajuLocale.kErrorIncorrectPacketMarker ) then
continue do
else
exit do
end if
end if
When checking the result there is a 301 redirect. The problem is that all old versions now will have the same hissy fit. Is there something I can do on my website to fix this?
Just so I understand the situation…
Your app points to http://path/to/update which returned the update information. Now it wants to redirect to https://path/to/update but AllowRedirect is set to false in the app so it’s not following it. Is that it?
The only thing you can do is make sure the current url returns the update information and put a new url into the new version that uses the certificate. Also turn on AllowRedirect to prevent this in the future.
Yes, you understood correctly. AllowRedirect is set to false. Most likely I never thought I would have to use this property.
The support from my hosting company told me to remove the automatic redirect from http to https and then muck around with the htaccess file myself and then exclude the update file. Perhaps I’ll try this tomorrow.
I’m curious because I’m thinking of changing that default to True instead…
Did you intentionally set it to false, or did you just let it use the default? If the latter, was that intentional, or did you just ignore it?
My original thinking was about security, but now I see that this situation can become common if users didn’t know or think about that property.
BTW, the develop branch contains new code around the new framework HTTPSocket, and that does not give you the option, it will always follow redirects.
I just never noticed this property.