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

Re: BCP56bis: advice for using status codes in applications

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 15 Jan 2019 12:37:00 -0700
Cc: Tommy Pauly <tpauly@apple.com>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>, "Julian F. Reschke" <julian.reschke@gmx.de>
Message-Id: <3205ADCA-6381-4040-B536-669C00D2CDEB@mnot.net>
To: Mark Baker <distobj@acm.org>

> On 10 Jan 2019, at 8:22 am, Mark Baker <distobj@acm.org> 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 <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"?

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   https://www.mnot.net/
Received on Tuesday, 15 January 2019 19:37:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 15 January 2019 19:37:30 UTC