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

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