vscode-resource domain name has '+' in domain name, which is illegal domain name

[rrelyea]

Type: Bug

Attempting to get a webview extension going, where the hosted web framework attempts to create a URI object based on the base url of the extension. Because it appears like the URL starts with:
"https://file+.vscode-resource.vscode-cdn.net"

The scenario fails. And the web framework throws an exception during its startup.
It doesn't appear that I have a workaround.

Can VSCode please be changed to use a valid domain name?

VS Code version: Code 1.72.0 (64bbfbf, 2022-10-04T23:20:39.912Z)
OS version: Windows_NT x64 10.0.22623
Modes:
Sandboxed: No

System Info

Item	Value
CPUs	Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz (8 x 2112)
GPU Status	2d_canvas: enabled canvas_oop_rasterization: disabled_off direct_rendering_display_compositor: disabled_off_ok gpu_compositing: enabled multiple_raster_threads: enabled_on opengl: enabled_on rasterization: enabled raw_draw: disabled_off_ok skia_renderer: enabled_on video_decode: enabled video_encode: enabled vulkan: disabled_off webgl: enabled webgl2: enabled webgpu: disabled_off
Load (avg)	undefined
Memory (System)	15.92GB (6.38GB free)
Process Argv	--crash-reporter-id c6e09d46-8681-47b7-b5c2-e121c3326b3f
Screen Reader	no
VM	0%

Extensions (21)

Extension	Author (truncated)	Version
vcard	cst	1.0.1
vscode-eslint	dba	2.2.6
EditorConfig	Edi	0.16.4
resxformatter	gir	1.0.1
vscode-pull-request-github	Git	0.50.0
blazorwasm-companion	ms-	1.1.0
csharp	ms-	1.25.0
vscode-dotnet-runtime	ms-	1.5.0
python	ms-	2022.16.0
vscode-pylance	ms-	2022.10.10
jupyter	ms-	2022.9.1002791758
jupyter-keymap	ms-	1.0.0
jupyter-renderers	ms-	1.0.10
vscode-jupyter-cell-tags	ms-	0.1.6
vscode-jupyter-slideshow	ms-	0.1.5
remote-wsl	ms-	0.72.0
powershell	ms-	2022.8.5
vscode-typescript-next	ms-	4.9.20221007
remote-vscode	raf	1.1.0
cors-browser	Wsc	1.0.11
t4-support	zbe	0.6.0

[mjbvz]

Seems like a valid url to me:

// Doesn't throw 
new URL('https://file+.vscode-resource.vscode-cdn.net')

And I don't see it in the forbidden code points for hosts: https://url.spec.whatwg.org/#host-miscellaneous

Are you sure it's not just a problem with the framework you are using?

[rrelyea]

RFC 1178 - Choosing a Name for Your Computer says:

      Don't use non-alphanumeric characters in a name.

         Your own computer may handle punctuation or control characters
         in a name, but most others do not.  If you ever expect to
         connect your computer to a heterogeneous network, you can count
         on a variety of interpretations of non-alphanumeric characters
         in names.  Network conventions on this are surprisingly
         nonstandard.

RFC1035 - Domain names - implementation and specification says:

The following syntax will result in fewer problems with many

applications that use domain names (e.g., mail, TELNET).

<domain> ::= <subdomain> | " "

<subdomain> ::= <label> | <subdomain> "." <label>

<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]

<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>

<let-dig-hyp> ::= <let-dig> | "-"

<let-dig> ::= <letter> | <digit>

<letter> ::= any one of the 52 alphabetic characters A through Z in
upper case and a through z in lower case

<digit> ::= any one of the ten digits 0 through 9

Note that while upper and lower case letters are allowed in domain
names, no significance is attached to the case.  That is, two names with
the same spelling but different case are to be treated as if identical.

The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less.

C#/WebAssembly runs into problems too:
In C#:
var uri = new Uri("https://file+.vscode-resource.vscode-cdn.net");

The following exception is thrown:

System.UriFormatException
  Message=Invalid URI: The hostname could not be parsed.
  Source=System.Private.Uri
  StackTrace:
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind, UriCreationOptions& creationOptions)
   at System.Uri..ctor(String uriString)

(also happens if we replace the '+' with '%2B')

[mjbvz]

These are valid uris afaik. They may not be valid internet host names, but that's not relevant for how VS Code uses them. Plus here is an important delimiter for information that we encode in the uri, so it is also not possible for us to easily switch to names that only use a-z and numbers as you suggest

Can you workaround the issue by not parsing these uris?

[rrelyea]

The web framework (blazor) includes support for navigation so it needs the base url.

A blazor app cannot run without trying to create that uri. You have several issues asking for support of blazor written webviews.

Could you more easily replace '+' with '-'?

[rrelyea]

Good question about valid URIs.
Seems like the URI specs allow looseness of definition, but then say that people using DNS should follow certain rules.

From above

If you ever expect to
         connect your computer to a heterogeneous network, you can count
         on a variety of interpretations of non-alphanumeric characters
         in names. 

I would imagine, that could be rewritten as...
if you ever expect your URI to be processed by different software systems, choosing a URI that allows for most interoperability would be recommended

Below, you'll see that the URI spec allows a +, but also says it depends on the name lookup technology that will be used. Using a domain name, like you are, seems like DNS system would be used. If so they specific a syntax without those subdelimiters in the hostname:

RFC3986 - Uniform Resource Identifier (URI): Generic Syntax

host        = IP-literal / IPv4address / reg-name
reg-name    = *( unreserved / pct-encoded / sub-delims )
   sub-delims    = "!" / "$" / "&" / "'" / "(" / ")"
                 / "*" / "+" / "," / ";" / "="

A host identified by a registered name is a sequence of characters
   usually intended for lookup within a locally defined host or service
   name registry, though the URI's scheme-specific semantics may require
   that a specific registry (or fixed name table) be used instead.  The
   most common name registry mechanism is the Domain Name System (DNS).
   A registered name intended for lookup in the DNS uses the syntax
   defined in [Section 3.5 of [RFC1034]](https://www.rfc-editor.org/rfc/rfc1034#section-3.5) 
   and [Section 2.1 of [RFC1123]](https://www.rfc-editor.org/rfc/rfc1123#section-2.1).
   Such a name consists of a sequence of domain labels separated by ".",
   each domain label starting and ending with an alphanumeric character
   and possibly also containing "-" characters.  The rightmost domain
   label of a fully qualified domain name in DNS may be followed by a
   single "." and should be if it is necessary to distinguish between
   the complete domain name and some local domain.

[mjbvz]

This sounds like a framework specific problem so without a compelling, simple, and complete suggestion on how to fix this, this is not something we are going to change in VS Code

The host you are seeing is constructed as http://SCHEME+AUTHORITY.vscode-resource.... where scheme and authority come from the original resources being loaded We can't use - as - is a valid character in both the scheme and authority. That's why we chose + as the separator

[rrelyea]

Will continue to look at your encoding of scheme+authority here to come up with good options:
webview.ts

Will also reach out to colleagues from dotnet, blazor, etc... to understand options in other components, etc.

[rrelyea]

Currently investigating 'SCHEME.AUTHORITY' instead of 'SCHEME+AUTHORITY'

Since AUTHORITY could be blank, we would need a well known string that serves as "NO-AUTHORITY".
(would love feedback on any problems you see with the approach while I investigate its feasibility)

Update: the period delimiter solution appears to work well. Unblocked me for now with private build. Will try to finalize fix and submit as PR for consideration in the next couple of weeks.

[rrelyea]

In this fork: https://github.com/rrelyea/vscode, I have fixes in 5 files for this, so far. It appears to work well.

Reasonable for me to spend time running all tests and submitting a PR?
Other guidance?

[mjbvz]

@rrelyea Yep sounds good. Thanks for taking a look!

For testing, besides testing a local workspace try a remote workspach such as ssh, wsl, or contains. These should load resources from a virtual filesystem with an authority (whereas file doesn't have any authority)

[StephenWeatherford]

@rrelyea What become of this? Was it ever submitted as a PR? We have a similar issue Azure/bicep#11467. Thx

[rrelyea]

Never submitted as PR. Ended up not being a blocking issue for me.

[groogiam]

@rrelyea

Never submitted as PR. Ended up not being a blocking issue for me.

Were you able to get this working in wasm without a custom VS Code build? Thanks.

[rrelyea]

Been a long time, so I don't recall. You could look here: https://github.com/[rrelyea/vscode-webview-blazor](https://github.com/rrelyea/vscode-webview-blazor)