XMLNS URL For Salesforce Custom Tag Declarations Needs To Be Changed To 'https'

[Richman7]

Everywhere Salesforce generates an XML file, the declaration of the parent custom tag is pointed at a URL that defines the declarations of these custom tags that (mostly?) doesn't include the 's'. The result is that XML tools (VS Code/XML plugin) cannot find the declarations, and raise an error. Here is an example from the CustomLabels xml file:
<CustomLabels xmlns="http://soap.sforce.com/2006/04/metadata">

When the URL is changed to https, it does successfully find the declarations:
<CustomLabels xmlns="https://soap.sforce.com/2006/04/metadata">

Suggested fix: Everywhere Salesforce generates XML files, ensure that the URL includes https.

[github-actions]

Hello @Richman7 👋 It looks like you didn't include the full Salesforce CLI version information in your issue.
Please provide the output of version --verbose --json for the CLI you're using (sf or sfdx).

A few more things to check:

• Make sure you've provided detailed steps to reproduce your issue.
  • A repository that clearly demonstrates the bug is ideal.
• Make sure you've installed the latest version of Salesforce CLI. (docs)
  • Better yet, try the rc or nightly versions. (docs)
• Try running the doctor command to diagnose common issues.
• Search GitHub for existing related issues.

Thank you!

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[Richman7]

Below is the CLI version info, as requested. The CLI version is controlled by the client, so we are a few versions behind. However, I searched for similar issues, and was unable to locate any, so the version shouldn't have an impact until a fix is implemented.

{
  "cliVersion": "@salesforce/cli/1.86.7-legacy.0",  
  "architecture": "win32-x64",
  "nodeVersion": "node-v18.15.0",
  "osVersion": "Windows_NT 10.0.19045",
  "shell": "cmd.exe",
  "rootPath": "C:\\Program Files\\sfdx\\client\\sf",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 2.3.1 (core)",      
    "@oclif/plugin-commands 2.2.17 (core)",
    "@oclif/plugin-help 5.2.11 (core)",
    "@oclif/plugin-not-found 2.3.26 (core)",        
    "@oclif/plugin-plugins 3.1.6 (core)",
    "@oclif/plugin-search 0.0.18 (core)",
    "@oclif/plugin-update 3.1.22 (core)",
    "@oclif/plugin-version 1.3.6 (core)",
    "@oclif/plugin-warn-if-update-available 2.0.41 (core)",
    "@oclif/plugin-which 2.2.22 (core)",
    "@salesforce/cli 1.86.7-legacy.0 (core)",
    "apex 2.3.4 (core)",
    "auth 2.8.4 (core)",
    "data 2.4.5 (core)",
    "deploy-retrieve 1.13.5 (core)",
    "info 2.6.30 (core)",
    "limits 2.3.23 (core)",
    "login 1.2.15 (core)",
    "org 2.9.19 (core)",
    "schema 2.3.17 (core)",
    "settings 1.4.17 (core)",
    "sobject 0.1.32 (core)",
    "source 2.10.22 (core)",
    "telemetry 2.2.1 (core)",
    "templates 55.5.2 (core)",
    "trust 2.4.27 (core)",
    "user 2.3.20 (core)"
  ]
}

[github-actions]

Hello @Richman7 👋

It looks like you're using an outdated version of Salesforce CLI. sf (v1) is in "maintenance mode" as of July 12, 2023. We highly recommend you move from sf (v1) to sf (v2) ASAP.

Moving to sf (v2) is easy and takes just two commands. Find all the information here.

After you move to the latest version of sf (v2), run your command again and provide the output of sf version --verbose --json.

[Richman7]

Adding version from another machine with the latest version, and confirmed that a retrieval of the CustomLabels metadata resulted in the same output as identified.

{
  "architecture": "darwin-x64",
  "cliVersion": "@salesforce/cli/2.69.14",
  "nodeVersion": "node-v22.11.0",
  "osVersion": "Darwin 24.1.0",
  "rootPath": "/Users/richard.peute/.local/share/sf/client/2.69.14-c6442ee",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.11 (core)",
    "@oclif/plugin-commands 4.1.12 (core)",
    "@oclif/plugin-help 6.2.18 (core)",
    "@oclif/plugin-not-found 3.2.29 (core)",
    "@oclif/plugin-plugins 5.4.19 (core)",
    "@oclif/plugin-search 1.2.16 (core)",
    "@oclif/plugin-update 4.6.14 (core)",
    "@oclif/plugin-version 2.2.16 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.24 (core)",
    "@oclif/plugin-which 3.2.19 (core)",
    "@salesforce/cli 2.69.14 (core)",
    "apex 3.6.6 (core)",
    "api 1.3.2 (core)",
    "auth 3.6.78 (core)",
    "data 3.12.3 (core)",
    "deploy-retrieve 3.15.17 (core)",
    "info 3.4.25 (core)",
    "limits 3.3.42 (core)",
    "marketplace 1.3.7 (core)",
    "org 5.2.7 (core)",
    "packaging 2.9.5 (core)",
    "schema 3.3.43 (core)",
    "settings 2.4.8 (core)",
    "sobject 1.4.46 (core)",
    "telemetry 3.6.26 (core)",
    "templates 56.3.33 (core)",
    "trust 3.7.45 (core)",
    "user 3.6.4 (core)",
    "@salesforce/sfdx-scanner 4.7.0 (user) published 43 days ago (Tue Oct 29 2024)"
  ]
}

[iowillhoit]

Hello @Richman7, this is not something that we will be able to correct. Even if we changed the url in the CLI generated files, the server will still create these files with the http endpoint. The CLI team does not have any control over files generated from the server.

However, I believe this error you are seeing can be configured within the Redhat XML vscode extension with the following setting:

[Richman7]

I was sincerely hoping that disabling/bypassing validation is not the fix.

Do you know what team in Salesforce is in charge of the functionality of generating the XML? I always assumed since the CLI can convert between mdapi and source, that it was the CLI doing this, but I'll gladly address this with the team that has direct control over this.

[iowillhoit]

Sorry I don't have a better answer for you. I don't know which team this would be. You are welcome to open a Salesforce Support Case to try to get redirected to them.

If I had to guess, this will be a difficult thing to get changed since a URI to valid schema is not the goal of these namespaces

It is not a goal that it be directly usable for retrieval of a schema

(source)

[Richman7]

Adding a potentially better solution to allowing the Redhat XML plugin in VS Code to validate against the Salesforce schema as available through the https variant of the namespace URI, instead of suppressing the validation.

There are a few ways to go about this, but using a catalog file seemed to be the most consistent solution between a Mac and a Windows machine. See documentation for full details and alternate solutions.

The catalog solution is a two-step process:

1. Create a catalog.xml file using the below content, and save it somewhere (can be a user folder, instead of directly in a project))

<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
    <uri
        name="http://soap.sforce.com/2006/04/metadata"
        uri="https://soap.sforce.com/2006/04/metadata" />
</catalog>

2. Register the catalog.xml file in the vscode 'settings.json' like this, replacing '/path/to/' with the path to the file as appropriate for your OS:

"xml.catalogs": [
    "/path/to/catalog.xml"
]

[iowillhoit]

Very cool @Richman7, thank you for digging into this and providing a better workaround 💯