UnityWebRequest all response headers are null

Hey community :heart:
I am having strange issue with web request response headers - they are listed but all of them are of null value, which is deadly in my case as i obviously need to read their data in ma app… The server response status itself is 200 though and also other additional data (json) which is part of an expected response are arriving pretty fine.

I am basically connecting to a custom Apiary api. When I test the request with same parameters in a browser it shows the headers content ok.

here is my C# code which i use to realize request from Unity (pretty stadard i think):

protected static IEnumerator PostUnityWebRequest(string url, string data)
    {
        byte[] bodyRaw = Encoding.UTF8.GetBytes(data);
        UnityWebRequest request = new UnityWebRequest(url, UnityWebRequest.kHttpVerbPOST);
        request.uploadHandler = (UploadHandler)new UploadHandlerRaw(bodyRaw);
        request.downloadHandler = (DownloadHandler)new DownloadHandlerBuffer();
        request.SetRequestHeader("Content-Type", "application/json");
        //request.useHttpContinue = false;
        //request.redirectLimit = 0;
        yield return request.Send();
        if (request.isError)
        {
            Debug.Log("request error: " + request.error);
        }
        else
        {
            Debug.Log("server response status: " + request.responseCode);
            Dictionary<string, string> responseHeaders = request.GetResponseHeaders();
            AUTHORIZED = true;
            isAuthorizing = false;
        }
    }

here is a screenshot showing the headers as they appear in the debugger:
77076-headers.png

here is how the same response headers appear in a web interface:

As I said, the body of the response arrives ok even in my unity request, I just cannot read the values of the headers (actually some headers are all missing too in my unity request as you can see)…

I am rather a noob regarding networking unfortunatelly, so after trying with new UnityWebRequest as well as legacy www class, I got a bit lost, even tried all other http methods (just to see if it could make any difference from standard POST). I have run through many related posts out there, from which i basically learned that there are some issues with unity networking api, particulary with redirecting but that doesn’t seem to be an issue in my case… I also tried to set different values for redirect limit in my web request. Some suggest to switch to 3rd party libs or using native .net classes instead… which i would like to avoid as it would mean to rewrite a major part of my async asset download managers etc…

So did enyone else here experience that, or does anyone have any clue what might be a possible cause?
I dont know what other info could i provide to help you help me, so please let me know:)

Thanks in advance guys!

I have the same issue with the 5.6.3p4 patched version of Unity.

Could it be that it is related to these changes?

(none) - UnityWebRequest : Fixed early availability of status code when UnityWebRequest was still running.
(none) - UnityWebRequest : Ensure that headers are available in UnityWebRequest only after all of them are received.
(none) - UnityWebRequest : Fixed possible issues aborting UnityWebRequest when using a custom download handler script.

I am seeing a similar issue in 2017.2.0f3, but slightly different. I am using UnityScript, and for me the www.responseHeaders are null, but only in the case where the body is empty. Once I add even just a single character to the body, then the www.responseHeaders are all happy. Fortunately for me, since I control the server I added a catch-all to the response handler on my server to just add a ’ ’ space character as the body if the body is empty.

We have gotten several reports about how Android devices simply crash when trying to access the response headers.
We’ve gotten other reports about exceptions when getting response headers, which we’ve worked-around with a try-catch.

Response headers are necessary to determine if the response has been encrypted. It’s also a major regression from the old, functional WWW mechanism.

This is fixed in 2017.2.1