"Warning" will be removed in next set of HTTP specs

[reschke]

See https://greenbytes.de/tech/webdav/draft-ietf-httpbis-cache-06.html#header.warning.

[dret]

interesting. it will still exist and be used, right? i am not even sure how this is getting handled in the registry, you cannot really legislate existing header fields out of existence, right? but given that it may not be recommended anymore: is there a similar mechanism you would suggest? we're trying to surface a "warning", i.e. something that can be ignored, but still may be interesting to look at.

[reschke]

you may want to bring up the use case; maybe we should reconsider the change wrt "warning"...

[dret]

On 2019-11-05 07:20, Julian Reschke wrote:

you may want to bring up the use case; maybe we should reconsider the change wrt "warning"...

it always seemed odd to me that warning on the one hand sounded very caching-specific, but at least spec language wise did allow other scenarios as well. we were actually curious to see whether there would be any pushback against a non-caching use.

i would suggest keeping the header and registry, but making it clear that it is not specific to caching info. i am guessing other scenarios might pop up once people realize that there is a general place to surface warnings in HTTP.

[andrecedik]

Thanks again for the feedback @reschke. What's the best place to get this sorted out? Back in the original issue, should we create a new one (in that repo) or is there another place that is better suited for discussing this?

[reschke]

....HTTP mailing list...

[dret]

thinking out loud: another possibility would be to say that if Warning is removed from the caching spec (which may make sense if it is not used in this context), we define and register it in our draft as a more general warning mechanism. the downside to this would be that we would depend on the caching spec being published.

[ioggstream]

Afaik headers can be deprecated but not removed from the table. The removal imho would allow a re-registration.

We can say that warning is deprecated for caching purposes. We should even check if other specs references Warning.

Still I'm not sure if we can modify the syntax of an already existing header, but maybe it's possible

[royfielding]

In general, Warning for anything other than gateway issues (i.e., control information that cannot change the content because it doesn't own the content) is a bad design because nobody can determine when and how to implement it consistently. Even for caching, it turns out that nobody is interested in implementing or displaying a Warning about something that they had no control over, since all it does is provoke a user complaint to the entity that has no power or interest in fixing it.

In the API case, warnings belong in the response data format. They have to identify both the semantics of the warning and the extent of the response data to which it applies. Providing that in a header field is nearly impossible, and certainly not supported by the existing syntax of the Warning header field. It has been deprecated both because it looks like a response status code and because the information it supplies is not actionable by the recipient. Placing the warning directly within the data format can be both distinct from the status and actionable within the processing definition of that format.

[dret]

On 2019-11-06 13:58, Roy T. Fielding wrote:

In the API case, warnings belong in the response data format. They have to identify both the semantics of the warning and the extent of the response data to which it supplies. Providing that in a header field is nearly impossible, and certainly not supported by the existing syntax of the Warning header field. It has been deprecated both because it looks like a response status code and because the information it supplies is not actionable by the recipient. Placing the warning directly within the data format can be both distinct from the status and actionable within the processing definition of that format.

that's what https://tools.ietf.org/html/draft-cedik-http-warning proposes: a way to embed warning info in the response. the warning header field is something that could make it more obvious for clients to figure out whether such a warning is present or not, but we certainly do not expect that the warning header field in itself will be sufficient to do something about the warning.

the draft as published proposes a JSON structure to be embedded. the warning code serves as an indication that there is embedded warning info, but it does not require the specific JSON structure to be used. what we're shooting for is to provide a pattern that designers can choose to use when they want such a warning mechanism in their API.

[dret]

On 2019-11-06 12:58, Roberto Polli wrote:

Afaik headers can be deprecated but not removed from the table. The removal imho would allow a re-registration.

i sure hope so. it would be bad registry design to allow things to be removed and potentially re-allocated to something different.

We can say that warning is deprecated for caching purposes. We should even check if other specs references Warning.

it could still be used for caching, no? it seems people don't find it useful, but if the semantics are extended to more explicitly allow non-caching use cases, then caching use cases would still fit the bill.

Still I'm not sure if we can modify the syntax of an already existing header, but maybe it's possible

do we have to? the current syntax may be a good-enough fit for more general use cases as well.

https://tools.ietf.org/html/rfc7234#section-5.5

the exception may be the "warn-agent" field that seems a bit odd for more general use cases, but "-" is allowed for unknown agents and then it doesn't look impossible to stick with the existing syntax.

[ioggstream]

FYI also related to:

• https://github.com/whatwg/fetch/issues/913
• https://github.com/httpwg/http-core/issues/139

[andrecedik]

I'm closing this issue, since we've released a new version of the I-D, that now introduces a new header field.