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

On 09/09/2013, at 8:22 PM, Roy T. Fielding <fielding@gbiv.com> wrote:
>> 
>> 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).

I thought you might...


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

You said "recipients", I didn't.


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

Because revalidation doesn't delete headers; it only replaces them.

Consider a HTTP/1.0 cache that has stored:

HTTP/1.1 200 OK
Date: [one hour ago]
Content-Type: foo/bar
Warning: 123 Whatever
X-Thing: 1

When the 304 comes in, it gets:

HTTP/1.1 304 Not Modified
Date: [now]
Content-Type: foo/bar
Other-Thing: 2

which makes the updated cache entry:

HTTP/1.1 200 OK
Date: [now]
Content-Type: foo/var
Warning: 123 Whatever
X-Thing: 1
Other-Thing: 2

<https://svn.tools.ietf.org/svn/wg/httpbis/draft-ietf-httpbis/latest/p6-cache.html#freshening.responses> says that certain Warning headers are to be deleted by caches when this happens, but 1.0 caches don't know about it (and as we've seen, very few 1.1 caches implement it).


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

Nod

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

OK

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

With...?

If we're going to keep the Warning feature, it should be interoperable. That includes making current implementations non-conformant, if it will get us to a place where interop is improved. That's why I want to make this requirement.

Failing that, we can warn generators that omitting warn-date from 1xx warnings can result in them being erroneously cached, because of both the poor state of implementation and 1.0 caches -- in prose. 

I think that's pretty weak, but if you insist...


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

Received on Monday, 9 September 2013 10:34:55 UTC