Re: [httpapi] Discussion of adopting Content-Warning header

Mark Nottingham <mnot@mnot.net> Thu, 28 January 2021 08:29 UTC

Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.40.0.2.32\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <CAEQcYZhF4X9c+4zknGvCQgW4mgcemMTG66dhH6S7=9bVDjmeYQ@mail.gmail.com>
Date: Thu, 28 Jan 2021 19:28:53 +1100
Cc: "Salz, Rich" <rsalz=40akamai.com@dmarc.ietf.org>, "httpapi@ietf.org" <httpapi@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3A31FE3-A2DA-4A8C-B18E-0D1DFD999E12@mnot.net>
References: <88ED49DB-E081-4C97-9FB9-080A1C585435@akamai.com> <C6EF74FA-4987-48EB-8F7B-74EB54C295CD@mnot.net> <CAEQcYZhF4X9c+4zknGvCQgW4mgcemMTG66dhH6S7=9bVDjmeYQ@mail.gmail.com>
To: André Cedik <andre.cedik@googlemail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/httpapi/CHBZXoiZmdbUQ-n4LK58cf2Ue-E>
Subject: Re: [httpapi] Discussion of adopting Content-Warning header
Precedence: list

Hi André,

> On 28 Jan 2021, at 7:21 pm, André Cedik <andre.cedik@googlemail.com> wrote:
> 
> The challenge with warnings from my point of view is the fact that the original request was successful - in our case, a shipping label has been created - but there were "side effects" that may need to be addressed. If it would only boil down to this I'd say "let's create a content-type application/warnings+json" or something similar. But I would make the assumption that there are use cases where warnings and errors can both happen with one request. Maybe because something happened at an intermediary and the destination server which is processing the request is throwing e.g. a server error. This is one of the reasons why we opted to make it a header field. The other being that there might be other use cases where an "embedded-warning" doesn't make sense. This is why the concept of a registry was introduced to create other warning types.

I'm not sure that assumption holds. There may indeed be other use cases for warnings in APIs that justify a header, but without seeing them, it's hard to tell if the design you've proposed will address them. Your use case can be addressed by using RFC7807, so why not just use that?

Cheers,


--
Mark Nottingham   https://www.mnot.net/

[httpapi] Discussion of adopting Content-Warning … Salz, Rich
Re: [httpapi] Discussion of adopting Content-Warn… Erik Wilde
Re: [httpapi] Discussion of adopting Content-Warn… Darrel Miller
Re: [httpapi] Discussion of adopting Content-Warn… Roberto Polli
Re: [httpapi] Discussion of adopting Content-Warn… André Cedik
Re: [httpapi] Discussion of adopting Content-Warn… Mark Nottingham
Re: [httpapi] Discussion of adopting Content-Warn… André Cedik
Re: [httpapi] Discussion of adopting Content-Warn… Mark Nottingham
Re: [httpapi] Discussion of adopting Content-Warn… Roberto Polli
Re: [httpapi] Discussion of adopting Content-Warn… Asbjørn Ulsberg