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

Hi Mark,

On Mon, Sep 02, 2013 at 10:47:58AM +1000, 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?

Seems good, it follows the same principle we have in the whole draft which
is that the first who is really able to clean up the mess does it, so this
will increase overall compliance of deployed solutions.

Regards,
Willy

Received on Monday, 2 September 2013 04:23:32 UTC