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

[Asbjørn Ulsberg <[e-mail]>]

3 tor. 28. jan. 2021 kl. 09:50 skrev Roberto Polli
<[e-mail]>:

> imho there is a general interest in a replacement of the `Warning`
> header (eg. to set alerts in payload-agnostic monitoring systems).

I also envision the utility of intermediaries adding Content-Warning
to indicate trouble understanding the request or response in one way
or another, which may lead to a much better developer experience when
these intermediaries are added to a request or response pipeline.

> My suggestion to André - that may still not address Mark's concerns - is to:
> 1- dis-entangle his proposal from the `Content` (eg. `Api-Warning`)

+1. I think "Warning" is a good name, but think it has greater utility
in being general and content type agnostic. Think about a reverse
proxy being configured to perform CSS minification, for instance; if
it fails parsing the CSS, it can leave the CSS untouched but add a
Warning in the response regarding the syntax error it encountered.

> 2- retain the "warning-type" registry, which can specify the type of
> warning including content-warning

On first skimming of the draft, I actually thought the "type" was
equal to "type" in RFC 7807, i.e. a URI. I was both surprised and a
bit disappointed to learn that was not the case.

I think having a registry for different warning types adds needless
friction and bureaucracy, without providing much benefit. Using a URI
like in RFC 7807 allows the same types already minted for problem+json
to be reused, allows for distributed and friction-free creation of
types and makes it possible for type URIs to be dereferenced directly
in order to read more about why the warning occurred and how it can be
remedied.

-- 
Asbjørn Ulsberg           -=|=-        [e-mail]
«He's a loathsome offensive brute, yet I can't look away»