Interactions with HTTP Caching

[punkeel]

How is HTTP Caching impacted by this RFC?

As a developer, should I add Accept-Signature to the Vary header? Does adding the nonce signature parameter change that?

Is 304 a valid response for a request with a Accept-Signature header?

[mikewest]

I don't think there are any unique implications for caching. The headers used by this mechanism act exactly as other headers delivered with a given response. If the resource changes, the signature will certainly change as well, and it would be ideal to replace the resource in caches generally.

Nonces would make signatures more dynamic, potentially changing per-request rather than when the underlying resource changes. Right now, there's nothing forcing you to use nonces, nothing checking the nonces, and therefore little benefit to using them. I'm imagining we'd add that in the future by tacking an option onto the integrity attribute (e.g. integrity="ed25519-[key goes here]?nonce=12345), at which point you'd certainly want to Vary the response on the Signature-Input header. Until then, however, there's not much value in them one way or the other (This reminds me to add that as a future extension point: filed as #41).

I do think there's probably some benefit in recommending that developers Vary on Signature-Input though. Does that match your expectation?

Regarding 304s, I think they'd be a valid response, insofar as I'd expect the client to use its cached resource (just as we do today for content-based integrity checks). Are there particular challenges there you think we should document?