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

On Sep 8, 2013, at 6:50 PM, Mark Nottingham wrote:
> 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(). 

Yes, and I would like to delete that code (or at least the bits
that are not needed).

>> 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.

Is there a distinction that I am missing?

> 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.

Why would revalidation occur (with updated Date) without the
1xx Warnings being deleted?

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

Okay.

> (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.)

We can add that back in if you think it's needed.

>> 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). 

I am pretty sure that Apache doesn't care, other than the desire
to be conformant with the standard.

> 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).

I don't see how.  Warning isn't necessary for the proper operation
of the protocol, which is why clients ignore them.

> 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.

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

Why?  I don't care how many ways a Warning might become stale;
nobody sees the Warnings, and even if they did we can't trust a
refreshed cache entry to actually be "fresh" in any reasonable
sense if the same cache didn't even bother to implement 1xx
Warning deletion; it is "safer", in that case, to assume the old
Warning is true until that cache kicks the bucket, since these
are all Warnings about how the content *might* be stale.

However, that notion of "safe" is hardly relevant given the
client isn't going to say anything to a user about the Warning.
Do you know of any client code (UA or cache) that changes
behavior based on a received Warning?

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

Still incompatible.

....Roy

Received on Monday, 9 September 2013 10:22:53 UTC