samskivert
commented
5 years ago I think that's because this whole approach to downloading a special getdown.txt via appbase_override that is actually not valid per the (global) digest.txt is kind of a hack. In the code that redownloads the special getdown.txt it then revalidates that new getdown.txt against the latest digest.txt and if it does not validate, then it basically ignores it.
So if you see getdown.txt failed to validate even after redownloading... in an error message, that means Getdown is ignoring the downloaded file and just using what it has (possibly with an overridden appbase URL, which maybe makes things mostly work).
Unfortunately it's not safe to just use the invalid getdown.txt because we rely on the secure hash of the file being valid to ensure that we don't try to use a file that failed to download properly or which was hijacked by some intermediary.
As I mentioned earlier, the only "really correct" way to do what was talked about in issue 77 is to have the web server generate a custom getdown.txt and digest.txt on the fly with correct contents.
It's possible that there are simpler features that could be added to Getdown to enable something like this to work without having to rely on it mostly working even when the digest fails, but I don't know exactly what they are and I have zero time to add random features to Getdown for random people. If someone wants to make a pull request, I can review it and get it merged.
Somewhat odd one this. Seem to have -appbase_override working (as per issue #77) and a fresh getdown.txt is pulled down rather than the existing one. But it looks like the app launch is using the -jvmarg values from the original getdown.txt on disc rather than the newly fetched one from the server.