benfoster/Fabrik.Common

Compressor throws exception

Closed this issue · 6 comments

return input.CopyToAsync(output)
.ContinueWith(task => output.Position = 0); // reset stream position back to 0

This line throws an exception because Position is not writeable (it's of type BufferManagerOutputStream

Does this even work?

Can you post steps to reproduce? Yes it should work (at least it does for me).

OK, I can explain what went wrong and how I fixed it:

Basically, I had to do two things for your sample to work in VS 2012 / .NET 4.5 with nuget retreived System.Web.Http and friends:

  • Remove the following line out of Pump, which throws an exception:
    c# .ContinueWith(task => input.Position = 0); // reset stream position back to 0
    So now, my Pump() method looks like this:
    c# protected virtual Task Pump(Stream input, Stream output) { return input.CopyToAsync(output); //.ContinueWith(task => output.Position = 0); // reset stream position back to 0 }
    This was important because in my case, output was a BufferManagerOutputStream which doesn't support the Position property at all... (I don't know how this worked for you)
  • Change the GZipStream/DeflateStream constructors to leave the underlying stream open...:
    c# public override Stream CreateCompressionStream(Stream output) { return new GZipStream(output, CompressionMode.Compress, true); }
    c# public override Stream CreateCompressionStream(Stream output) { return new DeflateStream(output, CompressionMode.Compress, true); }

Can you confirm if the issue was on the client or server?

Were you using a custom media type formatter or the default XmlMediaTypeFormatter/JsonMediaTypeFormatter?

It was definitely happening on the server.. The client was "wget"

The same error happened with the default media formatted (JSON in my case)
and a custom one..

I'll send a link to a repro project when I'm in front of my computer...

On Sep 23, 2012, at 13:09, Ben Foster notifications@github.com wrote:

Can you confirm if the issue was on the client or server?

Were you using a custom media type formatter or the default
XmlMediaTypeFormatter/JsonMediaTypeFormatter?


Reply to this email directly or view it on
GitHubhttps://github.com//issues/2#issuecomment-8797397.

It's okay, I can reproduce now. The exception was getting swallowed and since it was still returning a compressed result I assumed everything was okay.

Writing better integration tests to verify the behaviour and then will push fix in next 24 hours.

This issue has now been fixed. The code throwing the exception (setting the stream position) has been moved into the DecompressionHandler since this is the only time we actually need to reset the position of the response stream. I've also added specs for the Decompression handler.