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

Re: BCP56bis: advice for using status codes in applications

From: Patrick McManus <mcmanus@ducksong.com>
Date: Wed, 9 Jan 2019 13:39:26 -0500
Message-ID: <CAOdDvNpuj-irK6K=VPfJ2eLBVXN24PHLSRmucD60tNVhSqKrcA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, "Julian F. Reschke" <julian.reschke@gmx.de>
Can you reference the specific text in 56bis that is being discussed.. it
would help focus the discussion. thanks!

On Wed, Jan 9, 2019 at 12:37 AM Mark Nottingham <mnot@mnot.net> wrote:

> 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 18:40:03 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 9 January 2019 18:40:05 UTC