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

[André Cedik <[e-mail]>]

Hey everyone and a happy new year,

I'd like to take the opportunity (since it is the first day back at work
for me) to get the ball rolling again.

Interestingly my first message in December seems to not have made it to the
list. At least that's what I get from the archive, where it is missing.
So I've added it to the end just for reference since the discussion has
already been going further.

Back to Darrel's question/suggestion.

I have certainly run into scenarios where there is value in returning
> warnings with a response and I've see the Warnings header from RFC 7234
> used in several cases.  However, the Warning header includes the Warn-Code
> to provide some details about the reason for the warning.  One advantage of
> using the Warning header was the fact that the warnings did not need to
> affect the structure of the payload.
> Would you consider a change to this draft that enabled representing
> details of the warning in the header itself?


Do you already have anything specific in mind? Maybe even an example when
warnings were returned using the Warnings header?
It would definitely make sense to have some kind of "code" to be returned
when a warning is present, but I am not sure if the use cases for different
APIs might be too specific to be handled by an overarching code. Hence
every API might need different codes for what they are trying to convey.
The advantage of returning the warnings in the body would be that more
specific information could be returned than trying to squeeze it into the
header.

Roberto is right. It would be possible to add more specific things using
the Content-Warning Type Registry

---

Original message:

> Thank you Rich for bringing this up again.
> I was planning on writing to the list about the draft, but haven't found
> the time yet. So it's great that you put some pressure on us.
> Let me try to answer two of the questions that came up during the IETF 109
> meeting.
>


Is this just for JSON documents?
> Absolutely not!
> It is the goal of the header to signal to a client that warnings are
> being returned.
> The value "embedded-warning" is merely one idea of telling this client,
> that more information can be found in the body.
> One could return a different content type than "application/json" and
> embed the warnings in there.
> The example shown in section 6 (
> https://tools.ietf.org/html/draft-cedik-http-warning-02#section-6) is
> just there so we have a proposition of how this could be returned.
> Ideally, we'd have a common way of returning warnings. Independent of what
> the content type is. But I'm not sure if this is possible.
>


Can we mix errors and warnings?
> If you have a look at the initial proposal - which was based on the
> warning header - we've had an example with errors and warnings.
> https://tools.ietf.org/html/draft-cedik-http-warning-00#section-5.2
> I can definitely see that there is a use case for having both at the same
> time since a warning could have occurred before the actual error came to
> be. So in this case returning the warning and the error could be helpful
> for a client.
> If you have further questions just let me know.


Best
André


On Tue, Dec 15, 2020 at 4:32 PM Roberto Polli <[e-mail]> wrote:

> Hi @all,
>
>
> Il giorno mar 15 dic 2020 alle ore 06:00 Darrel Miller
> <Darrel.Miller=[e-mail]> ha scritto:
> > > if
> > > there isn't enough interest, an alternative path may be to keep
> > > developing it as an individual draft
> I think this draft will benefit from a wider discussion, including the
> considerations provided by Darrell.
>
> > [..] I've see the Warnings header from RFC 7234 used in several cases.
> > [..] One advantage of using the Warning header was the fact that the
> warnings did not need to affect the structure of the payload.
> > Would you consider a change to this draft that enabled representing
> details of the warning in the header itself?
> iiuc this behavior can be configured via the content-warning-type: the
> payload one is  "embedded-warning",
> so the field definition already has an extension mechanism capable of
> supporting further types, eg "expensive-request" or "old-api-version"
> or whatever.
>
> I think this kind of discussions are the kind of activity of the workgroup.
>
> Have a nice day,
> R.
>
> --
> httpapi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/httpapi
>