1

I have a regular .NET Framework class library that successfully calls the Twitter REST API and returns the JSON data returned from the API.

This library was copied to a UWP app inside a Universal Windows class library. Everything compiled out of the box (except some minor namespace changes).

However, the data returned from the UWP library is just garbage! Whereas the .NET framework library returns the JSON data, the UWP library returns something that looks like this in Visual Studio:

\u001f?\b\0\0\0\0\0\0?Vmo?6\u0010?+ ....

There are questions that seem to be similar, like this one, but that (and other answers) use ReadAsBufferAsync which does not exist on the HttpResponseMessage returned in my library.

How can I have my UWP library work the same way as my Framework library?

This is my HttpClient usage, which is identical for both UWP and Framework library:

using (HttpClient client = new HttpClient()) {
    client.BaseAddress = new Uri(TWITTER_API);
    client.DefaultRequestHeaders.Accept.Clear();
    client.DefaultRequestHeaders.Accept.Add(
        new MediaTypeWithQualityHeaderValue("application/json"));
    client.DefaultRequestHeaders.Add("Authorization", generatedAuthString);

    HttpResponseMessage response = await client.GetAsync(TWITTER_API_PATH);
    if (response.StatusCode == HttpStatusCode.OK) {
        // This returns garbage in UWP library, correct JSON string in Framework library
        return await response.Content.ReadAsStringAsync();
    }

    return null;
}

I have also tried using ReadAsByteArrayAsync() and then using Encoding.UTF8.GetString(), but it yielded the same garbage result.

These are the response headers returned by the API call:

server: tsa_o
strict-transport-security: max-age=631138519
x-transaction: 00ba702600ece624
x-connection-hash: 4f6ae39419ed099fbc9eaa61419071ee
x-twitter-response-tags: BouncerCompliant
cache-control: no-store, must-revalidate, no-cache, pre-check=0, post-check=0
x-rate-limit-remaining: 899
set-cookie: lang=en; Path=/, guest_id=v1%3A150003721463912535; Domain=.twitter.com; Path=/; Expires=Sun, 14-Jul-2019 13:00:14 UTC
x-rate-limit-limit: 900
date: Fri, 14 Jul 2017 13:00:14 GMT
x-response-time: 199
x-frame-options: SAMEORIGIN
x-rate-limit-reset: 1500038114
status: 200 OK
x-content-type-options: nosniff
x-access-level: read-write-directmessages
pragma: no-cache
x-xss-protection: 1; mode=block
TheHvidsten
  • 4,028
  • 3
  • 29
  • 62
  • 1
    May be the response is correct but just compressed (check the response headers). In case UWP does not transparently decompress the response this may explain the strange data you get. – Robert Jul 14 '17 at 12:59
  • @Robert Response headers are pasted into the question. It does not look like they contain anything related to compression. – TheHvidsten Jul 14 '17 at 13:04
  • @mjwills Nothing :( – TheHvidsten Jul 14 '17 at 13:16
  • @mjwills You're correct. It was a duplicate. I added the handler as in the accepted answer on that question, and suddenly the data is not garbage any more, but the expected JSON. When a response is compressed, would it not be nice to have something in the response headers that say the response is compressed so you can take the appropriate actions? – TheHvidsten Jul 14 '17 at 13:20

0 Answers0