reason-phrase obsolete in RFC-7230

31 views
Skip to first unread message

Vinnie Falco

unread,
May 3, 2016, 7:50:01 AM5/3/16
to boosthttp-dev
The reason-phrase is obsolete in RFC7230:

"The reason-phrase element exists for the sole purpose of providing a
textual description associated with the numeric status code, mostly
out of deference to earlier Internet application protocols that were
more frequently used with interactive text clients. A client SHOULD
ignore the reason-phrase content."

Perhaps we can simply remove the field from the message class. When
serializing a HTTP/1 message, we could use a table to map the integer
status code to its canonical reason phrase.

This would eliminate an entire std::string from the interface.

Vinícius dos Santos Oliveira

unread,
Jun 12, 2016, 11:11:25 AM6/12/16
to Vinnie Falco, boosthttp-dev
2016-05-03 8:50 GMT-03:00 Vinnie Falco <vinnie...@gmail.com>:
Perhaps we can simply remove the field from the message class. When
serializing a HTTP/1 message, we could use a table to map the integer
status code to its canonical reason phrase.

I think this is a polemic change, but I'd agree with you as a solution to "what to do when the text is not on map?" is given.

What do you think about giving the string "REASON PHRASE UNKNOWN"?

Of course I'm talking about the server-side.


--
Vinícius dos Santos Oliveira

Vinnie Falco

unread,
Jun 12, 2016, 11:14:43 AM6/12/16
to Vinícius dos Santos Oliveira, boosthttp-dev
On Sun, Jun 12, 2016 at 11:11 AM, Vinícius dos Santos Oliveira
<vini.i...@gmail.com> wrote:
> I think this is a polemic change, but I'd agree with you as a solution to
> "what to do when the text is not on map?" is given.
>
> What do you think about giving the string "REASON PHRASE UNKNOWN"?

For sending response messages, the serialization algorithm will simply
insert the standard reason phrase text based on the status code. For
receiving response messages, the parser will just discard the reason
phrase text. It will not be accessible to callers. These changes are
reasonable based on the letter of rfc7230.

However, this is rather controversial and some clients might care
about the reason phrase, since the language in rfc7230 is a "SHOULD
NOT" rather than a "MUST NOT." Based on this interpretation, I don't
feel strongly about removing reason phrase support but it is an option
to consider in the future if we discover significant benefits to doing
so.

Vinícius dos Santos Oliveira

unread,
Jun 12, 2016, 11:28:12 AM6/12/16
to Vinnie Falco, boosthttp-dev
2016-06-12 12:14 GMT-03:00 Vinnie Falco <vinnie...@gmail.com>:
For sending response messages, the serialization algorithm will simply
insert the standard reason phrase text based on the status code.

That's the part that need a default string in case the status code is not know.

However, this is rather controversial and some clients might care
about the reason phrase, since the language in rfc7230 is a "SHOULD
NOT" rather than a "MUST NOT." Based on this interpretation, I don't
feel strongly about removing reason phrase support but it is an option
to consider in the future if we discover significant benefits to doing
so.

Sure. We can postpone this discussion for later.
Reply all
Reply to author
Forward
0 new messages