Yeah. If I put an HTTPSocket on a Window and call the URL it has the HeadersReceived event fires with the new Location.
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 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 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:
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.
@Kem T 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.