Handling DELETEs which flush the dispatcher cache

I have been working on the following problemette, which was posted to the DAY-CQ mailing list on Google.com :-

Hi CQ Community,

Does anyone know how to stop the dispatcher invalidating on a DELETE command down a path?

The reason why I ask is because we have a lot of usergenerated content which is being reverse replicated. When the UGC is moved, for security, from /content/usergenerated to /content/mysite/blah/blah, then the /content/usergenerated/... node is deleted on the publish server. Each of these delete commands triggers the flush agent.

I have tried defining a rep:policy to deny jcr:all on a user in /content/usergenerated/. This works for node additions but, deletions are not recognised. So I cannot stop it here.

I have tried to alter the configuration in the /invalidate section of dispatcher.any file to no avail. Is this sdection defining what objects get invalidated rather than what objects trigger an invalidation?

I also noticed that in the release notes of the dispatcher the following, which makes me think that invalidate on delete might be hard-wired ...

Issues resolved in 4.0.5:
25169 - Support flush on every write

Any help would be greatly appreciated!

This turned out to be a product bug - so it's in the queue to fix for a future version. Great!

In the meantime, we have come up with a workaround which is to implement a HTTP rewrite rule based upon the CQ-Handle /content/usergenerated (we don't need to flush on any changes in this area).

The key to intercepting the /dispatcher/invalidate.cache was to catch the CQ-Handle header /content/usergenerated and then to set CQ-Action to "TEST". This nullifies the request.