For stream output: Hashcode as eTag cache to avoid compressing and sending resources user already has.

There is eTag cache in file-mode but not in stream mode.

We can add optional cache:
Add hashcode of unzipped resource as eTag. Now if user already has correct eTag in request we can send just http status of not modified instead of zipping and sending data.

I have a simple OWIN application. On GET it returns a big chunk of JSON.

When compression enabled, it computes an ETAG and the ETAG remains the same even if the data changes.

After playing a bit with sources it turns out if I change the following line

                    if usecompress && checkNoValidETag(context.Response.Body) then

to

                    if usecompress && checkNoValidETag(buffer) then

and add this

        let getMd5Hash (item:Stream) =
            item.Position <- 0L

it starts to work and properly computes ETAG.

But it doesn't feel like it's a correct fix.

Upon downloading the nuget package into a brand new C# project and adding the appropriate app.UseCompressionModule() code, I start my self hosted server and get the following error:

System.TypeInitializationException was unhandled by user code
  HResult=-2146233036
  Message=The type initializer for '<StartupCode$Owin-Compression>.$CompressionModule' threw an exception.
  Source=Owin.Compression
  TypeName=<StartupCode$Owin-Compression>.$CompressionModule
  StackTrace:
       at Owin.OwinCompression.get_DefaultCompressionSettings()
       at Owin.CompressionExtensions.UseCompressionModule(IAppBuilder app)
       at AspNetSelfHostDemo.Startup.Configuration(IAppBuilder app) in {{path-to-project-hidden}}\Startup.cs:line 52
  InnerException: 
       FileName=FSharp.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
       FusionLog==== Pre-bind state information ===
LOG: DisplayName = FSharp.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
 (Fully-specified)
LOG: Appbase = file:///{{path-to-project-hidden}}/bin/Debug/
LOG: Initial PrivatePath = NULL
Calling assembly : Owin.Compression, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: {{path-to-project-hidden}}\bin\Debug\AspNetSelfHostDemo.vshost.exe.Config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: FSharp.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
LOG: Attempting download of new URL file:///{{path-to-project-hidden}}/bin/Debug/FSharp.Core.DLL.
LOG: Attempting download of new URL file:///{{path-to-project-hidden}}/bin/Debug/FSharp.Core/FSharp.Core.DLL.
LOG: Attempting download of new URL file:///{{path-to-project-hidden}}/bin/Debug/FSharp.Core.EXE.
LOG: Attempting download of new URL file:///{{path-to-project-hidden}}/bin/Debug/FSharp.Core/FSharp.Core.EXE.

       HResult=-2147024894
       Message=Could not load file or assembly 'FSharp.Core, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
       Source=Owin.Compression
       StackTrace:
            at <StartupCode$Owin-Compression>.$CompressionModule..cctor()
       InnerException: 

Downloading the FSharp.Core nuget package fixes the error. Are you assuming your user has FSharp installed on their machine? Seems like a poor assumption or one that should be mentioned in your documentation somewhere.

Also begs the question why should I have a dependency on FSharp.Core in my C# project....

Hello,
I notice that you may be assuming that anything without an extension is inherently compressable. This is not the case for us, virtually nothing has an extension.
e.g.
GET /swagger/ui/images/logo_small-png

We would really like to be able to define what responses are compressed based on the response mime-type.
At the moment everything and anything without an extension is compressed.

let compressableExtension =
match context.Request.Path.ToString() with
| null -> true
| x when x.Contains(".") ->
let typemap = settings.AllowedExtensionAndMimeTypes |> Map.ofSeq
typemap.ContainsKey(x.Substring(x.LastIndexOf "."))
| _ -> true

I was using this library for compression of a response which is for a stateful request. We have a project scenario in our app such that if the project is already open in a cluster(we have multiple clusters in different regions like - East US , South east asia etc) the request gets forwarded to that cluster. What happened was if you just hit one cluster compression was working fine but when the request was being forwarded and as the library is part of middle ware , the library is trying to compress the already compressed response. Library should check if the response is already compressed it should do nothing and just return. It could use response header to add a simple check in usecompress function.

Severity Code Description Project File Line Suppression State
Error NU1603 Owin.Compression 1.0.16 depends on Owin (>= 1.0.0-prerelease && <= 1.0.0) but Owin 1.0.0-prerelease was not found. An approximate best match of Owin 1.0.0 was resolved

Is there a way to either remove the DEFLATE option or make GZIP preferred? There are several references on the web indicating some browsers have issues processing DEFLATE payloads, so I'd like to prevent any issues arising from these findings.

https://zoompf.com/blog/2012/02/lose-the-wait-http-compression

Currently this module is serving static files from the file system. Instead it could use just compress HTTP-response, so that it could be plugged with other modules, e.g. Microsoft.Owin.StaticFiles NuGet package to do the actual file loading.

The problem seems to be that Microsoft.Owin.StaticFiles won't actually integrate to OWIN-pipeline but it will send the file directly. So there might not be a way to interrupt the HTTP-response. There are very few events (Microsoft.Owin.StaticFiles.FileServerOptions().StaticFileOptions.OnPrepareResponse) and it seems that those can't also be to interrupt the actual response.

I can see in Nuget descriptions that there is following limitations on dependencies

Microsoft.Owin (>= 3.0.1 && < 3.1.0)

Is there is any hard reasons on why 3.1.0 owin package is not supported?

Reading file contents in getFile() function of OwinCompression module implemented as StreamReader.ReadToEndAsync() + System.Text.Encoding.UTF8.GetBytes:
https://github.com/Thorium/Owin.Compression/blob/master/src/Owin.Compression/CompressionModule.fs#L156

How it will proceed with arbitrary encoded text files or binary files (for example, images and fonts) - the file contents will be corrupted in response. This applies when using .MapCompressionModule(...) and respectively ResponseMode.File.