Incorrect W3C namespace in XML is allowed

[miicah]

<svg xmlns="https://www.w3.org/2000/svg" viewBox="0 0 100 100">
  <path d="M30,1h40l29,29v40l-29,29h-40l-29-29v-40z" stroke="#000" fill="none"/> 
  <path d="M31,3h38l28,28v38l-28,28h-38l-28-28v-38z" fill="#a23"/> 
  <text x="50" y="68" font-size="48" fill="#FFF" text-anchor="middle"><![CDATA[410]]></text>
</svg>

Copy the above into the sanitiser and you will see the correct SVG. However when loading on an actual webpage, having the W3C XML namespace pointing to https will cause the SVG to fail to load.

[verdy-p]

URI in namespaces are not supposed to be loaded by the SVG client parser or any XML parser (so replacing http by https will not avoid any security risk). They are just used as unique identifiers and are recognized only for their exact documented values. But there may be a non-standard "tolerance" in the parser for such replacement, now that there are multiple SVG specifications and versions.

The referenced content of the URI does not matter: it could be any document, in any MIME type, or could even stop resolving or return an HTTP 404 or 500 error from the remote server, this should not impact the SVG renderer (but it may be useful for some SVG creators or designers to get relevant documentation or recommendations: it willeb up to the final creator to decide what to do with that content if they visit it with a web browser, which could even block loading the referenced document in case the remote server is compromized, but should not block rendering the SVG referencing the same URI).

The data model need to process the document should be internally bound to this URI by the SVG processor (which should know by default that exact URI), or by local custom rules if one wants to limit the rendering, or to introduce local security/administrative restrictions, or to allow some non-standard extensions for the root XML namespace or in custom XML namespaces, or to provide compatiblity across different SVG specifications or usage profiles.