W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2019

BCP56bis: advice for using status codes in applications

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 9 Jan 2019 16:34:19 +1100
Cc: "Julian F. Reschke" <julian.reschke@gmx.de>
Message-Id: <DD56873F-5680-443B-A9E7-93EED9FD0FA1@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
Promoting to a new thread, as suggested.

I explored the thinking behind this in a blog post a while back:
  https://www.mnot.net/blog/2017/05/11/status_codes

Julian, do you disagree with that, or just how it's expressed here?


> On 8 Jan 2019, at 8:31 pm, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> On 2019-01-08 10:11, Mark Nottingham wrote:
>> ...
>>>>> It talks about status codes in general; that includes new ones, no?
>>>> Potentially, but new status codes are required to be generic, not application-specific, so it ends up in the same place. Status codes are *not* a guaranteed end-to-end signal; they can (and often are) superseded by HTTP components in the middle.
>>> 
>>> Under certain well-understood circumstances, by design, or when there is a bug. My point is that they usually are reliable when the actual origin servers gets to respond.
>> Well-understood by implementers, perhaps, but often not application designers.
>>> I'm concerned that the current text will cause people to stuff all information into header fields or the payload, and just send 400.
>> Yes. Unless you want to intentionally trigger generic HTTP processing based upon a chosen status code, that's best practice.
>> ...
> 
> This is really news to me. This probably requires a new top-level thread.


--
Mark Nottingham   https://www.mnot.net/
Received on Wednesday, 9 January 2019 05:34:49 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 January 2019 05:34:50 UTC