Set Cache-Control: no-cache for responses with an ETag

[garyttierney]

Background: right now browsers will cache IIIF resources to disk for the caching period before checking if new content is available. That means we're never sending up an If-None-Match and getting a corresponding 304, so we end up with stale data in the browser. This change makes clients always send an If-None-Match before using the local cache.

Related to #140

[donaldgray]

LGTM - brackets on same line is inconsistent with rest of code base (nothing enforcing this).

Worth adding a test, a regression here would cause FE issues?

[garyttierney]

Worth adding a test, a regression here would cause FE issues?

What test suite would that go in (i.e. do we have an integration suite in the .NET code, or do you mean e2e)?

[garyttierney]

LGTM - brackets on same line is inconsistent with rest of code base (nothing enforcing this).

Ah, I ran the auto-formatter but it changed way more, let me re-run it just on those lines.

[garyttierney]

Actually, it was the auto-formatter that put the braces on the same line. Can someone check the correct code style into the shared DotSettings in Rider?

[donaldgray]

What test suite would that go in (i.e. do we have an integration suite in the .NET code, or do you mean e2e)?

Integration tests are in https://github.com/dlcs/iiif-presentation/tree/main/src/IIIFPresentation/API.Tests/Integration - I think a test for this could be added to GET Manifest and/or Collection tests.

Using existing integration test class will bootstrap db (and localstack if required) and configure WebApplicationFactory for making http requests.