Re: BCP56bis: advice for using status codes in applications

I'm having trouble understanding these paragraphs even after reading
them in context.

(disclaimer; this is my first time reading this draft since probably 01)

On Wed, 9 Jan 2019 at 13:51, Tommy Pauly <tpauly@apple.com> wrote:
>
> 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),

Since that's just an example, are there other valid (or invalid)
specifications of "implications"?

>conveying any
>    application-specific information in the message body and/or HTTP
>    header fields, not the status code.  [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.

What criteria was used to identify 201 and 404 as exceptions? It seems
to me that any generic code could be included.

Received on Thursday, 10 January 2019 15:23:02 UTC