Re: BCP56bis: advice for using status codes in applications

> On 10 Jan 2019, at 8:22 am, Mark Baker <> wrote:
> 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 <> wrote:
>> I believe the text that started this discussion comes from section 4.6 (HTTP Status Codes):
>> 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"?

I think it's reasonable to have application-specific implications of classes of responses defined for a specific resource.

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

They don't have effect on generic HTTP implementations, beyond their Nxx semantics. 

Mark Nottingham

Received on Tuesday, 15 January 2019 19:37:29 UTC