Before reading this, refresh your memory of Joel Spolsky's wonderful post on the Law of Leaky Abstractions.
Viewing the value in the debugger or outputting it to the debug window didn't show any obvious missing line-feeds, but perhaps the reader was doing something weird.
also showed that everything was as it should be. Every single line in the response header ended in 0D0A.
Just in case the reader was doing something weird, I double-checked in Fiddler. Sure enough, there were only 0D0A pairs.
Huh. I figured at this point it was time to go step through the Framework code.
I knew from reading Mehdi's extremely in-depth article on the same problem that problem probably stemmed from somewhere in ParseHeadersStrict, although it took me a while to get there. Given that I had verified from two different sources that every header line did end in CRLF, I thought perhaps something else in the Framework was acting up. As it turns out, it was exactly where I should have looked in the first place.
Here's the relevant code from WebHeaderCollection.cs. At this point we are looping through a byte buffer containing the response.
// Find the header name; only regular characters allowed.
and ensuring they're valid. The above loop is ensuring that the header name (before the colon) doesn't have any weird characters in it.
The next portion of code ensures that we read the colon and header value and Most Importantly that the line ends with CRLF. Given how many times I had seen the error message CR must be followed by LF, I was quite curious to see how this was going to fail.
// Read to a colon.
And yet it blew up. Again. Even though I could see in the VS Memory window that every single 0D was followed by OA.
and there was definitely something different about that header name compared to all the others.
I sent all this info off to Mashape this evening and am hoping they can fix it soon.
Update: Mashape fixed this issue on August 21.