REST calls launched with UnityWebRequest fail

Problem:

REST calls launched with UnityWebRequest fail.

After a patching made on the queried servers (see below) the actual response is not the one expected.

It is as if in the journey that goes from the application to the server the calls lost the authentication cookies (which are currently found in the header).

An activity of downgrade and reinstallation its been made for understand what was the problem.

Updating the Shibboleth version to the 3.2.0 there is the problem above.

We try other solutions for launch the calls like “HttpWebRequest” and the results is fine. The question now is:

-what is the difference between “UnityWebRequest” and “HttpWebRequest”?

Most likely your use of UnityWebRequest is in some way incorrect. Can you show the code sample of how you use it?

This is how all the calls are handled, it was ok for nearly 2 years.

public IPromise<ResponseHelper> Call(string servicePath) {

        return Call(servicePath, new Dictionary<string, string>());
    }

    public IPromise<ResponseHelper> Call(string servicePath,
        Dictionary<string, string> payload) {

        string authCookies = LoginController.GetAdfsSessionCookie()
            + "; " + LoginController.GetLiferaySessionCookie();
        Logger.Log(authCookies);

        string wsUrl = basePath + servicePath + "?" + LoginController.GetLiferayAuthToken();
        Logger.Log("calling ws:" + wsUrl);

        return RestClient.Post(new RequestHelper
        {
            Uri = wsUrl,
#if !UNITY_WEBGL || UNITY_EDITOR_WIN
            Headers = new Dictionary<string, string> {
                { "Cookie", authCookies}
            },
#endif
            SimpleForm = payload,
            IgnoreHttpException = true
        });
    }

In latest Unity versions cookies are also managed automatically. There is also API in UnityWebRequest to clear the cache. Maybe that has anything to do with it?
For diagnosis, try examining raw request via HTTP debugger (such as Fiddler or Charles proxy).

1 Like

We are currently using Unity 2018.4.11f, and also we already tried to examining raw request, but the calls are right (in fact in iOs the application is working fine).

Well, if requests don’t work, there should be something wrong with them…
It’s always the best to compare working request with non-working one. There must be some header or some other intricacy different.

Yes this is clear, but take this another one: we take the raw calls directly from the log and after that we tried to use that raw calls with postmen and the results is ok! the expected response was received.
Did you have any suggestion actually? maybe the problem is the plugin “RESTClient”?

Were you performing the real raw calls? That is including all the headers, cookies etc?
Because otherwise I don’t see how they can work on one device and not on other. Except maybe one being plain HTTP and other HTTPS, or the TLS version being very new and supported by one, not other.