"Warning" will be removed in next set of HTTP specs #125
Comments
|
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? |
|
you may want to bring up the use case; maybe we should reconsider the change wrt "warning"... |
|
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.
|
|
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? |
|
....HTTP mailing list... |
|
thinking out loud: another possibility would be to say that if |
|
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 |
|
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. |
|
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.
|
|
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.
|
|
FYI also related to: |
|
I'm closing this issue, since we've released a new version of the I-D, that now introduces a new header field. |
See https://greenbytes.de/tech/webdav/draft-ietf-httpbis-cache-06.html#header.warning.
The text was updated successfully, but these errors were encountered: