Relative download url in appcast.xml no longer works

[jamesweston]

The example appcast below works in 2.3.0 but no longer in 3.0 I get the following error in the logs "netsparkle: Unable to generate download temp file name; was the app cast set up properly with a download link?" If i change the enclosure url from enclosure url="Client_Setup_1.2.exe" to enclosure url="./Client_Setup_1.2.exe" it will download correctly in 3.0 is this expected behaviour?

Sample Appcast

<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:sparkle="http://www.andymatuschak.org/xml-namespaces/sparkle">
  <channel>
    <title>Test Client</title>
    <description>Most recent changes with links to updates</description>
    <language>en</language>
    <item>
      <title>Test 1.2</title>
      <pubDate>Wed, 05 Feb 2025 13:37:53 +00:00</pubDate>
      <sparkle:version>1.2</sparkle:version>
      <sparkle:shortVersionString>1.2</sparkle:shortVersionString>
      <enclosure url="Client_Setup_1.2.exe" sparkle:version="1.2" sparkle:shortVersionString="1.2" length="39820904" sparkle:os="windows" type="application/octet-stream" sparkle:criticalUpdate="false" sparkle:signature="removed" />
    </item>
  </channel>
</rss>

The real appcast is created with netsparkle-generate-appcast -n "Software Name Client" -b $releasePath -a $releasePath

[jamesweston]

I have updated my deployment scripts to now add . at the start of the enclosure url for the client appcasts and client updates are working again. I would guess a change has been made to how GetAbsoluteURL within NetSparkle is getting applied.

[Deadpikle]

Yes, this seems like a regression to me at first glance. Won't have time to look into a fix for a few days. Glad there is a workaround. Thanks very much for reporting. :-)

[jamesweston]

This issue has caused some more problems where a v2.x.x netsparkle client can download an update with enclosure url="Client_Setup_1.2.exe" but v3.x.x cannot and with enclosure url="./Client_Setup_1.2.exe" v3.x.x netsparkle can download but a v2.x.x client cannot.

So far my testing has shown what removing theif (item.DownloadLink.StartsWith("..") || item.DownloadLink.StartsWith(".")) check from within GetDownloadPathForAppCastItem allows both Client_Setup_1.2.exe and ./Client_Setup_1.2.exe to pass through to Utilities.GetAbsoluteURL instead of the current behaviour where GetDownloadPathForAppCastItem returns null for Client_Setup_1.2.exe when called for downloadTempFileName = await GetDownloadPathForAppCastItem(item); but I don’t know if removing the check for .. and . will have further impact somewhere else.

[Deadpikle]

I see the issue, yes. Thanks for the update.

I still won't have time to dig really deep into this for several more days, sorry. #399 was the original issue for the ../. stuff, and it was fixed in #620. So this lib needs to be compatible with ../ URLs and ./ URLs and filename.exe type URLs.

Interestingly, since the .. and . check was in addition to previous checks, presumably this would have only added capabilities to that func from 2.x, not broken anything that was previously working, so I am suspicious that the culprit might actually be somewhere else: commit 5ec3e6b, specifically. Note how before code was moved into XMLAppCastGenerator, some code in AppCastItem existed for modifying the download link if there was no full URL in the download link. (5ec3e6b#diff-0d3dcf848177ff1fd75ee4571f3cd81af3eb90f467460c7afcbb137f56a43b15L243 -- if link doesn't work, line 244 of the changes of AppCastItem). I believe that is the code that has gone "poof" in 3.x that is affecting the behavior, here.

So why did I do that? At a glance, probably because castUrl was no longer available.

Adding similar code to GetDownloadPathForAppCastItem that was removed from AppCastItem and not brought into the generators may be the best way to move forward? (In other words, code like this line: newAppCastItem.DownloadLink = castUrl.Substring(0, castUrl.LastIndexOf('/') + 1) + newAppCastItem.DownloadLink;) This is my gut reaction, but it's very late here and I'm out of time to think more on this. But, that should fix the issue regardless of app cast generator. So, the fix should be a simple if check in GetDownloadPathForAppCastItem with the URL fixing as needed. (May not be the best fix, but it would be a fix.)

A workaround, I think, would be to use TmpDownloadFileNameWithExtension and download to a custom file name rather than relying on the server. Or include the full download URL in the app cast.

[jamesweston]

Thanks for the update no worries about not having time. This is what i ended up doing in my fork for testing if it's any help jamesweston@d9d084d