Batch requests and response compression

ServiceStack
1

I have been experimenting with the batch requests in SS 4 Auto Batched Requests.

My problem is that I had been using ToOptimizedResult to compress responses. When I use batching each individual response gets compressed and then combined into an uncompressed response.

Have I missed a better way to handle this?

thanks,

David

2

You wont be able to use ToOptimizedResult() on auto batched responses since it returns a CompressedResult (encapsulating raw serialized compressed bytes) whereas Auto Batching requires the original DTO’s so they can be passed individually through the response pipeline then combined and returned together.

3

Thanks for the response. Further on batched requests. I am probably doing something wrong but it seems to be working such that if I post a batch of requests and the service throws and exception for one of them then the batch stops processing at that point and the only response I get is the error response.

Is that the intended behaviour?

4

Oh, and another related question. I have always been puzzled that SS does not compress by default, that we have to code for compression. Are you sceptical of the value of compression?

5

Yes it throws an exception/error response short-circuiting the Request. It will also return a HttpHeaders.XAutoBatchCompleted (X-AutoBatch-Completed) HTTP Header indicating how many requests were completed before first failure.

6

Why would it compress everything by default? It’s definitely something that should be opt-in. If you want to generically compress everything you can enable a ASP.NET Response Filter in the Global.asax Application_PreSendRequestHeaders() example.

The ToOptimizedResult() isn’t the same thing as it doesn’t compress every response, it stores compressed serialized bytes in cache and writes directly to the Response stream on subsequent requests, so the response is only compressed once (when cached) and not every response.

7

Thats a little painful. I was hoping to use this when creating new objects which have server generated unique ids. So with this model I can know that the first N were create but I will not have their unique ids and will find it difficult to find them, unless I send some other unique property in each request.

8

Sorry, ‘by default’ was poor wording, I meant more as a config option, something like AppHost.Config.CompressWhenRequested. Anyway, I was just curious re any philosophical position.