4

I have an issue with the 

connection:didWriteData:totalBytesWritten:expectedTotalBytes:

method of the NSURLConnectionDownloadDelegate under iOS 6.

Under iOS 5 Simulator it works just fine, giving me the right expectedTotalBytes value.

On iOS 6 Simulator, the expectedTotalBytes always returns 0. The totalBytesWritten value is still right.

It's the same request, the same URL, just the OS Version is different.

Has anyone encountered a similar issue or has any idea what could cause this?

Cheers Kim

Micky
  • 5,578
  • 7
  • 31
  • 55
  • Does the same thing happen on a device? – Tom Irving Sep 25 '12 at 12:30
  • Yes, same thing on an iPad with iOS 6 – Micky Sep 25 '12 at 12:41
  • 2
    Probably worth submitting a bug report (bugreporter.apple.com). – Tom Irving Sep 25 '12 at 12:50
  • Ditto to @TomIrving suggestion - create a small demo project (I tend to move things in and out of my public dropbox folder etc), that demonstrates the problem. Then submit the demo app with your bug. Apple will eventually look at it as this is an important API. Just to be absolutely clear, you understand that totalBytesWritten is a 'long long' type, and so if you log the value you must use %lld. – David H Sep 25 '12 at 13:07
  • @David yes, I totally and completely understand that and definitely used %lld for logging :) – Micky Sep 25 '12 at 13:08
  • @Kim Did you submit this bug to apple? – matzino Sep 25 '12 at 13:33
  • I implement a sample project, under iOS 6 and in the Simulator I get the values for "totalBytesWritten" and "expectedTotalBytes". *confused* In my other project, which still works fine under iOS 5, the value for "expectedTotalBytes" is always -1! – matzino Sep 25 '12 at 13:54
  • I submitted the bug to apple bugreporter. If anyone else is experiencing this issue, too, feel free to submit a bug yourself, as apple uses the number of reportings of an issue as an indicator for it's priority. – Micky Sep 26 '12 at 08:55

1 Answers1

7

Just spent a good amount of time investigating the same issue. It turned out to be that in iOS6 the request is first made with HEAD to investigate the headers, which is not that abnormal.

However it seems headers from the response to the actual GET request are ignored. As a result if your server did not support HEAD or returned 0 content length for HEAD request against a given URL, iOS NSURLConnection will use wrong information.

My problem was that my custom server did not support HEAD requests for files I was downloading, and instead returned a 405 (HTTP Error 405 Method not allowed) which in its own response contained a content length that then iOS6 used when returning expectedTotalBytes, not the correct one from the GET response.

To fix my problem, I first enabled HEAD for my file download requests and then made sure the correct content length was returned. Verified with:

curl -v -I http://url
...
< Content-Length: 23493947
Content-Length: 23493947

Not sure if that is bug in iOS6 or just better compliance with the HTTP standards. Hope that helps others.

Jaisor
  • 86
  • 1
  • 4
  • 1
    +1 exact same problem, though not sure what to do with S3 where our content is hosted. – msk Oct 01 '12 at 07:52
  • Thank you very much, this seems to be the problem. Our server also returns no value for content-length in a HEAD request. It is also a S3, so I think we'll use a workaround passing the content length somewhere in the response to the initial request to our own server. – Micky Oct 15 '12 at 12:17
  • The problem with S3 and signed requests is that with signed requests you specify a single REST verb that is allowed with the signed URL. That verb could be GET or HEAD, but not both. So you need to get the Content-Length from another channel. Fun. – fnf Apr 19 '13 at 13:39