Re: Proposal for #486: Requiring proxies to process warn-date

On 2013-09-02 02:47, Mark Nottingham wrote:
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/486>
>
> We discussed this issue in Berlin briefly, and I had an action to make a concrete proposal.
>
> In <https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#header.warning>:
>
> OLD:
> ---8<---
>     If an implementation sends a message with one or more Warning header fields
>     to a receiver whose version is HTTP/1.0 or lower, then the sender MUST
>     include in each warning-value a warn-date that matches the
>     Date header field in the message.
>
>     If a system receives a message with a warning-value that includes a
>     warn-date, and that warn-date is different from the Date
>     value in the response, then that warning-value MUST be deleted from the
>     message before storing, forwarding, or using it. (preventing the
>     consequences of naive caching of Warning header fields.) If all of the
>     warning-values are deleted for this reason, the Warning header field MUST
>     be deleted as well.
> --->8---
>
> NEW:
> ---8<---
>     RFC2616 made the Warning header field's warn-date component optional; it
>     was only required to be sent when the recipient's version was HTTP/1.0 or lower.
>
>     However, deployment experience has shown that many (if not most) intermediaries
>     do not process the Warning header as required by RFC2616. This results in
>     situations where the field can appear in messages where it is not applicable, because
>     a warning-value has not been removed by an intermediary.
>
>     As a result, this specification shifts responsibility for processing of Warning from
>     intermediaries to the recipient that is actually consuming them.
>
>     Generators of Warning header fields MUST include in every warning-value
>     a warn-date that matches the Date header field in the message. Recipients that
>     process a Warning header field MUST ignore (and MAY remove before forwarding)
>     a warning-value whose warn-date is different from the Date value in the response.
> --->8---
>
> We'd also remove the brackets in the ABNF that denote that warn-date is optional.
>
> Comments?
> ...

Indeed; I have to apologize for not paying attention before.

I have now tried to understand what's going on, and I'm confused.

1) "Warning" is not defined in HTTP/1.0 (right?). At least I don't see 
it in <http://tools.ietf.org/html/rfc1945>.

2) RFC 2068 does define Warning, but doesn't mention this issue at all: 
<http://tools.ietf.org/html/rfc2068#section-14.45>.

3) RFC 2616 has in 
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.46.p.19>:

"If an implementation sends a message with one or more Warning headers 
whose version is HTTP/1.0 or lower, then the sender MUST include in each 
warning-value a warn-date that matches the date in the response."

HTTPbis changed this to:

"If an implementation sends a message with one or more Warning header 
fields to a receiver whose version is HTTP/1.0 or lower, then the sender 
MUST include in each warning-value a warn-date that matches the Date 
header field in the message."

Was that an intentional change at all?

And what are we trying to achieve here?


Best regards, Julian

Received on Monday, 2 September 2013 13:04:59 UTC