CSS local cache stale with WebDAV connection

[JasonWoodward]

We've been successfully using Contribute 4 (Windows) against an Apache 2 WebDAV
server for several months now. Roughly 20 contributors have been updating
roughly 500 pages with little trouble (stale DAV locks here and there being the
worst) until now.

We've found that once you edit a page and the associated external style sheets
are downloaded into Contribute's local cache ("sites") the stylesheets are
always retrieved from cache (for edit mode) and never re-requested from the
server (even if they have been updated).

So, for instance, given the following XHTML snippet:

<link rel="stylesheet" type="text/css" href="/styles/screen-new.css" />
<link rel="stylesheet" type="text/css" href="/styles/contribute.css" />

... going into edit mode will cause both style sheets to be downloaded from
the server. But, subsequent changes to either of these style sheets (via
non-DW, non-Contribute editing on the server itself, in case that matters) will
not be reflected in edit mode UNTIL the local cache (the "site" directory) is
deleted by the end user. Browse mode is unaffected.

One thing I noticed when troubleshooting with wireshark (f.k.a. ethereal) was
that the GET requests for the style sheets (in edit mode) contained very few
headers. Conspicuously missing are the Accept and User-agent headers present
on most other requests issued by Contribute.

Has anyone else seen something similar? Any tips on what else to look at
before I escalate this to paid support?

[JasonWoodward]

We discovered what the problem was, so here it is for posterity.

Say you have A.html which references X.css which includes Y.css. If Y.css is
updated (the last modified date changes) without X.css changing (lastmodified
WebDAV PROPFIND request unchanged from cached version) then Contribute doesn't
bother with Y.css.

Updating the last modified date on X.css (when Y.css is changed) causes
Contribute to update the local copy.