Subject: [#202] reason phrase

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Aug 2013 15:45:18 +0200

https://github.com/http2/http2-spec/issues/202

#202 raises a question about the removal of the reason phrase.

I haven't heard of cases where the reason phrase carries semantics.  I
should hope that no implementation ever does that.

Those people that require semantics should be using headers.  I like
the current draft and would encourage people to leave this as it is.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Aug 2013 17:14:08 +0200

> the current draft and would encourage people to leave this as it is.

Right in principle.

However, people who feel strongly about the reason phrase will then just 
go ahead and mint a new header field; it would save everybody a lot of 
time if they wouldn't have to and just use a predefined header field.

Best regards, Julian

---

From: James M Snell <[email-masked]>
Date: Tue, 6 Aug 2013 08:52:38 -0700

+1 .. having a :reason header field would be cheap and painless. It
can be made optional and, I suspect, most implementations will ignore
it, but for the folks who use it (and I have seen a few) it avoids a
bit of hassle.

On Tue, Aug 6, 2013 at 8:14 AM, Julian Reschke <[email-masked]> wrote:
> However, people who feel strongly about the reason phrase will then just go
> ahead and mint a new header field; it would save everybody a lot of time if
> they wouldn't have to and just use a predefined header field.
>
> Best regards, Julian
>
>

---

From: David Morris <[email-masked]>
Date: Tue, 6 Aug 2013 08:55:34 -0700 (PDT)

> they wouldn't have to and just use a predefined header field.

I think I've seen code that examined the phrase but I don't recall where.
I've found the phrase semi-useful in casual debugging with wire level
data, but I'll freely agree that having a tool like wireshark add the
phrase as part of its interpretation would be much better.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 06 Aug 2013 23:38:32 +0200

> phrase as part of its interpretation would be much better.

The trouble with that is that you loose data.

"Is the 308 I see in this trace a permanent redirect, or the thing 
Google drive implemented without caring to specify it?"

Best regards, Julian

---

From: Benjamin Carlyle <[email-masked]>
Date: Wed, 14 Aug 2013 18:14:56 +1000

> phrase as part of its interpretation would be much better.

I've seen the reason phrase used for machine to machine cases in
conjunction with very general codes such as bad request or conflict, where
it hasn't been worth filling out the body but information about an error is
still useful for debugging. The use case is for debugging. The client
receives an unexpected error and the reason phrase gives them something to
grep for in the code or a description of the error that isn't relevant to
the actual client software. The body may be difficult to use in these cases
for whatever reason.

A header would be an acceptable alternative, but the current location
within the status line ensures current frameworks often make it slightly
simpler to add than using a sperate header. In the interests of being able
to pass messages between http 1 and 2 without loss of data it seems
worthwhile to at least retain it as a header. I agree that clients
shouldn't use the value beyond logging it though.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 14 Aug 2013 08:01:24 -0400

Hi Benjamin,

The http/1 reason phrase was never end to end. (easiest example is a cache
changing OK to be Not Modified.. but I don't see any reason it can't change
OK to LGTM). The use case you describe really needed to be in a header all
along.

-P