Introduction

In AFNetworking 2.0, request headers are usually set on the request serializer before the request is sent. For a GET request, that means you do not add headers in the URL itself or in the response serializer. You configure the requestSerializer on the manager, or you build a custom request and attach headers there.

The Normal AFNetworking 2.0 Pattern

The most common object in AFNetworking 2.0 is AFHTTPRequestOperationManager. It exposes a requestSerializer, and that serializer owns the HTTP header fields that will be applied to outgoing requests.

A simple example:

1#import <AFNetworking/AFNetworking.h>
2
3AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
4[manager.requestSerializer setValue:@"Bearer token-value" forHTTPHeaderField:@"Authorization"];
5[manager.requestSerializer setValue:@"application/json" forHTTPHeaderField:@"Accept"];
6
7[manager GET:@"https://api.example.com/profile"
8  parameters:nil
9     success:^(AFHTTPRequestOperation *operation, id responseObject) {
10         NSLog(@"%@", responseObject);
11     }
12     failure:^(AFHTTPRequestOperation *operation, NSError *error) {
13         NSLog(@"Error: %@", error);
14     }];

Those headers are attached to the outgoing GET request because they were configured on the request serializer before the request started.

Headers Set on the Manager Affect Future Requests

A useful detail is that the serializer belongs to the manager. If you reuse the same manager for several requests, any headers you set remain there until changed or cleared.

That is convenient for shared headers such as:

• 'Authorization'
• 'Accept'
• 'User-Agent'
• custom API version headers

It also means you should be careful when one request needs special headers but another should not inherit them.

Per-Request Header Customization

If you need headers for only one request, you can create an NSMutableURLRequest through the serializer and then run it with an operation.

1#import <AFNetworking/AFNetworking.h>
2
3AFHTTPRequestOperationManager *manager = [AFHTTPRequestOperationManager manager];
4NSError *error = nil;
5
6NSMutableURLRequest *request = [manager.requestSerializer requestWithMethod:@"GET"
7                                                                  URLString:@"https://api.example.com/profile"
8                                                                 parameters:nil
9                                                                      error:&error];
10
11[request setValue:@"Bearer token-value" forHTTPHeaderField:@"Authorization"];
12[request setValue:@"mobile-app" forHTTPHeaderField:@"X-Client"];
13
14AFHTTPRequestOperation *operation = [manager HTTPRequestOperationWithRequest:request
15                                                                     success:^(AFHTTPRequestOperation *operation, id responseObject) {
16                                                                         NSLog(@"%@", responseObject);
17                                                                     }
18                                                                     failure:^(AFHTTPRequestOperation *operation, NSError *error) {
19                                                                         NSLog(@"Error: %@", error);
20                                                                     }];
21
22[manager.operationQueue addOperation:operation];

This pattern is safer when one request needs temporary headers and you do not want those headers to leak into later calls made by the same manager.

Choosing the Right Serializer

The request serializer controls how parameters and headers are encoded. AFNetworking 2.0 commonly uses:

• 'AFHTTPRequestSerializer for standard form-style requests'
• 'AFJSONRequestSerializer when the request body should be JSON'

For GET requests, parameters usually go in the query string either way, but headers are still configured through the serializer.

Example:

manager.requestSerializer = [AFJSONRequestSerializer serializer];
[manager.requestSerializer setValue:@"application/json" forHTTPHeaderField:@"Content-Type"];

Even though Content-Type is more relevant for body-bearing requests, the general header-setting mechanism is the same.

Debugging Header Problems

If the server says an auth header is missing, check these points:

• was the header set before the request started
• are you using the same manager instance you configured
• did later code overwrite the header value
• is a proxy or test server showing the raw outgoing request

It can help to inspect the built request directly:

NSLog(@"Headers: %@", request.allHTTPHeaderFields);

That gives you a direct view of what AFNetworking is about to send.

Common Pitfalls

The most common mistake is trying to set headers on the response serializer instead of the request serializer. Another is setting a header on a shared manager and then forgetting that all later requests through that manager inherit it. Developers also sometimes add headers after the request has already been created or started, which has no effect on the already-built request. A final issue is using the convenience GET method when a one-off custom request would be cleaner for per-request headers.

Summary

• In AFNetworking 2.0, headers for a GET request are usually set on manager.requestSerializer.
• Shared headers belong on the manager's serializer before the request starts.
• One-off headers are better handled by building a custom NSMutableURLRequest.
• The response serializer does not control outgoing headers.
• If headers seem missing, inspect the actual request object and the lifetime of the manager configuration.