Link: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/57
Origin: http://www.w3.org/mid/1168508632.25607.104.camel@henriknordstrom.net
Component: p1-messaging
6.1.1 is apparently a bit too vague about how applications should parse and process the information, making some implementations parse the reason phrase (probably exact matches on the complete status line, not just status code) to determine the outcome.
There should be a SHOULD requirement or equivalent that applications use the status code to determine the status of the response and only process the Reason Phrase as a comment intended for humans.
It's true that later in the same section there is a reverse MAY requirement implying this by saying that the phrases in the rfc is just an example and may be replaced without affecting the protocol, but apparently it's not sufficient for implementers to understand that applications should not decide the outcome based on the reason phrase.
I propose rewording the last sentence of the first paragraph "The client is not required to examine or display the Reason-Phrase." into something like
The client MAY present the Reason Phrase to the user and SHOULD NOT examine the Reason Phrase for other purposes.
or perhaps
The client SHOULD NOT examine the Reason Phrase for other purposes than displaying it to the user.
I suggest
The Reason Phrase exists for the sole purpose of providing a textual description associated with the numeric status code out of deference to earlier Internet application protocols that were more frequently used with interactive text clients. The client SHOULD ignore the content of the Reason Phrase.
....Roy
From [198]:
Clarify that a client SHOULD ignore the Reason Phrase; related to #57.
Fixed in [198]
From [199]:
Record "Reason Phrase" clarification in Changes seection, related to #57.