-[NSMutableURLRequest allHeaderFields]: unrecognized selector sent to instance 0x88cbcb0

is there allHeaderFields on NSURLRequest ?

Hello, @mattt!

I want to propose a set of six features that, I think, could complement AFHTTPRequestOperationLogger very well.

1. Total request/response statistics.

Since logging is done by subscription to AFNetworking notifications, it is possible to not only log single requests one by one, but also keep a log of a total summary of requests that was performed up to a given period of time. It is very easy to collect this kind of summary information since this AFHTTPRequestOperationLogger already deals with every request (its start/finish moments). Then some function like loggingSummary
could return formated log summary for a given period of time (the most obvious - an application lifetime) so the following

NSLog(@"%@", [[AFHTTPRequestOperationLogger sharedLogger] loggingSummary]);

would produce formatted information like

Requests sent: ...
Requests received: ...
Total bytes sent: ...
Total bytes received: ...
...

2. Allow output to a custom function.

I think a technique similar to what is described here could be used to teach AFHTTPRequestOperationLogger to produce its output to some other target than NSLog (I personally hate the kind of output that NSLog produce). For example, printf - having it implemented, we could see just AFNetworking logging without all this NSLog noise it produces.

3. AFHTTPRequestLoggerLevel: make logger levels composite

typedef enum {
  AFLoggerLevelOff,
  AFLoggerLevelDebug,
  AFLoggerLevelInfo,
  AFLoggerLevelWarn,
  AFLoggerLevelError,
  AFLoggerLevelFatal = AFLoggerLevelOff,
} AFHTTPRequestLoggerLevel;

This is how current typedef enum for AFHTTPRequestLoggerLevel. Let's see how it could look like:

typedef enum {
  AFLoggerLevelOff = 0,

  AFLoggerLevelHTTPMethod = 1 << 0,
  AFLoggerLevelStatusCode = 1 << 1,
  AFLoggerLevelURL = 1 << 2,
  AFLoggerLevelHeaderFields = 1 << 3,
  AFLoggerLevelBody = 1 << 4,
  AFLoggerLevelElapsedTime = 1 << 5,
  AFLoggerLevelDataSize = 1 << 6,
  ...

  AFLoggerLevelDebug = AFLoggerLevelHTTPMethod | AFLoggerLevelStatusCode | AFLoggerLevelURL | AFLoggerLevelHeaderFields | AFLoggerLevelBody | AFLoggerLevelDataSize,
  AFLoggerLevelInfo = AFLoggerLevelHTTPMethod | AFLoggerLevelURL,
  AFLoggerLevelWarn = ...,
  AFLoggerLevelError = ...,
  AFLoggerLevelFatal = AFLoggerLevelOff,
} AFHTTPRequestLoggerLevel;

This feature also would be a nice-to-have to be able to build more verbose formatters (see 4 and 6).

4. Add logging of request/response data size.

The logging of request/response size should be added because of by my observations HTTP response headers do not always contain Content-Length header like "Content-Length" = 3069;. And even if they did, it would be still nice to see response size without having a logging of HTTP headers enabled. Currently I log operation.responseData.length by my own to get that info.

5. Add logging of NSError object with the domain “NSURLErrorDomain”.

AFHTTPRequestOperationLogger could describe errors caused by some connection problems, not the problems caused on/by a server-side. The most frequent errors I deal with are NSURLErrorCannotFindHost = -1003 (occasional, indeterministic) and NSURLErrorNotConnectedToInternet = -1009 no-networking error. These errors result in that NSURLConnection formats its responses without HTTP status code but with this NSError with NSURLErrorDomain. Would be great to have a humanized description of these NSErrors! I even think NSError deserves its own kind of AFLoggerLevel... = 1 << ... string (see 3 and 6).

6. Logging formatting: more verbose and more ... formatted

Having all 1-5 described above, I think it is obvious that AFHTTPRequestOperationLogger should have all this formatting logic extracted out of the HTTPOperationDidStart: and HTTPOperationDidFinish: methods into a separate class or a method. This separate concern should be mainly about these two important things: 1) printing a logging info based on what is a current logging level, 2) making all this output formatted nicely and consisely.

I feel that AFHTTPRequestOperationLogger lacks all these features I described. The reason I haven't started implementing all of these on top of AFHTTPRequestOperationLogger because at first I want to know your thoughts about every and all of these and in the second because I am afraid I will not be able to implement all of these in a so-crystal-pure manner like AFHTTPRequestOperationLogger is currently done, at least without your assistance and tutorship.

And one more! This is just my personal opinion: having in mind all the stuff I've just described (especially the first feature about total HTTP statistics) I do think that more general AFNetworkingLogging is a better name for the whole project than AFHTTPRequestOperationLogger - a logger of just AFHTTPRequestOperations.

Thanks.

I had to remove strong from two properties that are blocks in
AFURLConnectionOperation.h
As its the only way my project will build on Xcode 5 runnig os x 10.9, and iOS 7 and only if AFHTTPRequestOperationLogger cocoapod is installed if that pod is not installed AFNetworking will build without me needing to edit the two properties. but once I re add the logger then I have to edit AFNetworking to not get errors during build

/**
The dispatch queue for completionBlock. If NULL (default), the main queue is used.
*/
@Property (nonatomic) dispatch_queue_t completionQueue;

/**
The dispatch group for completionBlock. If NULL (default), a private dispatch group is used.
*/
@Property (nonatomic) dispatch_group_t completionGroup;

AFHTTPRequestOperationLogger is requiring AFNetworking (>= 0.9.0)

which causes this error

[!] The platform of the target Pods (iOS 5.0) is not compatible with AFNetworking (2.0.0-RC1) which has a minimum requirement of iOS 7.0 - OS X 10.9.

Can we update the podspec to support AF 2.0.0? It should still work just fine for the NSURLConnection APIs, but cocoapods is currently preventing the install because it says it requires 1.x

We need to add support for NSURLSession, but thats a larger discussion on how to best add that from a modular perspective.

This is really strange. For some reason if I'm using the AFJSONRequestOperation class:

[[AFHTTPRequestOperationLogger sharedLogger] startLogging];
[[AFHTTPRequestOperationLogger sharedLogger] setLevel:AFLoggerLevelInfo];

AFHTTPClient *client  = [[AFHTTPClient alloc] initWithBaseURL:url];
[client registerHTTPOperationClass:[AFJSONRequestOperation class]];
[client setDefaultHeader:@"Accept" value:@"application/json"];

[client postPath:@"login"
      parameters:@{@"email":email,@"password":password}
         success:^(AFHTTPRequestOperation *operation, id response) {

         }
         failure:nil];

the response succeeds however there is no logging. It seem that for whatever reason isKindOfClass fails?!?:

- (void)HTTPOperationDidStart:(NSNotification *)notification {
    AFHTTPRequestOperation *operation = (AFHTTPRequestOperation *)[notification object];

    if (![operation isKindOfClass:[AFHTTPRequestOperation class]]) {
        return;
    }

... cut ...

Debugging it shows nothing wrong. po operation sows it's a AFJSONRequestOperation object and po ![operation isKindOfClass:[AFHTTPRequestOperation class]] shows false however it still hits the return. I'm at a loss to explain why so thought maybe someone else would have insight into this.

Nice logger but:
when I try to send multipart request with Debug level of logging I can't see content of body (because used stream). Can you fix this behavior? Or it is not a bag?

In my project I have two singleton instances of different subclasses of AFHTTPClient for different external APIs. How can I filter log messages by AFHTTPClient instance or by subclass name?

When will the AFHTTPRequestOperationLogger work in AFNetworking 2.0?