我可以从 NSHTTPURLResponse 中的 HTTP 状态行访问“原因短语”吗

指定 HTTP 的 RFC 2616 在第 6.1.1 节中表示，状态行的部分是 3 位数字状态代码和文本“原因短语”。

我正在构建一个 iPhone 应用程序，它使用 NSURLConnection 通过 HTTP 访问数据。我可以毫无问题地获取 HTTP 状态代码，但如何访问“原因短语”？

这是我的连接：didReceiveResponse：方法

- (void)connection:(NSURLConnection *)connection didReceiveResponse:(NSURLResponse *)response {
    NSHTTPURLResponse *httpResponse = (NSHTTPURLResponse *)response;

    httpStatusCode = [httpResponse statusCode];
    // Reason Phrase ??
}

具体来说，我并不是指“代码 xxx 含义的解释”文本。我可以在 RFC 中查找，这些都是静态的。我的意思是服务器在状态行中生成的文本。这种状态行的一个例子是：

HTTP/1.1 412 ClientAppVersion: 0.10 < 0.11

此处的原因短语为“ClientAppVersion: 0.10

这个例子也暗示了我想要做什么。我正在构建一个类似 REST 的 API，因此，我应该使用 HTTP 状态代码来指示错误。但 HTTP 状态代码是为 HTTP 而不是为我的应用程序发明的，因此我尝试将额外的信息塞入原因短语中。

跟进之前的评论（这不完全是您正在寻找的答案）。

HTTP 规范 (RFC 2616) 指出，关于状态代码和原因短语 http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1:

状态代码供以下人员使用 自动机和原因短语是 供人类用户使用。这 客户不需要检查或 显示原因短语。

从文本中可以清楚地看出，不应期望 HTTP 客户端读取原因短语。事实上，如果有的话，它通常是可能提供的本地化版本（不一定是服务器发送的版本）。

拥有 HTTP 等标准和规范的目的是能够期望不同的兼容实现（例如您的服务器和 iOS 库）能够互操作。如果你改变规范，你应该预料到会出现问题。特别是，如果您要使用的库不允许您访问原因短语，请不要感到惊讶。

我不太确定如何解释您的评论（“我正在弯曲 HTTP 以使其符合 REST 理念。”）我可以向您保证，REST 可以使用 HTTP 来实现，而无需这种弯曲。我不确定你从哪里得到这个弯曲 HTTP 以适应 REST 想法的想法......

如果您想实现某种方式以 REST 方式给出错误原因，则应在响应消息正文中（甚至可能在自定义标头中）给出原因，而不是在原因短语中给出。即使它是纯文本响应，也比原因短语更好。例如：

代替：

HTTP/1.1 412 ClientAppVersion: 0.10 < 0.11

use:

HTTP/1.1 412 Precondition Failed
Content-Type: text/plain

ClientAppVersion: 0.10 < 0.11

也许：

HTTP/1.1 412 Precondition Failed
Content-Type: text/plain
X-My-Error: ClientAppVersion: 0.10 < 0.11

请注意，无论如何您都应该返回消息正文（除非 204）。状态码 412 http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.13也与基于标头的前提条件（您可能正在使用）非常具体相关：

一个或多个给出的前提条件 评估的请求标头字段的数量 测试时为 false 服务器。该响应代码允许 客户提出先决条件 当前资源元信息 （标头字段数据）从而防止 所请求的方法是 应用于除 一个有意的。