Re: [#202] reason phrase

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



On Wed, Aug 14, 2013 at 4:14 AM, Benjamin Carlyle <
benjamincarlyle@soundadvice.id.au> wrote:

>
> On 7 Aug 2013 01:56, "David Morris" <dwm@xpasc.com> wrote:
> > 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.
>
> 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.
>