Include the actual "reason phrase" provided by servers in HTTP error messages

[ypsah]

Hi, at the moment, reqwest displays the recommended reason phrase for HTTP errors, resulting in error messages of the form:

HTTP status client error (403 Forbidden)

ref:

reqwest/src/error.rs

Line 214 in 0cf27a9

write!(f, "{prefix} ({code})")?;

.

These recommended reason phrases (e.g. 403 -> Forbidden, 404 -> Not Found) are documented in RFC9110 and implemented by http here. However the RFC states that these are only recommendations:

The reason phrases listed here are only recommendations -- they can be replaced by local equivalents or left out altogether without affecting the protocol.

ref: https://datatracker.ietf.org/doc/html/rfc9110#name-overview-of-status-codes

As it turns out, some servers customize reason phrases to include useful information. That's the case for example of Sonatype Nexus Repository, a proprietary package index which can quarantine packages that violate some kind of policy (e.g. "package is affected by a CVE with a score > 9"). When trying to download a quarantined package, the server will respond with a 403 HTTP error and set the HTTP reason phrase to something along the lines of: component quarantined, more information at <url>, where <url> redirects to a dashboard with instructions on how to go forward. Needless to say, this is extremely useful for end users that otherwise may think something is wrong with their local setup and struggle to find the actual root cause for the failed download.

Would it be possible to include customized HTTP reason phrases in error messages in reqwest please? Either as a replacement or in addition to the recommended reason phrases.

---

For what it's worth, the requests python package does include the reason set by the server, whatever it is set to: https://github.com/psf/requests/blob/1764cc938efc3cc9720188dfa6c3852c45211aa0/src/requests/models.py#L1017.

[seanmonstar]

As it turns out, some servers customize reason phrases to include useful information.

True. This isn't really a good idea for a server; reason phrases are effectively deprecated (they'll be lost if the requests go through HTTP/2 or 3). It's much better to include any important information in a header or the body. And because of that, the http crate will not be adding support for them.

However, in this case, there is something we can do. hyper will notice if the reason phrase is custom, and will store it in a response extension. What we could do in reqwest is check for it, and if that exists, include it in the error.

[ypsah]

This isn't really a good idea for a server

Agreed. I think the lack of a standard way to communicate error details in the Simple Repository API is to blame here.

hyper will notice if the reason phrase is custom, and will store it in a response extension. What we could do in reqwest is check for it, and if that exists, include it in the error.

This would be great.