Cannot set Content-type header in CoreWebView2WebResourceRequest

[myxply]

I am trying to do a simple call with custom headers:
var request = webView.CoreWebView2.Environment.CreateWebResourceRequest("http://localhost", "POST", null, "Content-Type: application/x-www-form-urlencoded\r\nContent-length: 50");
webView.CoreWebView2.NavigateWithWebResourceRequest(request);

However, the Content-Type header is always ignored and doesn't show up in request.Headers. I've tried specifying only this header in the string, and it still doesn't work. I've also tried using the debugger to set it with SetHeader, and "Content-type" doesn't add to the collection. I can call SetHeader("test","testval") and it shows up. "Content-length" does work. I really need content-type for my application. I've tried WebVeiw2 versions 1.0.705.50 through 1.0.824-prerelease and the behavior is the same.
Am I doing something wrong or is this a bug? In my real code, I would replace the MemoryStream with something real instead of passing in null, though that makes no difference in terms of this issue occurring.
In my real application, I'd actually be setting Content-Type to multipart-mime like this:
Content-Type: multipart/form-data; boundary=---------------------------

AB#32294343

[champnic]

Hey @myxply - thanks for the bug report! I've verified the behavior locally. It doesn't have to do specifically with "Content-Type", but instead it seems our code misses the first header in the list. If you put something before the "Content-Type" header it shows up fine, for example:
var req = env.CreateWebResourceRequest("http:\\localhost", "POST", null, "Hi: 8\r\nContent-Length: application/x-www-form-urlencoded\r\n");

Then I see the Content-Type header:

It also looks like this only affects our .NET controls. For Win32 the example string you provided gave the expected result.

I've opened this bug on our backlog and we'll get it fixed. Thanks!

[myxply]

Thanks! I was able to follow this example to get both content-length and content-type to show up in the headers by putting a dummy one before both of them. Once this bug is fixed I will try out without the workaround.

[myxply]

An update...it looks to me like whatever headers you set are just not showing up in the debugger. When the request is actually sent to the server, the custom header is there even if you only supply one of them.
However, the real reason my requests were never making it to the server was because I was trying to include Content-length. If you do that, you get an error page from the browser control and it never makes it to the server (ERR_INVALID_ARGUMENT). Content-length seems to be set correctly and automatically by the browser control though.

[champnic]

This is fixed in 1.0.902-prerelease SDK. Thanks!