Yikes. The following statement from the .NET 3.5 B2 "known issues" made me a little nervous:
For WCF HTTP streaming, the stream that is returned to the client is not the same size as the stream size requested in some stress situations. The service can send extra bytes to the client side due to a known racing issue in the Visual Studio 2008 product code.
To resolve this issue:
Avoid using the HTTP streaming feature for WCF.
Um, I need HTTP streaming- my stress tests max out my server memory if I do things buffered, and the stress tests don't even simulate slow clients yet. I set up a test to try and reproduce the behavior (just to see how bad it is). I wasn't able to see that behavior, but I did see another nasty one. If a client disconnects from a webHttpBinding service while a response is being streamed, the HttpListener throws an unhandled exception on an I/O completion thread. In a self-hosted scenario (like mine), unhandled exceptions take the process down, which effectively means part of my app is down until someone brings it back up!
Luckily, the legacy .NET 1.1 unhandled exception backstop is still available via configuration, so that will keep my process alive until they get the problem fixed.
Ahh, the fun of developing on the bleeding edge.