I’m also very interested in this topic. With the additional extended 3rd party apps this will happen more frequently (power bi for me this month). The only solution i have found for this (not ideal) is to use the pre-cache wizard to verify i have all the fixlets cached ahead of the patch cycle. Recently though i am getting an error “unable to parse action script line 1: Prefetch command syntax error: You will need to fix this error before issuing the action.” This has something to do with the firefox fixlets (yes, i have firefox whitelisted). I have to remove all the firefox fixlets from my baseline before i can run the wizard. Again, this is not ideal. Hoping there’s a setting that will allow the baseline to move forward after x attempts to download.
@LouC can you tell me which fixlets / which sites, and whether this is still an issue? I am aware of one case that was raised on this but I believe it has been resolved.
Yes, it’s still an issue. These are the firefox fixlets (Updates for Windows Applications) i have in my baseline:
Mozilla Firefox 109.0 Available
Mozilla Firefox 110.0 Available
Mozilla Firefox (x64) 109.0 Available
Mozilla Firefox (x64) 110.0 Available
Getting a little off-topic here, but what version is your “Updates for Windows Applications” site? I’m on version 1911 and not seeing a problem when I action those fixlets.
I’m on the same version. You can run the “File Pre-Cache Wizard” against a baseline with those fixlets in it?
Doing some further testing… if i disable “Require SHA-256 Downloads” in the Admin tool then when i run the “File Pre-Cache Wizard” I don’t get that error… but all the downloads fail with “Unexpected HTTP response: 404 Not Found”. This is my DownloadWhitelist entry for firefox:
I’ve moved this to a new topic…
From the Console, can you copy & paste one of the actual download links that’s failing here? Since this is four different fixlets and each fixlet can choose from several downloads of different languages I want to be sure I’m trying the same.
All of the downloads appear to have the sha256 parameters, I’m having some trouble reproducing this behavior.
Oh! - the precache wizard…lemme look into that
Ok, I do see a problem with at least fixlet 6081958 “Mozilla Firefox (x64) 109.0 Available” when run through the File Precache Wizard. I’ve opened an internal bug on it because I don’t see this issue reported by anyone else.
If you want to open your own support case to track resolution on it, let me know and I’ll give you the bug ID they should attach to your case. Otherwise I’ll let you know when I hear some progress on it.
I’ll just wait to hear back from you. Thanks for taking the time to look into this.
I’m checking with Dev on this, but it may turn out to be a limitation on the precache wizard itself in dealing with these Dynamic Downloads for FireFox.
Rather than publishing 17 different fixlets for each FireFox version to cover the 17 languages, we have one fixlet that determines which language is installed and only downloads that language file. This download is performed inside a Relevance Substitution block to prevent the Server and Relays from downloading all 17 language files.
At present the Precache Wizard doesn’t appear to handle the case that the original download is inside a Relevance Substitution, where the %2520 string is meant to represent the percent-encoded literal %20 in the download URL, and the Wizard is passing that string along directly as the new literal download URL.
I had at first thought the issue was with some extra spacing characters in the Firefox fixlets, but now it may be that the Precache Wizard can’t handle these relevance-substitution downloads. The original Firefox fixlets do work, it’s just the Precache Wizard that appears limited.
Yes, i’ve been successfully installing firefox all these months, I just couldn’t figure out why I couldn’t pre-cache them via the wizard like I used to. Hopefully this gets addressed in a future release. Thanks for digging into it.
Ok, the feedback I’m getting is that the File Pre-Cache Wizard never handled the FireFox download links. The issue is that those links are inside of a relevance substitution, which should be evaluated on the client itself (this way the client only downloads the specific language-version that it needs).
Inside the relevance substitution, the URL download strings are percent-encoded, as necessary when defining the string in Relevance. In all the places where the literal URL needs a space, the space is URL-encoded to the ‘%20’ symbol to represent a space; and then further Relevance percent-encoded to ‘%2522’ to represent “literal percent-symbol followed by 22”. The File Pre-Cache Wizard does not perform the relevance substitutions on the URL and tries to include the literal %25 as part of the URL, so it’s a bad download link.
It’s not clear whether the File Precache Wizard could be enhanced to handle every case of relevance substitutions (since those should be done on the client, and conceivably could have things like ‘OS’ or installed application checks), but maybe these very trivial substitutions could be handled in some cases.
I’ve added an Idea at https://bigfix-ideas.hcltechsw.com/ideas/BFP-I-365 to enhance the precache wizard to try to handle those URLs. Please upvote if this is important to you.