RFC: Pull out status_t to the top level to allow using those enum values from clients. #837
Conversation
Thanks @igorpeshansky -- I love this idea. We might even be able to consolidate this with the server-side defined status codes as well. Feedback follows. |
namespace http { | ||
|
||
/// The set of known status codes for HTTP server responses. | ||
enum status_t { |
deanberris
May 1, 2018
Member
If we're doing this, then I suggest dropping the _t
suffix, and calling it status_code
to be more descriptive.
Also, if we're going to do this as well, we might as well add the following:
- An "unknown" value to be the default (say,
0
).
- More known status codes, even those that are extensions -- we can probably do those later on, instead of in this PR.
If we're doing this, then I suggest dropping the _t
suffix, and calling it status_code
to be more descriptive.
Also, if we're going to do this as well, we might as well add the following:
- An "unknown" value to be the default (say,
0
). - More known status codes, even those that are extensions -- we can probably do those later on, instead of in this PR.
@@ -0,0 +1,39 @@ | |||
#ifndef BOOST_NETWORK_PROTOCOL_HTTP_STATUS_HPP_20180501 | |||
#define BOOST_NETWORK_PROTOCOL_HTTP_STATUS_HPP_20180501 |
deanberris
May 1, 2018
Member
Consider naming this file status_code.hpp
along with the suggested change to the enum name.
Consider naming this file status_code.hpp
along with the suggested change to the enum name.
@igorpeshansky can you also PR this to branch 0.13-release? |
@deanberris PTAL. Would like to gauge if this change is actually a good idea.