I’ve written a windows service application that exposes a WCF REST web service. The call signature is as follows:
[OperationContract]
[WebInvoke(
Method = "POST",
UriTemplate = "/render",
BodyStyle = WebMessageBodyStyle.Bare)]
Stream Render(Stream input);
It’s implemented like so:
public Stream Render(Stream input)
{
return new AdapterStream(output => DoActualWork(input, output));
}
But immediately when Render() returns, the underlying stream to the calling client is cut off, so that it gets a HTTP 200 OK and 0 bytes of body data. Immediately after that, a breakpoint inside DoActualWork() is hit – so the server actually does its job and dumps data onto the AdapterStream during the following seconds, but by then the caller has been disconnected and is long gone.
Any ideas why this happens? Since DoActualWork() actually IS called, it would seem that the framework really did try to fetch data from the AdapterStream, but … well, too late or something.
If nothing else, do you have any other suggestions for achieving the same thing (i.e. circumventing the fact that the result stream is a return value rather than a method parameter) without having to dump the (huge) results into a MemoryStream first and returning that? Which works like a charm, by the way, except for eating lots of memory.
Even if this question is quite old, I solved the problem like this:
First ensure that your WebHttpBinding has TransferMode streamed.
Second ensure that you flush and dispose the stream given to you in the callback.
Third block the callback (Not the Render method!) until finished writing to the stream.