Can I access "Reason Phrase" from the HTTP Status-Line in NSHTTPURLResponse

Question

RFC 2616 specifying HTTP says - in section 6.1.1 - that part of the Status-Line is a 3-digit numeric Status Code AND a textual "Reason Phrase".

I am building an iPhone app, that is using NSURLConnection to access data over HTTP. I can get the HTTP Status Code without problems, but how can I access the "Reason Phrase"?

Here's my connection:didReceiveResponse: method

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

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

To be specific, I do NOT mean the "explanation of what a code xxx means" text. I can lookup that in the RFC and those are static. I mean the text the server produced in the status line. An example of such a status line would be:

HTTP/1.1 412 ClientAppVersion: 0.10 < 0.11

and the Reason Phrase would be "ClientAppVersion: 0.10 < 0.11" here.

This example also gives a hint at what I am trying to do. I am building a REST-like API, and as such, I should use the HTTP status codes to indicate errors. But HTTP status codes were invented for HTTP and not for my app, so I try to cram extra information into the Reason Phrase.

Answer 1

Following up on previous comments (this is not quite the answer you're looking for).

The HTTP specification (RFC 2616) states, about status codes and reason-phrase:

The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase.

It's quite clear, from the text, that an HTTP client shouldn't be expected to read the reason-phrase. In fact, it's often a localized version that may be presented, if at all (not necessarily the one sent by the server).

The purpose of having standards and specifications such as HTTP is to be able to expect different compliant implementations (such as your server and the iOS libraries) to be able to interoperate. You should expect problems if you bend the specifications. In particular, don't be surprised if the library you want to use doesn't give you access to the reason-phrase.

I'm not quite sure how to interpret your comment ("I am bending HTTP to make it fit the REST idea.") I can assure you that REST can be implemented using HTTP without this sort of bending. I'm not sure where you got this idea of bending HTTP to fit the REST idea...

If you want to implement something to give an error reason the REST way, the cause should be given in the response message-body (or even maybe in a custom header), not in the reason-phrase. Even if it's a plain-text response, it's better than the reason phrase. For example:

Instead of:

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

or perhaps:

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

Note that you should return a message-body anyway (unless 204). Status code 412 is also quite specifically related to preconditions based on headers (which you may be using):

The precondition given in one or more of the request-header fields evaluated to false when it was tested on the server. This response code allows the client to place preconditions on the current resource metainformation (header field data) and thus prevent the requested method from being applied to a resource other than the one intended.