UnityWebRequest - Is their any alternative to this borked piece of crap?

I have been fighting with UnityWebRequest for two days now over just simple S***. For example:

I have my game connect to a web server and get a JSON response verifying the server is up.

Code (CSharp):

1.   url += "api/hlogin/connectionCheck/";

In the editor, this works. Build and upload the game to the same server, this works.
I then have the game then connect to the server to verify a login and get a JSON response... same code mind you.

Code (CSharp):

1.   url += "api/hlogin/doConnect/";

In the editor, this works. Build and upload the game to the same server, 404 error.

How about this one for some debugging fun:

Somehow, this piece of trash managed to get BOTH the 404 error page AND the JSON response from the server, mash them both together in the same downloadHandler.text and promptly spit back a 404 error. And that's with just one request (yea, I set up a counter to make sure this thing wasn't doing 2 requests and gluing different results together).

More? Ok.

I do a web request to the server and it grabs the JSON just fine. And gives a 404 error in isHttpError. Wait a minute, how can it grab the page AND say it doesn't exist?!?

MORE??? Sure.

WTF is a HTTP error code 0? I looked through https://tools.ietf.org/html/rfc2616#section-10 and unless I'm blind an illiterate those error codes start at 100. But does UnityWebRequest spit out a 0 when it wants to? Yep, sure does. I've seen it. "Unknown Error" Really? It's UNKNOWN??? Ok. If you write code and you put in an error handler then you pretty much know when and were the error occurs unless you're just being damned lazy and classify EVERYTHING as an unknown error. Was it in sending the request? No internet connection? Was it in the server? Did it give a 500 error response? Was it in the GD SSL certificate? UNKNOWN doesn't tell me CRAP!

And, here's one more for the road. If I do this, UnityWebRequests spits out a 404 error:

Code (CSharp):

1.               if (connectRequest.isNetworkError || connectRequest.isHttpError)
2.             { }

But, if I ignore the 404 error and do this:

Code (CSharp):

1.               if (connectRequest.isNetworkError)
2.             { }

the page loads just fine. Make sense? Nope.

I want to program Unity in PHP. 5 minutes and I'd have a Curl request with none of these stupid problems.

 

Just as a constructive bit of meta-feedback: The anger and frustration in your post caused me to stop bother to read it pretty early on. Calm yourself down, edit your post to remove all the angry nonsense, and post concise and meaningful questions.

Consider this: You're angry at something, or someone, but whomever you're angry at is almost certainly not going to be the person reading your post and trying to help you. You're writing to regular forum folks, like me, who don't work for Unity. But I have to put up with your yelling at me? I'll go find a friendlier post read.

 

The squeaky wheel gets the grease.

Nothing on this planet was ever changed by a passive majority. And, if you think this was directed at you then you have other issues you need to deal with rather than answering forum posts.

 

Fair enough. To each his own philosophy. Maybe someone else here will find it rewarding to help you.

 

The immediate first question is going to be: which pay-for assets have you tried? There's a bunch of HTTP-related ones that have been around for years (although I've not used them myself - haven't needed to, I used to be a network programmer so I prefer to write my own). Most things in Unity that have been badly broken for a long time have a strong asset (or multiple strong assets) that replace them neatly - and since Unity doesn't pay anyone for this, you have to buy them separately.

 

Second question will be: why aren't you using an open-source HTTP library? C# has loads of them.

TL;DR: UnityWebRequest isn't great, but ... why are you using it? Does anyone else still use it? (I thought most had stopped a long time ago)

 

At the moment I'm not using any pay-for assets. I'm just starting this project and am interested in seeing if Unity us going to be a better choice than my other attempt (Construct 3). I did look at a couple of assets for Unity. One embeds chrome but that has limitations in that it appears to only work on windows. There was an asset that allowed HTML be displayed in Unity and I looked at that. But, it appears support has stopped for that and it now crashes.

As for HTTP libraries, I'm still fumbling my way through C# (PHP programmer) so I'm not familiar with any. Right now, the only C# lib I've added is Newtonsoft.json

 

You aren't really posting to get something changed, you are asking for help, maybe a little humility wouldn't hurt... anyways:

You can use the standard C# HTTP libraries in Unity, see for example: https://forum.unity.com/threads/httpclient-on-net-standard-2-0.608800/

Library details: https://docs.microsoft.com/en-us/dotnet/api/system.net.http.httpclient?view=netcore-3.1

And for future reference this is the 'Game Design' section, you will get quick replies if you post this kind of issue in the correct section called 'Scripting': https://forum.unity.com/forums/scripting.12/

 

The world of politics is full of examples to the contrary - rejections of the activism of a loud minority.

 

What's the problem with UnityWebRequest? I use it in all my projects for all my account related stuff (own account system and then synchronization of achievements, stats, leaderboards and so on) and haven't had a single problem that wasn't caused by a programming error on my side (and I use it on all platforms, from Windows, Linux, Mac standalone over mobile (Android and iOS) to consoles (Switch, Xbox One, UWP)). Would be great to know any problems I might run into in the future.

 

This thread has been hijacked by sensitive trolls.

 

Aside from OP's examples?

I have no complaints about UWR. It's scrappy but simple, easy to use. If you only have basic use-cases then sure, go for it, keep using it.

Last time I tried it though it wasn't as good as more widely-used HTTP client libs (HTTP client lib writing is surprisingly complex given how simple HTTP is - but once you get into all the details of async I/O, proxies, VPNs, etc it all piles up and you end up wtih lots and lots of special-case code)