W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2013

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

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 09 Sep 2013 12:37:57 +0200
Message-ID: <522DA505.6090808@gmx.de>
To: "Roy T. Fielding" <fielding@gbiv.com>
CC: Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 2013-09-09 12:22, Roy T. Fielding wrote:
 > ...
>> If we follow your proposal and remove requirements around warn-date, someone can generate a Warning that persists in cache beyond a revalidation, and that condition won't be able to be detected. Apache is doing that right now by generating Warning fields without warn-date.
>
> Apache also generates some Warning header fields with bad syntax,
> probably because there are no examples in the spec.  Fixing that
> is way down there on my to-do list.
>
> We can keep the requirement that, when a warn-date exists AND
> a recipient is going to make some use of the Warning, THEN it
> has to be processed in some way.
>
> We cannot add a requirement that senders of Warning must send
> the warn-date, which is what the ABNF change does.  Aside from
> being a fantasy, it is incompatible with the grammar in 2068,
> and that is just as forbidden for us as it was for 2616.
> ...

Well, RFC 2068 has:


           Warning    = "Warning" ":" 1#warning-value

           warning-value = warn-code SP warn-agent SP warn-text
           warn-code  = 2DIGIT
           warn-agent = ( host [ ":" port ] ) | pseudonym
                           ; the name or pseudonym of the server adding
                           ; the Warning header, for use in debugging
           warn-text  = quoted-string

(<http://tools.ietf.org/html/rfc2068#section-14.45>) - so adding an 
optional date already was an incompatible change.


> ...

Best regards, Julian
Received on Monday, 9 September 2013 10:38:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:15 UTC