Re: BCP56bis: advice for using status codes in applications

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/
>
>
>