A while back I posted about the need to 'rewind' the Request.InputStream if you peek at it. I laid out some hypothetical ways to do it, and in the end settled on one that used a C# using statement.

Bad Move.™ I found this out while testing and wondering why my stream wasn't being rewound. Why Because when the using statement is done, the underlying stream is CLOSED, in order to allow the Streamreader to be disposed. This means that your stream doesn't rewind, it just GOES AWAY, which is much worse than leaving it 'unwound.'

In the end, using a StreamReader on the InputStream is pretty much a bad idea, unless you plan on having exclusive access to it and don't care about rewinding it. (BTW, ReverseDOS 2.8 no longer peeks at the InputStream in this manner).

Of course, if you shouldn't use a StreamReader, then how should you do it Well, remember that InputStream is a stream, and you can just read bytes out of it as needed. (But you'll need to rewind when you're done). Here's an example:

HttpRequest Request = HttpContext.Current.Request;

long len = Request.InputStream.Length;
byte[] input = new byte[len];
Request.InputStream.Read(input,0,Convert.ToInt32(len));
Request.InputStream.Seek(0,SeekOrigin.Begin);

// xfer the byte[] to a string:
string output = System.Text.Encoding.UTF8.GetString(input);

This way we're still rewinding the InputStream when we're done peaking at it, we're not leaving objects open/laying about, and the rewind is actually WORKING.