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

On 07/09/2013, at 10:40 AM, Roy T. Fielding <fielding@gbiv.com> wrote:

> Sorry for missing the boat here, but this changes the warn-date
> to be a required field.

If you're generating a Warning header field, yes.


> As mentioned previously, no implementation
> that I am aware of actually sends a warn-date, let alone processes
> one, so now we have changed a never-implemented requirement into
> an everyone-who-implements-is-noncompliant requirement.

Actually, Apache httpd's mod_proxy_http appears to; see clean_warning_headers() and ap_proxy_clean_warnings(). 


> How does that help?
> 
> I thought what I heard from the last meeting was that we would
> remove all requirements on warn-date except for those recipients
> who actually process warning header fields.

I think we said that we'd remove requirements on those parties that don't do anything specific to Warnings.


> The 2616 requirements (and motivation) for warn-date are
> inherently bogus -- they assume that a Date header field
> will be originated by a non-conformant cache, such that a
> cached warning value will have a different date than a
> non-cached warning value.  I have no idea why that assumption
> was made, given that Date is defined as the origin's date of
> message creation, is supposed to be cached when a response
> is cached, and required to not be originated at each hop.
> Even non-conformant caches tend to implement that correctly,
> aside from the ones that don't save any header fields.

Revalidation updates Date, because it's required to be sent in a 304. So, you can detect whether revalidation has occurred if the warn-date and Date are different.

The point of warn-date is to detect cache revalidation, not just caching.

(I note that in RFC2616 the definition of 304 Not Modified explicitly requires Date, whereas p4 omits it, relying on the requirements for Date in p2. I'm a bit concerned that'll confuse implementers, since the list in p4 appears to be definitive.)

> 
> To reiterate again, NOBODY implements the requirements on
> warn-date.  
> 
> Even if it is implemented as specified, the end
> result is the same -- warnings are always ignored by recipients.
> This feature should be purged.

Right now, Apache *is* generating a lot of Warnings that will be incorrect if they pass through a cache, because most caches don't strip based upon warn-date (ironically, the one that I found is Apache, and it isn't including a warn-date, so that feature can't function). 

It seems to me that warn-date processing by the consuming implementation is necessary for the proper operation of the protocol, both by the spec (since 1.0 didn't include processing for Warning) and in reality (since most 1.1 intermediary / cache implementations are not stripping Warning). 

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.

I think we need to require warn-date in those Warnings that are affected by cache revalidation; specifically, the 1xx series. 

What if we constrained the requirement to include a warn-date to just those warnings?


--
Mark Nottingham   http://www.mnot.net/

Received on Monday, 9 September 2013 01:50:36 UTC