search

dret / I-D

Internet Drafts I've authored or contributed to.
16 stars 13 forks source link

content-warning: do we need to limit `warnings` semantic? #134

Open ioggstream opened 4 years ago

ioggstream commented 4 years ago

Note

The spec says

   When an condition occurs that can not be defined as a "hard error"
   (i.e., that allows clients to continue treating the resulting
   response as a success), additional information about this condition
   can be returned to the API client

In my understanding, this sentence suggests to limit the usage of warnings to non-hard-error.

We can just define warnings and let people use whenever their application logic requires it.

I

andrecedik commented 4 years ago

What we're trying to achieve is to create a standard way of returning warning information to a client. So from my point of view there is only this use case.

There are only two other options:

  1. Allow hard errors to be returned in the warnings object This makes no sense at all, since you are mixing errors and warnings which is what we're trying to get rid of.

  2. Be open about when to return warnings From what I've gotten from the feedback to the first version of our I-D, this is what happened with the Warning Header, that was/will be removed. The spec got interpreted in different ways and in the end it was best to remove it, since its original purpose was lost.