Compression, https

930 views
Skip to first unread message

daniel

unread,
May 20, 2011, 11:21:25 AM5/20/11
to servic...@googlegroups.com
Does ServiceStack support compression, both in requests and responses? Does it suport https when self hosting? These are the only things that keep me from using it ;) 

daniel

unread,
May 20, 2011, 11:36:39 AM5/20/11
to servic...@googlegroups.com
I meant response compression and request decompression

Demis Bellot

unread,
May 20, 2011, 11:42:46 AM5/20/11
to servic...@googlegroups.com
Hi Daniel,

If you use the RequestContext.ToOptimizedResultUsingCache it will return the most optimal result, i.e. Deflated/Gzipped output if the client (i.e. browser) supports it, example at:

Compression is not on by default but you can opt-in by returning your DTO in a CompressedResult to get this behaviour.
We don't do any special functionality to de-compress requests ourselves so it will only work if the web server/IIS is configured to uncompresses the request automatically for ASP.NET applications.

Self-hosting is available using the HttpListener, we've never hosted it using https ourselves but below are some tips on how to host a HttpListener with https:

Cheers,


On Fri, May 20, 2011 at 4:36 PM, daniel <nyk...@gmail.com> wrote:
I meant response compression and request decompression



--
- Demis


daniel

unread,
May 20, 2011, 12:51:25 PM5/20/11
to servic...@googlegroups.com
Hi Demis, 

Thank You for response, I think RequestContext.ToOptimizedResultUsingCache will do just great for responses. Do You think it could be possible to decompress request using "Accessing the IHttpRequest and IHttpResponse using filters"?

Cheers,
Daniel

Demis Bellot

unread,
May 20, 2011, 1:01:14 PM5/20/11
to servic...@googlegroups.com
Not with the Request and Response filters in ServiceStack since the DTO needs to be already materialized at that point.

You want to look for an IIS/ASP.NET configuration/filter that automatically decompresses deflated/gzipped requests that it receives for dynamic requests. 
It may even be on by default, you should just try it and see if it works.

Here's some info about configuring compression in IIS:

Cheers,

daniel

unread,
May 20, 2011, 3:05:23 PM5/20/11
to servic...@googlegroups.com
It looks like IIS only support reponses compression. Requests that I use are quite large (~40M) comparing to compressed (~4M).

Using WCF, I have written a custom message encoder (http://msdn.microsoft.com/en-us/library/ms751458.aspx). I need solution that works both on .NET and Mono.

Cheers,
Daniel

Demis Bellot

unread,
May 20, 2011, 5:07:23 PM5/20/11
to servic...@googlegroups.com
Ok 40M web service requests sounds like a lot, too much.

Personally due to the resource constraints and fragility of handling of handling large messages I don't think processing 40M in realtime (i.e. as soon as you receive the request) is a winning strategy. 
Up to a certain size I would stop trying call web services with very large payloads and instead use the HTTP File Upload mechanism to transfer data instead which is much more resilient.

My preferred approach would be to package the payload on the client in an optimal format, HTTP upload it to the web service which would simply persist the message before an offline background thread or external service/process detects, unwraps and executes the request one at a time.

If you're considering doing something similar in the future then the RestFiles example shows how to process/save HTTP uploaded files:

Cheers,

daniel

unread,
May 21, 2011, 2:54:34 AM5/21/11
to servic...@googlegroups.com
I transfer 40M (4M compressed) request only once a day to synchronize some data. All other transfers are quite small, I don't want to make additional file transfers when using WCF works just great already. 

What about: Global.asax and 

void Application_PreRequestHandlerExecute(object sender, EventArgs e)
{
...
}

Maybe I could do some decompression here? Do You think it's good place to start?

Cheers,
Daniel

daniel

unread,
May 21, 2011, 3:05:40 AM5/21/11
to servic...@googlegroups.com
   1: protected void Application_BeginRequest(object sender, EventArgs e)
   2: {
   3:     if (this.Request.Headers["Accept-Encoding"] != null
   4:         && this.Request.Headers["Accept-Encoding"].Contains("gzip")
   5:         && this.Request.Path.ToLower().EndsWith(".aspx"))
   6:     {
   7:         this.Response.Filter = new System.IO.Compression.GZipStream(this.Response.Filter, System.IO.Compression.CompressionMode.Compress, true);
   8:         this.Response.AddHeader("Content-encoding", "gzip");
   9:     }
  10: }

It's what I found for now.

daniel

unread,
May 21, 2011, 3:08:52 AM5/21/11
to servic...@googlegroups.com
public void Application_BeginRequest() 
{
   Request.Filter = ...
}

Will it work with ServiceStack?

mythz

unread,
May 21, 2011, 6:13:36 AM5/21/11
to servic...@googlegroups.com
I don't see why not, ServiceStack is just a thin layer over ASP.NET's IHttpHandlers - if this works for normal ASP.NET web apps then it should work for ServiceStack.

Cheers,
Demis

daniel

unread,
May 21, 2011, 6:32:42 AM5/21/11
to servic...@googlegroups.com
Ok, that's great ;) I needed some confirmation if Application_BeginRequest will not colide with ServiceStack.

Cheers,
Daniel
Reply all
Reply to author
Forward
0 new messages