Hi,
I’m attempting to use gzip requests/responses with UnityWebRequest using:
currentRequest.SetRequestHeader("Accept-Encoding", "gzip");
which returns
Message:Cannot set Request Header Accept-Encoding - name contains illegal characters or is not user-overridable Source:UnityEngine TargetSite: Void SetRequestHeader(System.String, System.String)
Are there any work arounds for this problem?
Your problem is that “Accept-Encoding” is a forbidden header name and cannot be set. I advice you to switch to another forum and ask about XMLHttpRequest to get and exact solution/workaround to this
Interesting! I’ve never come across forbidden header names before. Thanks for the help
Finally, Unity decided to allow it … Yeah!
The documentation for SetRequestHeader now states the following:
“It is possible to set a custom value for the accept-encoding header but the resulting behavior is unreliable so it is strongly recommended to let it be automatically handled unless you can accept the risk of unexpected results.”
Does anybody now what is behind these ominous words? I tried it, and it works fine, though I do have to decompress the contents myself.
What kind of unreliable, unexpected results could happen?
Something changed in Unity 2020 and now it spams warnings in logs every time Accept-Encoding is set… Could they be disabled somehow?
Very annoying with playfab for example https://community.playfab.com/questions/43345/getting-the-header-accept-encoding-is-managed-auto.html
Bump, let me gzip the content 
You can, at your own risk. The messages are informational, so you know you might have issues.
They are completely spamming my console. It’s not informational it’s distracting. Show that message once per play not every time uwr is used…
These messages make everything worse as I may miss something really important.
Additionally that information is confusing.
What does it mean? Is it set automatically to I don’t know… Something? Is it doing any decompression/compression automatically? (no it doesn’t checked headers with fiddler) So what’s the point?
Here’s how informational these msgs are:
Thanks Unity for treating me like a child, now I have to disable warnings forever.
I consider switching to HttpClient. Even PlayFab support started to recommend Unity 2019 instead of 2020 bcs of it Redirecting to PlayFab Discord forum....
It is either set to supported values or left out depending on platform. On platforms that do support compression, data will be automatically decompressed, but on on platforms without support for compression the data will be compressed.
Finally, on WebGL, the value you set will be ignored.
That’s why the recommendation to leave it unset.
Servers (and many cdn providers) won’t return compressed content if there’s no Accept-Encoding header. So what you said here is false. Obviously Windows supports compression but uwr doesn’t do it.
Request with header manually set:
Automatic:
Have you checked whether servers response is actually compressed and that the data you get out of UWR was properly decompressed? Compression wasn’t supported on Windows in the past.
Yes I guess it’s not “supported” but few lines of code does it:
string textResponse;
if ( string.Equals( request.GetResponseHeader( "Content-Encoding" ), "gzip", StringComparison.InvariantCultureIgnoreCase ) )
{
using ( var decompress = new GZipStream( new MemoryStream( request.downloadHandler.data ), CompressionMode.Decompress ) )
using ( var sr = new StreamReader( decompress ) )
{
textResponse = sr.ReadToEnd();
}
}
else
textResponse = request.downloadHandler.text;
How can this fail and give me unexpected results?
On platforms that do support gzip the data you get from download handler will be decompressed already and your code will fail.
Eh… Then Unity code is wrong as it should remove Content-Encoding header.
But anyway…
byte[] bytes = www.downloadHandler.data;
bool isGzip = bytes != null && bytes [0] == 31 && bytes [1] == 139;
but that’s not the point.
Couldn’t that message be moved to method summary? It’s really annoying:
(sometimes when I get completely unrelated bug)
Did some tests to see how bad HttpClient is. Timings would be inconsistent but memory is something what can be tested:
HttpClient:
TotalAllocatedMemory 99,64 Megabyte
TotalReservedMemory 273,09 Megabyte
HttpClient with "Accept-Encoding", "gzip":
TotalAllocatedMemory 100,64 Megabyte
TotalReservedMemory 274,09 Megabyte
UnityWebRequest:
TotalAllocatedMemory 116,39 Megabyte
TotalReservedMemory 289,65 Megabyte
UnityWebRequest with "Accept-Encoding", "gzip":
TotalAllocatedMemory 104,44 Megabyte
TotalReservedMemory 278,09 Megabyte
Amazing results, UnityWebRequest even with “Accept-Encoding” and spamming warnings to console/logs it allocates less memory than pure UnityWebRequest due to much smaller response size. Interesting to see how response size doesn’t matter for HttpClient (yes I did test if response size was gzipped, was 800kb down to 200kb).
Gzip tests include deserialization of the content, http client does:
HttpClientHandler handler = new HttpClientHandler()
{
AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
};
client = new HttpClient( handler );
Uwr what I’ve sent before in this thread.
#Edit
One more test x100 requests:
HttpClient
TotalAllocatedMemory 100,70 Megabyte
TotalReservedMemory 274,09 Megabyte
UnityWebRequest
TotalAllocatedMemory 185,12 Megabyte
TotalReservedMemory 357,80 Megabyte
OK I’m definitely switching to HttpClient.
More in UnityWebRequest allocates way more memory than HttpClient
I am not familiar with this header accept-encoding topic but I am using Playfab and am getting this header accept-encoding warning that is clogging up my console. I hope Unity and Playfab can resolve this.
Same problem here. Console full of playfab warning. Unity, can you simply add some way to just disable the warning? (config?)