W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

Re: [#202] reason phrase

From: Patrick McManus <mcmanus@ducksong.com>
Date: Wed, 14 Aug 2013 08:01:24 -0400
Message-ID: <CAOdDvNo0dpf=S0RPyLWoUzSjvo5hqNp1fnA6902SDvykYL4GAg@mail.gmail.com>
To: Benjamin Carlyle <benjamincarlyle@soundadvice.id.au>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
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.
>
Received on Wednesday, 14 August 2013 12:01:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:14 UTC