Re: BCP56bis: advice for using status codes in applications

I believe the text that started this discussion comes from section 4.6 (HTTP Status Codes): https://tools.ietf.org/html/draft-ietf-httpbis-bcp56bis-08#section-4.6

The specific text of interest is:

   Instead, applications using HTTP should specify the implications of
   general classes of responses (e.g., "successful response" for 2xx;
   "client error" for 4xx and "server error" for 5xx), conveying any
   application-specific information in the message body and/or HTTP
   header fields, not the status code.  [RFC7807 <https://tools.ietf.org/html/rfc7807>] provides one way for
   applications using HTTP to do so for error conditions.

   There are limited exceptions to this; for example, applications might
   use 201 (Created) or 404 (Not Found) to convey application semantics
   that are compatible with the generic HTTP semantics of those status
   codes.  In general, though, applications should resist the temptation
   to map their semantics into fine-grained status codes.

Thanks,
Tommy


> On Jan 9, 2019, at 10:39 AM, Patrick McManus <mcmanus@ducksong.com> wrote:
> 
> 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 <mailto: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 <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 <mailto: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/ <https://www.mnot.net/>
> 
>