Use AFHTTPResponseSerializer for AFHTTPRequestOperation
Remove the executable permission from .m files
[Issue #1525] Removing duplicate conditional
Merge branch 'master' of github.com:AFNetworking/AFNetworking
[Issue #1531] Adding more explicit data / MIME type / text encoding name version of UIWebView -loadRequest:...
Merge pull request #1526 from techee/master

Use AFHTTPResponseSerializer for AFHTTPRequestOperation
[Issue #1526] Updating documentation for default response serializer of AFHTTPRequestOperation
Merge branch 'master' of github.com:AFNetworking/AFNetworking
[Issue #1398] Setting Content-Length after setting request stream
[Issue #1515] Removing check for nonzero responseData length
[Issue #1492] Fixing macro for iOS 6 compatibility in UIProgressView+AFNetworking
Removing duplicated schemes
Merge pull request #1537 from kylef/permissions

Remove the executable permission from .m files
Fixes an issue writing partial data to output stream

This will manifest in a way where you will get duplicate data because it will
write the same data again and again.
Merge pull request #1539 from kylef/output-stream

Fixes an issue writing partial data to the output stream
[Issue #1539] Adding casts to suppress compiler warnings
Removed unnecessary willChangeValueForKey and didChangeValueForKey method calls.
Fix a bug where [AFURLConnectionOperation pause] did not correctly reset
the state of AFURLConnectionOperation, causing the Network Thread to
enter an infinite loop.

The logic for 'pause' was calling [self.connection performSelector:...].
If 'pause' is executed immediately after 'start', and 'start' did not
have a chance to create self.connection on the Network Thread, then the
logic in 'pause' would effectively be a no-op. When 'resume' gets
called, the previous connection was not actually cancelled, so there are
2 connections both of which have a reference to the same NSOutputStream.
The first connection to finish/error would close the NSOutputStream, and
the second connection would spin forever in the delegate callback
connection:didReceiveData: since [self.outputStream hasSpaceAvailable]
always returns NO.

The test case I added reproduces the failure, but is flaky because it
relies on a race condition between the main thread and the Network
Thread.
Fix a bug where [AFURLConnectionOperation cancel] does not set the
appropriate error on the NSOperation.

There is a race condition where 'cancel' is called immediately after
'start'. When operationDidStart is then called on the Network Thread,
self.connection is not instantiated, because the NSOperation is
cancelled, and 'finish' is called, but without the error set.  When
cancelConnection is then called on the Network Thread, the error is not
set, because the operation is already finished.

In the new code, cancelConnection is always responsible for setting the error,
and then calling 'finish'. operationDidStart never attempts to call
'finish'.

This bug was one of the sources of non-deterministic failures in
testThatCancellationOfRequestOperationInvokesFailureCompletionBlock.
Fixed refs to AFJSONSerializer -> AFJSONResponseSerializer