UnityWebRequest current status and iOS problems

Hi,

Unity's new experimental UnityWebRequest seems awesome (providing me with the only option so far to decompress a png on a background thread) but it seems somewhat unstable.

I keep getting strange error logs like m_ReferenceCount == 0 on both the editor and on iOS and it simply crashes on UnityWebRequest finalizer on iOS.

Is there any way around these problems? Will the final version of UnityWebRequest be released in 5.3 branch? Is there any ETA? I can't find anything on the roadmap.

As it currently stands it's super useful but unstable.

 

Filed bug 763234 for the Editor/iOS common console.log problems
Filed bug 763240 for the mono scripting backend ios problem.

I still can't pin down the finalizer crash on a sample project. I'll go back to my main project and see if it happens again

 

I have same problem. I use unity 5.3.3f1.
Is fixed?

 

Looking at 5.4 API documentation page, it seems that UnityWebRequest lost the "Experimental" part (http://docs.unity3d.com/540/Documentation/ScriptReference/Networking.UnityWebRequest.html) . Nice!

 

Nonetheless, I have not yet received any updates on very specific issues described more than three months ago, here. Simply put, some parts of the API are not working as intended.

@Mantas Puida would you help passing cases 751794 and 751798 to someone who can review those? Justinas was going to look into them, but I got no news or feedback ever since.

 

@povilas Thanks for your comment. You speak of "the" bug, which persists the mistery regarding the two (or three) reported issues. Can you elaborate in any way?

 

Is it recommended we start using UnityWebRequest in place of WWW?

 

The situation is very uncomfortable for developers trying to use the UnityWebRequest API: bugs, horrible communication, months in the dark regarding progress, Unity staff ignoring the issue tracker and bug reports...

At least in my case, I won't start using UnityWebRequest (I tried and can't, due to bugs), and I discourage others to do so. I only hope the situation improves before they deprecate the WWW class.

 

@Novack did you try 5.4beta?

 

Not really. Although I had hopes for it, reading the changelog could not found transcendental improvements on the UnityWebRequest API, other than it was promoted from "Experimental" (which actually happened back in november, while Unity was still working on 5.4b).

Five months I have been following the evolution of this API -the web calls are quite important on my projects-, but has been a harsh relation so far.

 

I have to agree with this, from the point of view of a complete beginner in http requests. Today I set out to make Get/Post requests work for the first time in Unity. I tried UnityWebRequest first, followed the manual to the letter, but I ran into problems with the simplest possible Post request. I tried to make it work for at least an hour; The same Post request made with WWW worked within 5 minutes...

 

@Mantas Puida do you have any details about cases 751794 and 751798? @povilas here commented "it" was fixed, what makes me wonder which one is, and what happens with the other?

Also any info regarding why developers are not using the bug tracker to give any feedback?

 

@Mantas Puida thanks for the answer.

Those are two separate issues.

751794 is about the redirectLimit not working.

751798 is unrelated, and indeed a separate issue. Is about redirections, but yet another problem: redirections are not checking the response header to check the next hop method. At least UnityWebRequest.Post() asumes redirections -if any- will keep using the POST method, when it may not be the case. In my concrete case, Im poking Google services using POST, but the second hop in the redirection for the 302 expects a GET request. In the bug tracker I have included a testbed webservice in Google infraestructure to help you guys see it on the field.

 

@Mantas Puida Much appreciated information, thank you very much!

Please keep us posted regarding 751798. Also worth noting for this issue, is that the POST method works correctly on the WWW class, so is a case of a feature working on the previous API, but not in the new UnityWebRequest API).

 

@Mantas Puida With todays Patch Release (5.3.4p5) looks like both 751798 and 751794 have been fixed. I have been able to test 751798 and is indeed fixed and working. I have not tested yet the redirectLimit issue (751794).

Any ideas about the plans for this fixes (timeline for inclusion in Beta 5.4 and/or next official point release)?

Thank you man, you have been really helpful here!


Edit: tested 751794, and the redirectLimit parameter is also working as expected.

 

Bug #792606 is a hard EXC_BAD_ACCESS any time you upload data with UnityWebRequest on iOS devices (e.g. POST or PUT). That bug report has a very simple repro project attached with 100% repro rate.

It's a crash in the destructor of the Unity C++ class "WebRequestProto" that happens when finalizers run.

I'm trying to find a workaround right now - experimenting with things like setting "disposeUploadHandlerOnDispose" to false and disposing it myself, etc. But no joy so far - always that same crash on iOS devices.

You really can't ship with this issue on iOS unless you are 100% GET requests.

This repro project is using 5.3.4p5.

 

@Claytonious is 792606 a confirmed and always happening problem? Sounds like a harsh issue.

May be ugly for this: Unity and IPv6 Support.

 

Yes, but the great folks at UT have fixed it and it will be in a patch release very soon.

 

Thanks man, are you following this issue in some other forum thread? Would you point me to it?

Edit: the report on the issue tracker has been updated, and now reflects the status mentioned here (Fixed in Unity 5.3.5).

Thanks @Mantas Puida!

 

Hey @Mantas Puida it seems that there is yet another issue related to UnityWebRequest and iOS: POST requests do not always work (even when the same request works fine in other platforms).

I have raised the Case 814388, with an encapsulated, ready-to-test script example of the issue.

Would you help pointing this to the right people?
Much appreciated.

 

Also, found another issue (Case 814458) where UnityWebRequest fails to create a POST request with the dictionary<string, string> method, if the payload surpasses 24Kb.

Special Note: To bypass this issue, Im now using WWWForm: the docs mention about this class being "legacy". Can someone offer clarification regarding if this helper class will be deprecated at some point (was designed for the WWW class which is being deprecated) or will be left in there?

Edit: Oh and found some mistakes on the documentation of the UnityWebRequest class (Case 814110).

 

I can't get my UNITYWEBREQUEST recognized when "using UnityEngine.Networking" instead of UnityEngine.Experimental.Networking... yours works without the Experimental reference?