Alamofire：遵循 HTTP 重定向（或不遵循）答案

【问题标题】：Alamofire: Follow HTTP redirects (or not)Alamofire：遵循 HTTP 重定向（或不遵循）
【发布时间】：2015-03-01 19:17:30
【问题描述】：

我正在尝试将 Alamofire 配置为根据每个请求跟踪（或不跟踪）重定向。

Alamofire 有一个私有内部类 SessionDelegate，它充当当前 URL 会话的 NSURLSessionTaskDelegate。 SessionDelegate 确实实现了相关的委托方法，URLSession(session:, task:, willPerformHTTPRedirection response:, request:, completionHandler:) 这正是我想要的。

更好的是，委托的实现参考了一个名为 taskWillPerformHTTPRedirection 的自定义变量闭包来确定如何处理重定向 - 再次，正是我想要的！

据我所知，默认情况下，该闭包始终为 nil——它不是由 Alamofire 内部分配的——这表明它旨在让用户为其分配一个闭包。

问题：我无法访问这个私有的SessionDelegate 类来为其taskWillPerformHTTPRedirection 变量分配一个闭包。它是一个私有类，对我的 Swift 文件不可见。将 Alamofire 请求配置为（不）遵循重定向的正确方法是什么？

【问题讨论】：

Alamofire 作为 AFnetworking 遵守 HTTP 标准。所以我认为它会自动跟踪重定向。我知道，因为我之前更改了域，并且应用程序会毫无问题地跟进重定向。
AFNetworking 可以配置为不遵循重定向。 Alamofire 肯定有这样做的基础。
由于 Alamofire 的代码不多，而且是一个非常年轻的库，所以我只会分叉库并使用 taskWillPerformHTTPRedirection 自己实现功能，正如您正确发现的那样。然后只需提交 PR。似乎@mattt 从一开始就将这些钩子放在那里，即使它们尚未被 Alamofire 公共 API 使用。
@TeemuKurppa：你是对的，当然，so I did。 :)
我开了一个赏金来让这个问题得到更多的关注。另请参阅 github.com/Alamofire/Alamofire/pull/350 上 Hersh 先生的初始实施。

标签： ios redirect swift alamofire

【解决方案1】：

得益于another pull request，Alamofire 现已提供灵活的重定向处理功能，Alamofire 1.2.0 也可以使用。

【讨论】：

我创建了SessionDelegate 的自定义类。 Alamofire.SessionDelegate 属性不可设置。如何在 Alamofire 中停止重定向。

【解决方案2】：

你可以这样使用它

let configuration = NSURLSessionConfiguration.defaultSessionConfiguration()
let sessionDelegate = Manager.SessionDelegate()
sessionDelegate.taskWillPerformHTTPRedirectionWithCompletion = {
   (session: NSURLSession, task: NSURLSessionTask, response: NSHTTPURLResponse,
    newRequest: NSURLRequest, completionHandler: NSURLRequest? -> Void) in

    // do something
}

let manager = Manager(configuration: configuration, delegate: sessionDelegate)

Alamofire Manager 使 delegate 保持强大，因此您可以放心

public let delegate: SessionDelegate

但请记住willPerformHTTPRedirection

仅在默认和临时会话中的任务调用此方法。后台会话中的任务会自动遵循重定向。

也很适合阅读基础知识Handling Redirects and Other Request Changes

【讨论】：

【解决方案3】：

我认为这个问题很久以前就已经讨论过了，请查看此issue

马特的回答很明确：

我假设 SessionDelegate 中有各种闭包类型的属性， TaskDelegate、DataTaskDelegate 和 DownloadTaskDelegate 旨在被客户用来扩展/覆盖特定的委托行为。

实际上，这是不正确的。这些是在内部实现的为了完整性。面向最终用户的任何功能将在 Manager 或 Request 上公开。

无论如何，我看到赏金是由 Aaron 提供的，而 Jonathan 分叉了他自己的 version，那你为什么不使用那个分叉呢？

【讨论】：