home
                                
                                 home copied to clipboard
                                
                                    home copied to clipboard
                            
                            
                            
                        Package Validator not validating URL's
What You Are Seeing?
The Package Validator is failing on the webview2-runtime package for the projectUrl, even though it is valid from my side.
This looks to be related to #60.
What is Expected?
The projectUrl is not flagged as invalid.
How Did You Get This To Happen? (Steps to Reproduce)
N/A.
System Details
N/A
Output Log
N/A
┆Issue is synchronized with this Gitlab issue by Unito
Hey @pauby ,
I own this package and it failed the automated process because of the package validator complaining about the DocsUrl in the nuspec. Unfortunately, i see nothing wrong with it and i'm pretty much blocked with my package from getting new versions now.
https://community.chocolatey.org/packages/mongodb-compass-isolated/1.31.1
Just to flesh out what @TraGicCode reported there, this appears to be impacting all of the MongoDB Compass packages (which reference the same docs URL):
Package affected:
URLs affected:
- https://docs.mongodb.com/compass/current/
Checking that URL locally, it loads "fine" but does have a couple of 401 responses while it's loading.

Looks like we have another candidate as well 😢
- puppet-agent - https://community.chocolatey.org/packages/puppet-agent/7.16.0
This URL is failing to validate correctly:
- https://puppet.com/puppet/puppet-open-source/
Another package:
URLS:
- https://www.deepl.com/translator
- https://www.deepl.com/en/pro-license?tab=free
Package:
- https://community.chocolatey.org/packages/deepl/3.5.25837
And another:
URL: https://www.binance.com/en/terms Package: https://community.chocolatey.org/packages/binance/1.36.0
Still present for this too : https://community.chocolatey.org/packages/binance/1.41.0 URL: https://www.binance.com/en/terms
Another package: https://community.chocolatey.org/packages/AdobeAIR/33.1.1.932 Failing URL: https://airsdk.harman.com/runtime
Another package: https://community.chocolatey.org/packages/deepl/4.0.6052 Failing URLs: https://www.deepl.com/translator and https://www.deepl.com/en/pro-license?tab=free
Slack may be hitting the same issue: https://community.chocolatey.org/packages/slack/4.34.115
Same issue for Microsoft Edge browser package and the  ProjectUrl: https://community.chocolatey.org/packages/microsoft-edge last three versions, e.g. https://community.chocolatey.org/packages/microsoft-edge/118.0.2088.46. Have re-submitted for validation (https://community.chocolatey.org/packages/microsoft-edge/118.0.2088.61), but same results.
URL in question is https://www.microsoft.com/en-us/edge and checking it I get a couple of redirects (302/301), but ultimately a HTTP 200 response (the final URL being https://www.microsoft.com/en-us/edge?ep=0&es=27&form=MA13FJ).
Have the same problem with Office365 https://community.chocolatey.org/packages/Office365Business/16731.20354 Affected URL: https://www.microsoft.com/en-us/microsoft-365
The package is currently broken for some time now, Microsoft deletes old installer version once a new one is released, so I've been getting comments from angry people for days.
ProjectUrl for https://community.chocolatey.org/packages/microsoft-teams and https://community.chocolatey.org/packages/microsoft-teams.install is now hitting this.
The URL being flagged is https://www.microsoft.com/en-us/microsoft-teams/group-chat-software which is legit
https://www.gnu.org/licenses/lgpl-3.0.html getting flagged from https://community.chocolatey.org/packages/mmsstv/1.13.1
Same for https://cdn.statically.io/gh/subsurface/subsurface/master/icons/subsurface-icon.png at https://community.chocolatey.org/packages/subsurface/6.0.5038
UPDATE This may be an interesting observation:
The initial upload of Subsurface 6.0.5038 had an incorrect iconUrl which was correctly flagged by validation testing. I fixed this and pushed the corrected package twice containing the previously mentioned correct iconUrl. Nevertheless, iconUrl continued to be flagged as invalid.
I suspected a caching issue, so pushed a new package Subsurface 6.0.5053 with the same iconUrl. As expected, validation testing passed on this one although iconUrl remained unchanged vs the corrected 6.0.5038 packages...
@schlotter I reran the validation on the failing package, and it is passing now. It was caused by caching, where the previously pushed .nupkg was still in the website cache when the test was rerun. Now that some hours have passed, a rerun passes, because the more recent correct .nupkg is used in the test.
This package version's DocsUrl is also affected. The URL works fine here.
Same for this Thebrain.install It was for the Docurl, but even by removing it, it still fails
Another package:
URLS:
- https://www.deepl.com/translator
- https://www.deepl.com/en/pro-license?tab=free
Package:
- https://community.chocolatey.org/packages/deepl/3.5.25837
Hello, I'd say every version of deepl since ... i don't remember ;-)
Work has been completed concerning this issue, and we have decided to downgrade this rule from a Requirement to a Note.
This will allow packages going through moderation as normal, but requires extra attention to validate the URLs being flagged manually.