[Bug]: Initialize-MonkeyHtml: HTML report broken due to jsDelivr 301 redirect not followed

[tranbert]

What happened?
Since a recent change on jsDelivr's side, the HTML report is generated broken. Only the "About Author" section is visible — no data, no CSS, no JS. The error message is:
Initialize-MonkeyHtml : Moved Permanently. Redirecting to /gh/silverhack/monkey365assets@latest/assets/config.json
How to reproduce it

Run Invoke-Monkey365 -IncludeEntraID -ExportTo HTML -OutDir C:\output
HTML report is generated but completely broken (no styling, no data)

Expected behavior
A fully rendered HTML report with charts, findings and styling.
Screenshots or Logs
The root cause is in Initialize-MonkeyHtml.ps1 — the Invoke-WebRequest call in the cdn block does not specify -MaximumRedirection, so PowerShell 5 blocks on the 301 returned by jsDelivr and never gets the actual content.
Fix — add -MaximumRedirection 5 to both Invoke-WebRequest calls in Initialize-MonkeyHtml.ps1:
powershell$content = Invoke-WebRequest -Uri $baseUrl -UseBasicParsing -MaximumRedirection 5
From where are you running Monkey365?

Resource: workstation
OS: Windows
PowerShell Version: 5.1
Monkey365 Version: 0.97
Others: N/A

Additional context
The URL https://cdn.jsdelivr.net/gh/silverhack/monkey365assets@latest/assets/config.json now returns 301 before 200. Adding -MaximumRedirection 5 to the Invoke-WebRequest calls fixes the issue. Same fix needed in the localcdn block a few lines below in the same file.

[silverhack]

Hi @tranbert thanks for reporting this. It's really appreciated.

Just saw it yesterday while testing some new features. Initially I assumed it was a local connectivity problem, but the same issue occurred in a new pipeline I'm working on. The global uptime of jsDelivr was 100% according to their status page (https://status.jsdelivr.com/?start=20260509&end=20260509), so honestly I have no idea what’s causing these redirection issues.

I’ll review those requests and implement a more robust error handling for the Invoke-WebRequest calls.

Thanks :)

[tranbert]

Also found a related issue in Convert-UrlToJsDelivr.ps1 — the $absolutePath variable includes a leading slash, which combined with the URL format string produces a double slash in the generated URL (e.g. @latest//assets/config.json).
Fix:
powershell$absolutePath = ($Url -split $repository)[1].TrimStart("/")

[silverhack]

Got it thanks! I'll add a separate issue to review all double-slash in URLs.

Just to mention that you can enable the legacy mode or serving those assets via a controlled server if you're experiencing issues with JsDelivr.

https://silverhack.github.io/monkey365/exporting/export-html/#exporting-options

Heavily tested JsDelivr today with zero issues.

Cheers

[tranbert]

OK fine, and thanks for all you do.

[silverhack]

Hi @tranbert thanks again for pointing me in the right direction. It looks like the problem is specifically tied to using the latest version in jsDelivr URLs.

When I use explicit versions, such as the main or develop branches, tagged release, etc.., everything works as expected. The redirect behavior only appears when latest is used. I've created separated issues #180 and #179 and if everything is going OK, the plan is to publish a new release of Monkey365 by the end of the week.

Thanks again, :)

[tranbert]

You're welcome !

[silverhack]

Fixed in latest release https://github.com/silverhack/monkey365/releases/tag/v0.98

[silverhack]

Hey @tranbert Apologies, I forgot to include you in the release notes.

Fixed now!

Thanks,