Support to request extensions://** by HttpClient

[newbe36524]

Is your feature request related to a problem? Please describe.

When I try to develop a browser extension by blazor. I have to fetch some resources hosts in extensions://* protocol by HttpClient.

But it throw a exception like:

blazor.webassembly.js:1 crit: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
      Unhandled exception rendering component: Only 'http', 'https', and 'blob' schemes are allowed. (Parameter 'requestUri')
System.ArgumentException: Only 'http', 'https', and 'blob' schemes are allowed. (Parameter 'requestUri')
   at System.Net.Http.HttpRequestMessage.InitializeValues(HttpMethod method, Uri requestUri)
   at System.Net.Http.HttpRequestMessage..ctor(HttpMethod method, Uri requestUri)
   at System.Net.Http.HttpClient.CreateRequestMessage(HttpMethod method, Uri uri)
   at System.Net.Http.HttpClient.GetStreamAsync(Uri requestUri, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.GetStreamAsync(Uri requestUri)
   at System.Net.Http.HttpClient.GetStreamAsync(String requestUri)
   at Newbe.Blazors.TryNet.Pages.Index.Compile(String text, MetadataReference[] additionalReferences) in D:\Repo\newbe\Newbe.Demo\src\BlogDemos\Newbe.Blazor\Newbe.Blazors.TryNet\Newbe.Blazors.TryNet\Pages\Index.cs:line 64
   at Newbe.Blazors.TryNet.Pages.Index.CompileAndEncode(String text, MetadataReference[] additionalReferences) in D:\Repo\newbe\Newbe.Demo\src\BlogDemos\Newbe.Blazor\Newbe.Blazors.TryNet\Newbe.Blazors.TryNet\Pages\Index.cs:line 49
   at Newbe.Blazors.TryNet.Pages.Index.OnClickRunAsync() in D:\Repo\newbe\Newbe.Demo\src\BlogDemos\Newbe.Blazor\Newbe.Blazors.TryNet\Newbe.Blazors.TryNet\Pages\Index.cs:line 86
   at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task)
   at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle)

Describe the solution you'd like

A clear and concise description of what you want to happen. Include any alternative solutions you've considered.

Please allow some additional schema like 'extensions' by some Property in HttpClient class.

[javiercn]

@newbe36524 thanks for contacting us.

This is a question for the dotnet/runtime folks

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Is your feature request related to a problem? Please describe.

When I try to develop a browser extension by blazor. I have to fetch some resources hosts in extensions://* protocol by HttpClient.

But it throw a exception like:

blazor.webassembly.js:1 crit: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
      Unhandled exception rendering component: Only 'http', 'https', and 'blob' schemes are allowed. (Parameter 'requestUri')
System.ArgumentException: Only 'http', 'https', and 'blob' schemes are allowed. (Parameter 'requestUri')
   at System.Net.Http.HttpRequestMessage.InitializeValues(HttpMethod method, Uri requestUri)
   at System.Net.Http.HttpRequestMessage..ctor(HttpMethod method, Uri requestUri)
   at System.Net.Http.HttpClient.CreateRequestMessage(HttpMethod method, Uri uri)
   at System.Net.Http.HttpClient.GetStreamAsync(Uri requestUri, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.GetStreamAsync(Uri requestUri)
   at System.Net.Http.HttpClient.GetStreamAsync(String requestUri)
   at Newbe.Blazors.TryNet.Pages.Index.Compile(String text, MetadataReference[] additionalReferences) in D:\Repo\newbe\Newbe.Demo\src\BlogDemos\Newbe.Blazor\Newbe.Blazors.TryNet\Newbe.Blazors.TryNet\Pages\Index.cs:line 64
   at Newbe.Blazors.TryNet.Pages.Index.CompileAndEncode(String text, MetadataReference[] additionalReferences) in D:\Repo\newbe\Newbe.Demo\src\BlogDemos\Newbe.Blazor\Newbe.Blazors.TryNet\Newbe.Blazors.TryNet\Pages\Index.cs:line 49
   at Newbe.Blazors.TryNet.Pages.Index.OnClickRunAsync() in D:\Repo\newbe\Newbe.Demo\src\BlogDemos\Newbe.Blazor\Newbe.Blazors.TryNet\Newbe.Blazors.TryNet\Pages\Index.cs:line 86
   at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task)
   at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle)

Describe the solution you'd like

A clear and concise description of what you want to happen. Include any alternative solutions you've considered.

Please allow some additional schema like 'extensions' by some Property in HttpClient class.

Author:	newbe36524
Assignees:	-
Labels:	area-System.Net, untriaged
Milestone:	-

[karelz]

@newbe36524 what is "extensions://* protocol"? I never heard of that. What does it do? What's the protocol?

As the exception says, HttpClient does not support it -- even Uri does not support it.
Is it something that JavaScript / WebAssembly natively support? If yes, then it would be feature request for .NET WebAssembly I assume ...

[ghost]

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Is your feature request related to a problem? Please describe.

When I try to develop a browser extension by blazor. I have to fetch some resources hosts in extensions://* protocol by HttpClient.

But it throw a exception like:

blazor.webassembly.js:1 crit: Microsoft.AspNetCore.Components.WebAssembly.Rendering.WebAssemblyRenderer[100]
      Unhandled exception rendering component: Only 'http', 'https', and 'blob' schemes are allowed. (Parameter 'requestUri')
System.ArgumentException: Only 'http', 'https', and 'blob' schemes are allowed. (Parameter 'requestUri')
   at System.Net.Http.HttpRequestMessage.InitializeValues(HttpMethod method, Uri requestUri)
   at System.Net.Http.HttpRequestMessage..ctor(HttpMethod method, Uri requestUri)
   at System.Net.Http.HttpClient.CreateRequestMessage(HttpMethod method, Uri uri)
   at System.Net.Http.HttpClient.GetStreamAsync(Uri requestUri, CancellationToken cancellationToken)
   at System.Net.Http.HttpClient.GetStreamAsync(Uri requestUri)
   at System.Net.Http.HttpClient.GetStreamAsync(String requestUri)
   at Newbe.Blazors.TryNet.Pages.Index.Compile(String text, MetadataReference[] additionalReferences) in D:\Repo\newbe\Newbe.Demo\src\BlogDemos\Newbe.Blazor\Newbe.Blazors.TryNet\Newbe.Blazors.TryNet\Pages\Index.cs:line 64
   at Newbe.Blazors.TryNet.Pages.Index.CompileAndEncode(String text, MetadataReference[] additionalReferences) in D:\Repo\newbe\Newbe.Demo\src\BlogDemos\Newbe.Blazor\Newbe.Blazors.TryNet\Newbe.Blazors.TryNet\Pages\Index.cs:line 49
   at Newbe.Blazors.TryNet.Pages.Index.OnClickRunAsync() in D:\Repo\newbe\Newbe.Demo\src\BlogDemos\Newbe.Blazor\Newbe.Blazors.TryNet\Newbe.Blazors.TryNet\Pages\Index.cs:line 86
   at Microsoft.AspNetCore.Components.ComponentBase.CallStateHasChangedOnAsyncCompletion(Task task)
   at Microsoft.AspNetCore.Components.RenderTree.Renderer.GetErrorHandledTask(Task taskToHandle)

Describe the solution you'd like

A clear and concise description of what you want to happen. Include any alternative solutions you've considered.

Please allow some additional schema like 'extensions' by some Property in HttpClient class.

Author:	newbe36524
Assignees:	-
Labels:	arch-wasm, area-System.Net, untriaged
Milestone:	-

[newbe36524]

@newbe36524 what is "extensions://* protocol"? I never heard of that. What does it do? What's the protocol?

As the exception says, HttpClient does not support it -- even Uri does not support it.
Is it something that JavaScript / WebAssembly natively support? If yes, then it would be feature request for .NET WebAssembly I assume ...

I can develop a chrome extension by Blazor WebAssembly. just like this project https://github.com/newbe36524/Amazing-Favorites.

In this way, I can using C# to build a chrome extensions.

However, if I want to request a resource such as extension://gglgheekopdecoeeinlggdmedamjbjpj/sample.json by HttpClient. The exception raised

[newbe36524]

Actually, I try to port a Blazor WebAssembly project from hosted style into to chrome extension style. But block by if I want to send a request with extensions://* protocol since all files is host in extensions folder instead of a web server.
It will throw a exception by HttpClient as the code below:

https://github.com/BlazorRepl/BlazorRepl/blob/master/Core/CompilationService.cs#L233

[karelz]

It is still not clear to me what is the "extensions://*" protocol? Is it just HTTP? Or something else?
How does JavaScript or something else communicate with such endpoints?

That will answer the question if it is something HttpClient in WebAssembly might want to support or not.

[newbe36524]

It is still not clear to me what is the "extensions://*" protocol? Is it just HTTP? Or something else?
How does JavaScript or something else communicate with such endpoints?

That will answer the question if it is something HttpClient in WebAssembly might want to support or not.

Just like http but they are real files hosted by browser extensions and target to browser extensions folder.
Take edge as a example.
I open extensions

click any one of backgroud page of a extensions

dev tool will show as below, and refresh dev tools by F5, you can find networks details, and open anyone of them that target to chrome-extensions:// and "open it in new tab", you could find url with extensions://*

For MS Edge, They are some files place at C:\Users[User]\AppData\Local\Microsoft\Edge\User Data\Default\Extensions[ExtenstionId][version]

[BenLampson]

It is still not clear to me what is the "extensions://*" protocol? Is it just HTTP? Or something else?
How does JavaScript or something else communicate with such endpoints?

That will answer the question if it is something HttpClient in WebAssembly might want to support or not.

The extensions://* is chrome or the chromium system's private "extends manager protocol"
it's full string is : chrome-extension://<extensionID>/<pathToFile>
extensionID is target extendsid,
path to file is the relative path about the extends folder.

You can think that is chromium's private file protocol, like file:\.....

[wfurt]

It seems inappropriate for generic framework like .NET HttpClient to worry about other product private guts. It seems like some kind of external package would be much more appropriate.

[newbe36524]

@wfurt In fact now, I am limited by this line of code because its requirements must be within the given range.

runtime/src/libraries/System.Net.Http/src/System/Net/Http/HttpClient.cs

Line 810 in ab4e593

if (!HttpUtilities.IsHttpUri(baseAddress))

I'm curious if it's possible to change this behavior by way of dependency injection or other options to be able to support wider or narrower scopes, rather than using this hard-coded approach.
The rest doesn't need to be modified.
This check is currently bypassed in my project by reflection, which works but does not seem elegant and efficient.
https://github.com/newbe36524/Newbe.Demo/blob/feature/blazor/src/BlogDemos/Newbe.Blazor/Newbe.Blazors.TryNet/Newbe.Blazors.TryNet/Pages/Index.cs#L67

[scalablecory]

@newbe36524 I believe that is only checked if you set BaseUri. If you give an absolute Uri in your HttpRequestMessage, does that solve your problem?

CC @marek-safar @kjpou1 @lewing we should consider if it makes sense to explicitly support things like this for browser.

[MihaZupan]

The check is also in HttpRequestMessage which will reject any Uri scheme except for:
http, https, ws, wss and (for browser) blob.

[wfurt]

If this boils down to schema check only, I think we could loosen the restriction for wasm.

[newbe36524]

@scalablecory Yeah, just as @MihaZupan mentioned, for now, it block me in HttpClient.BaseUri and HttpRequestMessage.Uri, and even WebRequest.Create.
So there is no way for me to send that request to the schema in C# class. I must skip the checking by reflection as I metioned above.

[geoffkizer]

If this boils down to schema check only, I think we could loosen the restriction for wasm.

Yeah, I'm not sure what the point of checking this in HttpClient/HttpRequestMessage themselves is.

The underlying HttpClientHandler will enforce whatever schemes it knows how to handle. Limiting this at the HttpClient/HttpRequestMessage layer seems unnecessary.

[karelz]

Triage: We agree that HttpClient/HttpRequestMessage should not do any schema validation. We already have blob for wasm.
Let's keep the check only in Handler.

[karelz]

@stephentoub what do you think?

[newbe36524]

Hi, friends, any update? I wonder that would it be ok in next net 6 preview or not?

[wfurt]

AFIK It is too late for preview 6 @newbe36524. We agreed this may make sense but it is not on top of the priority list.

[davidfowl]

Would a pull request be accepted?

[karelz]

Yes, we would take a PR.

@stephentoub do you have opinion on the plan?

[stephentoub]

@stephentoub do you have opinion on the plan?

As long as all of our handlers do the appropriate validation for what they're capable of, removing such validation from HttpClient / HttpRequestMessage sounds like the right thing to do.