1 Answer
1

From perusing the source, it seems that the progress callback is just passed the expectedContentLength property of the cached, internal NSHTTPURLResponse object. So, if for some reason your server isn't correctly sending the Content-Length header, and/or is doing chunked transfer encoding, that value is unknown, and the value NSURLResponseUnknownLength is returned (which happens to be defined as -1).

Try inspecting the headers returned by an HTTP request outside the context of your app. If you get a Content-Length header with a sane value, the problem likely lies in AFNetworking itself. If it is absent, the problem lies with the server. I've never seen an HTTP server send a JSON response using chunked transfer encoding (most of the time the content size should be relatively small and known at the time the headers are sent), but it's within spec for it to do so.

OK Warrenm. I print the response headers and the content-length is not present. You're right. I'm using Rails 3 on my server. I will try to find why it's not present and maybe force it in Rails or something like that. Well I added this : config.middleware.use Rack::ContentLength in my Rails config. But the result is stranged : "Content-Length" = 2658; => Get 176699 of 2658 bytes . I'm sure the JSON is more bytes than 2658...
–
muqaddarFeb 9 '12 at 7:55

Sounds like the mismatch of content length could have something to do with a discrepancy between the full and gzip'd size. Not sure if that helps...
–
matttFeb 13 '12 at 5:13