iOS / asi-http-request

incorrectly charging the entire buffer size against the throttler
rather than just the number of bytes actually read.

For example, if you did a read with a 32KB buffer which only received
300 bytes across the wire, the bandwidth Throttler would charge
you for a full 32KB of bandwidth rather than the 300 bytes that
were really used.  This was grossly overstating the bandwidth
consumption to the throttler.

Cache Error with downloadDestinationPath, Not storing downloaded data

* Use [pool drain] because Xcode told us to
* Get rid of a couple of random nib warnings

Make CF allocated objects collectable

NSMakeCollectable and the Static Analzyer should play nice

Move expiryDateForRequest to ASIHTTPRequest

Update projects for newest Xcode / SDK

Solve building warning on Xcode 4.2 & iOS SDK 5.0

UIInterfaceOrientation o = [[UIApplication sharedApplication] statusBarOrientation];
to solve building warning on XCode4.2 and iOS SDK 5.0

…o that the code can be reused.

The functionality is common enough that it may be advantageous for
a third party looking at the request headers to use this method to
calculate the request's expiry date.

Unit tests:

  No new tests.

Documentation:

  Documented the new method +expiryDateForRequest:maxAge:

Thread safety fix for +threadForRequest

closes gh-205

* If key is empty, don't add anything (value can be empty)
* All file/data methods now do through the long form addData:withFileName:andContentType:forKey: method, to cut down on a bit of duplication
Thanks to Bas Scheffers for suggesting changes here!

If you start multiple ASIHTTPRequests from different threads at the same time, you could encounter a condiition where networkThread is being multiply initialized

need to use NOT NOT maxBandwidthPerSecond instead of (maxBandwidthPerSecond). Otherwise value like 1024 will be false

Comment tweaks

…herwise value like 1024 will be false

ASIDownloadCache will now store 301, 302, 303 and 307 redirect responses in the cache. Requests pulling from the cache will automatically redirect (assuming shouldRedirect is true) as if they'd received a Location header from the server.
This change should allow the download cache to operate more effectively as an offline fallback when no internet connection is available.
Additionally, requests encountering a 304 will no longer read from the cache and then write back to it. Instead, they merely update the expiry date (if an updated date was supplied).
As part of this work, two new required methods were added to the ASICacheDelegate protocol, see ASICacheDelegate.h for more info
Finally, ASIDownloadCache now stores the response status code in a custom header in the cached headers dictionary, and requests will have their response status code set to this when they are pulled from the cache.