CreateWebResourceResponse with content-encoding gzip

[stefan1000]

Hi,

we are trying to directly pass gz encoded data via CreateWebResourceResponse by adding a header Content-Encoding: gzip and setting the gz content as payload.

In request headers there is no accepted encoding header, just passing Content-Encoding results in garbage results...

Are we doing something wrong or are those things not possible ?

[novac42]

Hi @stefan1000 could you please provide some more information about this?

• Framework (WinUI, Win32, WinForms, UWP, WPF, etc)
• SDK and Runtime version
• Operating System

[stefan1000]

Using Win32 C++ API like

std::wstring headers;
headers = L"content-type: application/json; charset=utf-8\r\ncontent-encoding: gzip\r\ncache-control: no-store, no-cache";

if (SUCCEEDED(m_Environment->CreateWebResourceResponse(stream.get(), 200, L"OK", headers.c_str(), &response)))
...

SDK 1.0.1722.4 Runtime 114.0.1823.67 Windows 10 22H2 x64

[ray007]

Same problem here with .NET. Tried setting Accept-Encoding on the request headers, but didn't help. So for now I send the output stream through an additional GzipStream to decompress.

[AshleyScirra]

I think I just ran in to this. I want to create a response using deflate compressed data. If I add Content-Encoding: deflate to the HTTP headers and pass compressed data as the response data, it looks like WebView2 does not attempt to decompress it. For example if returning a compressed HTML document, it just loads the compressed data as text, which just produces garbage text on-screen.

It looks like WebView2's requests do not include an Accept-Encoding header when intercepted with AddWebResourceRequestedFilter. Perhaps that's the problem - if WebView2 is not telling the server it accepts compressed data, then maybe it won't attempt to decompress anything the server responds with. The 'Accepted content-encodings' field in network conditions in devtools doesn't appear to affect anything.

Any chance this could get looked at soon?