- From: Benjamin Carlyle <benjamincarlyle@soundadvice.id.au>
- Date: Wed, 14 Aug 2013 18:14:56 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Message-ID: <CAN2g+6b=nqY604D8F8tx8vRQwhVtYf79qGZFdC6Tf-9UwfBibw@mail.gmail.com>
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 08:15:23 UTC