Since I lost several hours on this today, I thought I'd quickly share my experience. There were very few results for the inital terms I searched for so perhaps this may help someone in the future.
I've been working on what will hopefully be my first released Windows Phone app (8.1 Silverlight) for the last two months. When I say two months, I worked on it for two weeks before the World Cup started and finally picked it up again today.
In the interim, it appears that Mashape has slightly changed the way you use their API. Or, more specifically, they've removed developer keys and only app-specific keys remain. (This was the first 30 minutes lost; I still don't see a tweet or blog post about this).
So it's my own fault I'm only now discovering there have been some changes:
- the removal of account keys
- the websuite UI (which is very difficult to view in Chrome on Windows)
- the data returned from an API call (?!)
After noticing the sample API page required you to now use
X-Mashape-Key instead of
X-Mashape-Authorization, I went ahead and made a bunch of other changes to my app without running it (Poor, poor Avatar). As soon as I made an API request, the code crashes with
Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED)) at System.Runtime.CompilerServices .TaskAwaiter .ThrowForNonSuccess(Task task) at System.Runtime .CompilerServices .TaskAwaiter .HandleNonSuccessAndDebuggerNotification(Task task) at System.Runtime.CompilerServices .TaskAwaiter`1 .GetResult()
Here's the code that had worked so well a few weeks ago:
var httpClient = new HttpClient(); httpClient.DefaultRequestHeaders .Add("X-Mashape-Authorization", "..."); var uri = new Uri("..."); var response = await httpClient.GetStringAsync(uri); var stuff = JsonConvert.DeserializeObject<...>(response);
Huh. What had I missed?
- using an await incorrectly
- some kind of incorrect binding
- a change to the WP SDK
So I undid all my changes, changed the one header, and still got the same crash.
Which usually means the Emulator is broken. Or Visual Studio. Or perhaps even the OS. After a complete relaunch and reboot, it turned out it was still my problem.
Fiddler to the rescue! Or not.
My next thought was that perhaps along with the header name change, I needed to include some more information in the
GET request. I could tell from my REST client that I shouldn't need anything else, but you never know. After hacking around with Fiddler for the better part of an hour (see here and here), I gave up.
I know Windows Phone Silverlight has its own quirks, but since there is still an overlap with WinRT apps, I thought perhaps creating a "normal" Windows Store app might help. There was also a better possibility of it working with Fiddler.
And yet the same crash persisted.
GetStringAsync yielded the same odd Catastrophic Failure. "PC Load Letter???" Seriously!
The one odd, ODD thing was now Fiddler was showing me a proper result. No HTTP error codes or gobbeldygook; the response seemed like exactly what I'd expect.
Good ol' WPF to the rescue
Throwing together a sample WPF app finally rewarded me with some useful information:
The server committed a protocol violation. Section=ResponseHeader Detail=CR must be followed by LF
And a few quick searches later, http://stackoverflow.com/questions/18580016/httpclient-server-committed-a-protocol-violation-section-responseheader-detail
(wonderful, for WPF apps - it took all of two seconds to verify the app.config change would let the
followed by http://social.msdn.microsoft.com/Forums/windowsapps/en-US/5a8f4b30-a91a-407f-aa6e-7be6ff68a152/how-to-set-useunsafeheaderparsing-of-httpclient
(not so good for Windows Store or Windows Phone apps. Sigh.)
Browsing through the code for unirest-net I couldn't see how it would possibly work even with Mashape's own recommended library. But, just in case, I downloaded it, built it, and was "rewarded" with the same message a few minutes later.
Windows Phone and WinRT error messages can be very annoying to debug. And depending on a third-party for your app can be very trying. But the sense of satisfaction at being able to submit a "good" bug report is ... almost worth it :)
I'm off to submit a bug report and cross my fingers. Let's hope I didn't miss something really simple in my investigation...
Update (July 25): Although I did get a dialog started with Marco and Morgan, the only advice I've received so far is to use the app.config fix (which doesn't work on Windows Phone). I'm really glad we hadn't launched a product yet; we'd have some very unhappy customers at this point.