Re: Communicating Warning Information in HTTP APIs

[Eric J Bowman <[e-mail]>]

+.5



I have old XHTML 1.1 content on archive.org, wrapped by them and including an error explaining how their wrapper broke XML, but no tip-off in the headers that the content is changed -- it's in the body.



So, I can see "good actors" adopting this draft.



My rural-ISP history makes me consider content-injection ads. Such intermediaries will not be adopting this draft. What I want as a Web developer, is some way of warning a client that it's receiving altered content, period.



Which was the hope behind Content-Md5?



This use-case is not considered in the draft, I hoped it would be after reading the summary -- but the problem of alerting the user-agent to changed content is only solved by assuming good actors. May be insoluble for bad actors?



What about a removable Warning header? Arms-race problem, the bad actors will eventually figure it out, maybe someone has a better idea, but the scope this draft describes seems to include this issue without solving it, is my feedback.



-Eric




---- On Fri, 25 Sep 2020 05:37:55 -0700 André Cedik <[e-mail]> wrote ----



Hi everyone,



first of all, thank you all for your feedback in the past. Since the end of last year, a lot has happened. 



With version 01 of the draft, we've taken a new route, introducing a new field (Content-Warning) which contains a key to identify that warning information will be returned in the responses body. 



We've released version 02 of the draft yesterday, which now incorporates most of the feedback we've received. Special thanks go out to Roberto Polli.



Again all feedback is appreciated so we can work on making this happen.



All the best and have a great weekend

André






On Wed, Nov 6, 2019 at 6:51 AM Mark Nottingham <mailto:[e-mail]> wrote:

Hi André,
 
 My .02 is that Warning's semantics are not consistently used or implemented by intermediaries, which makes it less than useful. Its syntax is also... not great.
 
 If you have use cases, I'd recommend minting a new header field and starting fresh, rather than trying to reuse it.
 
 Cheers,
 
 
 > On 6 Nov 2019, at 5:58 am, André Cedik <mailto:[e-mail]> wrote:
 > 
 > Hey everyone,
 > 
 > Erik Wilde submitted an I-D on Monday - using the subject of this mail as the title (see https://datatracker.ietf.org/doc/draft-cedik-http-warning/) - that he and I wrote. It is our goal "to allow HTTP providers to have a standardized way of communicating to their consumers that while the response can be considered to be a non-failure, there is some warning information available that they might want to take into account".
 > 
 > Shortly after we submitted the draft Julian Reschke notified us (see https://github.com/dret/I-D/issues/125) that the Warning header is bound to be removed with the next spec (draft-ietf-httpbis-cache). Which is very unfortunate for the I-D since we wanted to use it for indicating that the client would find additional information within the response body. 
 > 
 > Since there is currently no other way of conveying this to an http client (that we know of), we'd really like to get feedback if this is a use case for which you would be willing to keep the Warning header or if there is another way to make something like this possible.
 > 
 > Best
 > André Cedik 
 
 --
 Mark Nottingham   https://www.mnot.net/