This topic focuses on how to use IP addresses resolved by HTTPDNS. For more information about how to use HTTPDNS to resolve domain names to IP addresses, see SDK for iOS.
Background information
In scenarios related to URL redirects such as 302 redirects, the following requirements must be met:
Users need to connect to the server through IP addresses even multiple 302 redirects are performed.
Redirection issues usually occur when POST requests are used. You can resolve these issues by using the following methods:
Use GET requests instead of POST requests.
Resolve redirection issues for POST requests.
The most cost-efficient solution is replacing POST requests with GET requests. However, this solution can be implemented only in limited scenarios. Therefore, this topic focuses on how to resolve redirection issues for POST requests.
Redirection for POST requests
This section describes how to respond to different types of redirection codes.
The following table describes the types of redirection codes.
Redirection code | Protocol | Description |
300 Multiple Choices | HTTP 1.0 | Optional redirection. This code indicates that the requested resources are redirected to other URLs but does not indicate whether the redirection is a temporary redirection or a permanent redirection. |
301 Moved Permancently | HTTP 1.0 | Permanent redirection. This code indicates that the requested resources are permanently moved to another URL. |
302 Moved Temporarily | HTTP 1.0 | Temporary redirection. This code indicates that the requested resources are temporarily moved to a new URL and may be moved again or can be normally accessed in the future. This code is the same as the 302 Found code in HTTP 1.1. |
303 See Other | HTTP 1.1 | This code is similar to the 301 or 302 code. However, if the original request is a POST request, the resources specified by the Location header in the response must be obtained by using the GET method. This code is available in HTTP 1.1. |
304 Not Modified | HTTP 1.0 | This code indicates that the request is not actually redirected. It is returned for conditional GET requests to avoid downloading data from the browser cache. |
305 Use Proxy | HTTP 1.1 | This code indicates that the requested resources must be obtained from the proxy server specified by the Location header in the response. This code is available in HTTP 1.1. |
306 | HTTP 1.0 | This code is no longer in use. |
307 Temporary Redirect | HTTP 1.1 | This code is the same as the 302 Found code in HTTP 1.1. Browsers may perform redirection when the 302 code is returned even if the original request is a POST request. In fact, when the request is a POST request, redirection can be performed only when the 303 code is returned. To resolve this issue, HTTP 1.1 introduces the 307 code. When the 303 code is returned, the browser performs redirection no matter whether the original request is a GET or POST request. When the 307 code is returned, the browser performs redirection only when the original request is a GET request. This code is available in HTTP 1.1. |
The following section focuses on how to handle common redirection codes including 301, 302, 303, and 307.
The 302 code is further defined into the 303 and 307 codes in HTTP 1.1. However, the 303 and 307 codes are not commonly used. Many browsers handle the 302 or 301 code in the same way as the 303 code.
The following table describes the usage of the common redirection codes.
Protocol | Redirection code | Recommended usage | Actual usage |
HTTP 1.0 | 302 (or 301) | Not recommended | The code is still commonly used. |
HTTP 1.1 | 303 and 307 | Recommended | The codes are not commonly used. |
The redirection codes in HTTP 1.0 and HTTP 1.1 are different in the redirection logic for POST requests.
POST or PUT requests are not idempotent, which indicates that different resources may be returned when the same POST or PUT request is sent for multiple times. Therefore, if the request is not a GET or HEAD request and 301 or 302 is returned for the request, the browser does not automatically redirect the request to the URL specified by the Location header in the response without confirmation.
If the request is a POST request and the 307 code is returned, the request is not automatically redirected to a GET request. You must check with the user whether the request needs to be redirected and manually redirect the request if required.
The 303 code is added in HTTP 1.1. However, the redirection logic of browsers does not change from HTTP 1.0 to HTTP 1.1. Currently, most browsers handle the 302 code by obtaining the Location header in the response and then initiating a GET request, which is the same as the method used to handle the 303 code.
You can handle different redirection codes based on your requirements. For example, you can perform the following operations to handle the 303 code:
Redirect the request if the Location header in the response contains the redirection URL.
If you replace the POST request with a GET request, clear the request body.
Clear the host information.
Send the request again.
Sample code:
NSString *location = self.response.headerFields[@"Location"];
if (location && location.length > 0) {
NSURL *url = [[NSURL alloc] initWithString:location];
NSMutableURLRequest *mRequest = [self.swizzleRequest mutableCopy];
mRequest.URL = url;
if ([[self.swizzleRequest.HTTPMethod lowercaseString] isEqualToString:@"post"]) {
// Redirect POST requests to GET requests.
mRequest.HTTPMethod = @"GET";
mRequest.HTTPBody = nil;
}
[mRequest setValue:nil forHTTPHeaderField:@"host"];