duplicated of #14770

@shakaran thanks for proposing this feature. However, this same feature was proposed and rejected in 2013 and in May of 2015. As you can see, Fabien gave some very compelling reasons for not adding this getter.

In any case, if this pull request is ultimately closed without merging it, please keep sending new pull requests and issues to help us improve Symfony. Thanks!

Thanks @dosten and @javiereguiluz it was my first pull request. I am needing this change in my unit test for check the status code and status text received in api request, since I found that you can inject some texts like '404 User not found' or '404 The user already has this property' in status text. If this not get implemented I will have to override the bevahiour. I don't see how much damage could have expose this attribute

I know it was your first pull request :) I wanted to give you a reasoned reply for that reason.

If you read the following section of the HTTP Specification:

   The Status-Code element is a 3-digit integer result code of the
   attempt to understand and satisfy the request. These codes are fully
   defined in section 10. The Reason-Phrase is intended to give a short
   textual description of the Status-Code. 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.

As you can see, the "reason phrase" or "status text" is "nothing" in the standard and clients/browsers can ignore it completely. The "solution" to your use case would be to not test this "useless" information and focus only on the important status code.

Thanks then for the warm welcome. Even if I am agree that it is a bit useless and the client/browsers should ignore it, and the HTTP clearly dont put as mandatory, I think that add the method don't should harm anybody, even you can say that Symfony still obey the HTTP spec, but it gives you additional power if you are still interested in check the Reason-Phrase or StatusText. But well, it depends of final BDFL's decision and the community

If we are in the process of implementing PSR-7 interfaces, maybe that this can be discussed again.
Personally I never use this but it can probably be useful in some legacy / interoperability cases.

@fabpot I'd be in favor of merging this one and end the discussion. This topic comes over and over again. I agree with your base concern that this is useless or even wrong, but it makes no harm (or at least, people always find many ways to harm their code, this one won't add much to the soup ;) )

But #14770 is better because it also updates tests. Closing this one.