Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

GZip support #540

wants to merge 2 commits into


None yet
3 participants

haemi commented Jan 30, 2012

added GZip support; basically, NSURLConnection does support GZip compression, but the body data has to be decompressed


bmorton commented Jan 30, 2012

It looks like you've got another commit mixed up on this pull request. Can you take a look at feature branching it so there is only one thing to look at merging? There's a pretty sweet guide on how to do this here: https://github.com/RestKit/RestKit/wiki/Contributing-to-RestKit

You'll also want to get some spec support behind this too so you know things are acting properly (as well as so others adding on to your code know they aren't breaking anything ;). There's some information on getting the test suite up and running and some notes on where to start writing tests here: https://github.com/RestKit/RestKit/blob/master/Docs/TESTING.md

We should probably check to make sure the stuff we've added to RKRequest will unzip the body as expected as well as the stuff in RKParserRegistry to make sure that the proper action happens when that MIME type is set.

I'll help as much as I can if you have any other questions! I idle on IRC most of the day in the #RestKit channel on freenode.


blakewatters commented Jan 31, 2012

From my understanding, NSURLConnection supports transparent GZip decompression when the Accept-Encoding header is set to gzip. You've implemented decompression of GZipped payloads. Couldn't you just use transparent GZip support from your web server? The parser registry and MIME Type constants are used for object mapping serialization and deserialization and don't conceptually line up with the extensions here.

If you need to explicitly decompress a GZip payload, why not just load it with an RKRequest and then decompress the NSData returned from the responseBody. Then you'd only need to link in the GZip header in your app and not modify the framework at all.

See http://blog.mro.name/2009/06/nsurlconnection-gzip-magic/

haemi commented Jan 31, 2012

@bmorton - sorry, I'll have a look at it

@blakewatters - I do set the header accordingly: [[RKClient sharedClient] setValue:@"gzip" forHTTPHeaderField:@"Accept-Encoding"];

Nevertheless it's necessary to decompress the body myself. My webserver sends the JSON-data gzip-compressed, so I need to decompress it before RestKit starts mapping. And from my point of view (but, of course, I may be wrong) I need to tell (1) RestKit that gzip can be mapped too and (2) I need to decompress the data myself...


blakewatters commented Feb 24, 2012

I see this as a pretty use-case specific feature… I would rather see an implementation that enables the data to be decompressed without adding the gzip specific bits into RKResponse. Interpreting application/gzip to always mean GZipped JSON payloads feels wrong to me… I would look for an alternate MIME type that could be registered at the application level as corresponding to GZipped JSON + a callback mechanism to permit decompression outside of RK. If there is a bunch of interest in such a feature I'd consider approaches to merge it… but I don't see this patch as merge able as is.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment