C# – Handling http response codes in GetStringAsync

c++windows-phone-8.1

i'm very new to C#, let alone Windows Phone development 🙂

I'm trying to send a request, get the JSON response, but if there is an error (such as 401), be able to tell the user such. Here is my code:

async Task<string> AccessTheWebAsync()
        {
            //builds the credentials for the web request
            var credentials = new NetworkCredential(globalvars.username, globalvars.password);
            var handler = new HttpClientHandler { Credentials = credentials };

            //calls the web request, stores and returns JSON content
            HttpClient client = new HttpClient(handler);
            Task<string> getStringTask = client.GetStringAsync("https://www.bla.com/content");

            String urlContents = await getStringTask;

            return urlContents;

        }

I know it must be something I'm doing wrong in the way that I send the request and store the response…but i'm just not sure what.

If there is an error, I get a general:
net_http_message_not_success_statuscode

Thank you!

Best Solution

You could use te GetAsync() method instead of the GetStringAsync().

HttpResponseMessage response = await client.GetAsync("https://www.bla.com/content");

if(!response.IsSuccessStatusCode)
{
     if (response.StatusCode == HttpStatusCode.Unauthorized)
     {
         do something...
     }
}
String urlContents = await response.Content.ReadAsStringAsync();

This way you can make use of the HttpStatusCode enumerable to check the returned status code.

Method A: HttpClient (Preferred)

Available in: .NET Framework 4.5+, .NET Standard 1.1+, .NET Core 1.0+ .

It is currently the preferred approach, and is asynchronous and high performance. Use the built-in version in most cases, but for very old platforms there is a NuGet package.

using System.Net.Http;

Setup

It is recommended to instantiate one HttpClient for your application's lifetime and share it unless you have a specific reason not to.

private static readonly HttpClient client = new HttpClient();

See HttpClientFactory for a dependency injection solution.

POST

var values = new Dictionary<string, string>
{
    { "thing1", "hello" },
    { "thing2", "world" }
};

var content = new FormUrlEncodedContent(values);

var response = await client.PostAsync("http://www.example.com/recepticle.aspx", content);

var responseString = await response.Content.ReadAsStringAsync();

GET

var responseString = await client.GetStringAsync("http://www.example.com/recepticle.aspx");

Method B: Third-Party Libraries

RestSharp

POST

 var client = new RestClient("http://example.com");
 // client.Authenticator = new HttpBasicAuthenticator(username, password);
 var request = new RestRequest("resource/{id}");
 request.AddParameter("thing1", "Hello");
 request.AddParameter("thing2", "world");
 request.AddHeader("header", "value");
 request.AddFile("file", path);
 var response = client.Post(request);
 var content = response.Content; // Raw content as string
 var response2 = client.Post<Person>(request);
 var name = response2.Data.Name;

Flurl.Http

It is a newer library sporting a fluent API, testing helpers, uses HttpClient under the hood, and is portable. It is available via NuGet.

    using Flurl.Http;

POST

var responseString = await "http://www.example.com/recepticle.aspx"
    .PostUrlEncodedAsync(new { thing1 = "hello", thing2 = "world" })
    .ReceiveString();

GET

var responseString = await "http://www.example.com/recepticle.aspx"
    .GetStringAsync();

Method C: HttpWebRequest (not recommended for new work)

Available in: .NET Framework 1.1+, .NET Standard 2.0+, .NET Core 1.0+. In .NET Core, it is mostly for compatibility -- it wraps HttpClient, is less performant, and won't get new features.

using System.Net;
using System.Text;  // For class Encoding
using System.IO;    // For StreamReader

POST

var request = (HttpWebRequest)WebRequest.Create("http://www.example.com/recepticle.aspx");

var postData = "thing1=" + Uri.EscapeDataString("hello");
    postData += "&thing2=" + Uri.EscapeDataString("world");
var data = Encoding.ASCII.GetBytes(postData);

request.Method = "POST";
request.ContentType = "application/x-www-form-urlencoded";
request.ContentLength = data.Length;

using (var stream = request.GetRequestStream())
{
    stream.Write(data, 0, data.Length);
}

var response = (HttpWebResponse)request.GetResponse();

var responseString = new StreamReader(response.GetResponseStream()).ReadToEnd();

GET

var request = (HttpWebRequest)WebRequest.Create("http://www.example.com/recepticle.aspx");

var response = (HttpWebResponse)request.GetResponse();

var responseString = new StreamReader(response.GetResponseStream()).ReadToEnd();

Method D: WebClient (Not recommended for new work)

This is a wrapper around HttpWebRequest. Compare with HttpClient.

Available in: .NET Framework 1.1+, NET Standard 2.0+, .NET Core 2.0+

using System.Net;
using System.Collections.Specialized;

POST

using (var client = new WebClient())
{
    var values = new NameValueCollection();
    values["thing1"] = "hello";
    values["thing2"] = "world";

    var response = client.UploadValues("http://www.example.com/recepticle.aspx", values);

    var responseString = Encoding.Default.GetString(response);
}

GET

using (var client = new WebClient())
{
    var responseString = client.DownloadString("http://www.example.com/recepticle.aspx");
}

C# – HttpClient.GetAsync(…) never returns when using await/async

You are misusing the API.

Here's the situation: in ASP.NET, only one thread can handle a request at a time. You can do some parallel processing if necessary (borrowing additional threads from the thread pool), but only one thread would have the request context (the additional threads do not have the request context).

This is managed by the ASP.NET SynchronizationContext.

By default, when you await a Task, the method resumes on a captured SynchronizationContext (or a captured TaskScheduler, if there is no SynchronizationContext). Normally, this is just what you want: an asynchronous controller action will await something, and when it resumes, it resumes with the request context.

So, here's why test5 fails:

Test5Controller.Get executes AsyncAwait_GetSomeDataAsync (within the ASP.NET request context).
AsyncAwait_GetSomeDataAsync executes HttpClient.GetAsync (within the ASP.NET request context).
The HTTP request is sent out, and HttpClient.GetAsync returns an uncompleted Task.
AsyncAwait_GetSomeDataAsync awaits the Task; since it is not complete, AsyncAwait_GetSomeDataAsync returns an uncompleted Task.
Test5Controller.Get blocks the current thread until that Task completes.
The HTTP response comes in, and the Task returned by HttpClient.GetAsync is completed.
AsyncAwait_GetSomeDataAsync attempts to resume within the ASP.NET request context. However, there is already a thread in that context: the thread blocked in Test5Controller.Get.
Deadlock.

Here's why the other ones work:

(test1, test2, and test3): Continuations_GetSomeDataAsync schedules the continuation to the thread pool, outside the ASP.NET request context. This allows the Task returned by Continuations_GetSomeDataAsync to complete without having to re-enter the request context.
(test4 and test6): Since the Task is awaited, the ASP.NET request thread is not blocked. This allows AsyncAwait_GetSomeDataAsync to use the ASP.NET request context when it is ready to continue.

And here's the best practices:

In your "library" async methods, use ConfigureAwait(false) whenever possible. In your case, this would change AsyncAwait_GetSomeDataAsync to be var result = await httpClient.GetAsync("http://stackoverflow.com", HttpCompletionOption.ResponseHeadersRead).ConfigureAwait(false);
Don't block on Tasks; it's async all the way down. In other words, use await instead of GetResult (Task.Result and Task.Wait should also be replaced with await).

That way, you get both benefits: the continuation (the remainder of the AsyncAwait_GetSomeDataAsync method) is run on a basic thread pool thread that doesn't have to enter the ASP.NET request context; and the controller itself is async (which doesn't block a request thread).

More information:

My async/await intro post, which includes a brief description of how Task awaiters use SynchronizationContext.
The Async/Await FAQ, which goes into more detail on the contexts. Also see Await, and UI, and deadlocks! Oh, my! which does apply here even though you're in ASP.NET rather than a UI, because the ASP.NET SynchronizationContext restricts the request context to just one thread at a time.
This MSDN forum post.
Stephen Toub demos this deadlock (using a UI), and so does Lucian Wischik.

Update 2012-07-13: Incorporated this answer into a blog post.

Best Solution

Related Solutions

C# – How to make an HTTP POST web request

Method A: HttpClient (Preferred)

Setup

Method B: Third-Party Libraries

Method C: HttpWebRequest (not recommended for new work)

Method D: WebClient (Not recommended for new work)

C# – HttpClient.GetAsync(…) never returns when using await/async

Related Question