fix(dav): make contact photo cache max-age configurable

[arndttouby]

Summary

Make the Cache-Control: max-age value for contact photo exports configurable via the app config key dav.contact_photo_cache_max_age (default: 3600).

This addresses the concern raised in the initial review: removing caching for 204 No Content responses would cause unnecessary database lookups on large installations. Instead, the default behavior is preserved (1 hour cache), but administrators can tune the value as needed — including setting it to 0 for development or debugging.

Changes

• ImageExportPlugin.php: Inject IConfig, read contact_photo_cache_max_age app value (default 3600), use it in the Cache-Control header instead of a hardcoded value.
• Server.php: Pass IConfig as second argument to ImageExportPlugin constructor.
• ImageExportPluginTest.php: Add IConfig mock to existing tests, add two new test cases (testCardWithCustomMaxAge with 120s, testCardWithZeroMaxAge with 0s).

Usage

# Set a custom max-age (e.g. 2 minutes)
occ config:app:set dav contact_photo_cache_max_age --value=120

# Disable caching entirely
occ config:app:set dav contact_photo_cache_max_age --value=0

# Reset to default (1 hour)
occ config:app:delete dav contact_photo_cache_max_age

Checklist

• Code changes
• Unit tests added
• Default behavior unchanged (max-age=3600)
• No performance regression (no additional DB queries by default)

[SebastianKrupinski]

Hi @arndttouby

Thank you for taking the time to create this PR.

[SebastianKrupinski]

So the code looks good.

But there is a down side to this change and probably why the code was originally written the way it was.

Yes the changes you made address one specific scenario, when a user adds a photo, the photo might not show for an hour.

But the changes now causes the client to continuously make requests for photos that don't exist every time the page loads, this would cause 1000's of unneeded requests on some systems, that access the database to check if there is a photo.

I think the trade off, of the one hour delay vs the performance impact of the changes you are suggesting is worth it.

[arndttouby]

Hi @SebastianKrupinski, thanks for the thorough review — your concern about the performance impact is absolutely valid.

I've reworked the approach based on your feedback. Instead of moving the Cache-Control header inside the try/catch (which would remove caching for 204 responses and cause unnecessary DB lookups), the new implementation makes max-age configurable via an app config value:

$maxAge = $this->config->getAppValue('dav', 'contact_photo_cache_max_age', '3600');

Key points:

• Default behavior is unchanged — max-age=3600 (1 hour) remains the default, so there is no performance regression on existing installations.
• Administrators can tune it — e.g. occ config:app:set dav contact_photo_cache_max_age --value=120 for a shorter cache, or --value=0 to disable caching entirely for debugging.
• IConfig is injected via the constructor (already available in Server.php).
• I've also added unit tests for custom max-age (120s) and zero max-age (0s) scenarios.

This way, the one-hour default stays in place for large installations, but smaller setups or admins who need faster photo updates have a knob to turn.