Closed evanp closed 7 months ago
Hmm. Are you worried about 200 responses to signed requests getting cached and returned to later requests without signatures?
Otherwise, HTTP error responses like 401s to unsigned requests generally aren't cached, right?
this is correct, using authorized fetch basically means you can never use HTTP caching
Of course, your welcome to do your caching "inside" of the HTTP Signature validation, with your application cache, as long as you're sure you've done all your authorization checks first.
On Thu, Feb 8, 2024, 8:11 PM Ryan Barrett @.***> wrote:
Hmm. Are you worried about 200 responses to signed requests getting cached and returned to later requests without signatures?
Otherwise, HTTP error responses like 401s to unsigned requests generally aren't cached, right?
— Reply to this email directly, view it on GitHub https://github.com/swicg/activitypub-http-signature/issues/23#issuecomment-1935233464, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCVZOQ4EWGAVSGMSROSDYSWAVTAVCNFSM6AAAAABDAXM2SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZVGIZTGNBWGQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hmm. Are you worried about 200 responses to signed requests getting cached and returned to later requests without signatures?
Otherwise, HTTP error responses like 401s to unsigned requests generally aren't cached, right?
I'm talking about If-Modified-Since, If-None-Match, 304 Not Modified style caching.
I don't see how that would be affected? The server is free to check the ETag or If-Modified-Since header either before or after validating the signature and making whatever decision it wants to based on that, and a 304 response is still possible.
On Mon, Feb 12, 2024 at 3:18 PM Evan Prodromou @.***> wrote:
Hmm. Are you worried about 200 responses to signed requests getting cached and returned to later requests without signatures?
Otherwise, HTTP error responses like 401s to unsigned requests generally aren't cached, right?
I'm talking about If-Modified-Since, If-None-Match, 304 Not Modified style caching.
— Reply to this email directly, view it on GitHub https://github.com/swicg/activitypub-http-signature/issues/23#issuecomment-1939505125, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABZCVZQL34OQIIPUNS53KDYTJ2JTAVCNFSM6AAAAABDAXM2SKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZZGUYDKMJSGU . You are receiving this because you commented.Message ID: @.***>
I got curious about this just now and spot tested some of the most popular fediverse server projects by fetching objects with HTTP Signatures. Only Mastodon currently include Signature
in Vary
. Here's what I got:
Hell, forget Signature
, only Mastodon even includes Accept
! Ugh.
Initial draft text below. Please review and revise!
HTTP responsees are cached in a wide variety of ways across the web. HTTP Signatures in ActivityPub requests can affect the resulting responses, so clients and servers both need to take signatures account when interacting with caches.
The main thing ActivityPub servers need to do is include Signature
in their Vary
header for responses that depend on request signatures, eg if they require authorized fetch and would return a 4xx error if a signature is missing or invalid. This prevents valid responses from being cached and returned to other future requests with missing or invalid signatures.
(This is similar to including Content-Type
in the Vary
response header for URLs that can return either user-facing HTML or ActivityStreams JSON, depending on content negotiation.)
One downside of this is that ActivityPub objects from servers that require authorized fetch generally can't be cached. HTTP Signatures include timestamps, and are generated by different private keys, so they'll almost never be the same across requests. This is an unfortunate side effect, but necessary for servers that want to control access based on the requester's identity.
@snarfed awesome, thank you!
I think the
Signature
header really messes things up for HTTP caching usingLast-Modified
andETag
headers.Because the authentication is all in the
Signature
header, you need to include theSignature
in theVary
header. But the signature will never be the same twice -- it will always include theDate
, so the signature field will always be different.It might be possible to leave the signature out of the
Vary
field for public objects, unless you're using authorized fetch.Somebody correct me if I'm way off here!