Change Details

At @Fjalapeno 's request, I'm reviewing the old task list from [[ https://etherpad.wikimedia.org/p/kask | this Etherpad ]]. One task is for TTLs. The [[ https://www.mediawiki.org/wiki/Requests_for_comment/SessionStorageAPI | RFC ]] doesn't allow for setting TTLs per-request, and explicitly states that the service will have a single TTL configured per-server. > In the interest of simplicity, set operations as described here use a TTL defined on a service-wide basis (read: a single, configurable TTL, applied to all writes). In the event this proves inadequate, a backward-compatible change to enable client-supplied TTL overrides via a Cache-Control header is planned. This task is to check if this "proves inadequate". We're done when we've... * checked MediaWiki code to see if we set different session TTLs for different sessions within a wiki for some reason * checked if we have session TTLs set at different values for different wikis ----- ## More on TTL semantics One (implicit) design goal of Kask is to be better about our use of namespacing than our previous implementation under Redis (for session storage, central auth, and object stash). For example, we want sessions to be isolated in their own store, not intermixed with other, arbitrary data; Kask instances should be thought of as mapping 1:1 with some specific use-case. The status quo at the time of this writing (both code and RFC) is that Kask supports a single TTL value. This value is configured server-side (Kask-side), and applies to every value written. This was done under the assumption that this behavior would fit that 1:1, instance/use-case mapping. The RFC states that if this assumption proves false, any supplied TTL must be less-than or equal-to the default. Put another way, what is at question is //NOT// whether arbitrary TTLs are possible, but //whether the client can override the default with something shorter//. The rationale for limiting client TTLs like this is about bounding retention expectations. Unlike Redis, sessions in Kask are persisted and fall within Foundation policy with respect to retention of PII data. It should be possible to reason about retention and expiration based on an instances configuration.

At @Fjalapeno 's request, I'm reviewing the old task list from [[ https://etherpad.wikimedia.org/p/kask | this Etherpad ]]. One task is for TTLs. The [[ https://www.mediawiki.org/wiki/Requests_for_comment/SessionStorageAPI | RFC ]] doesn't allow for setting TTLs per-request, and explicitly states that the service will have a single TTL configured per-server. > In the interest of simplicity, set operations as described here use a TTL defined on a service-wide basis (read: a single, configurable TTL, applied to all writes). In the event this proves inadequate, a backward-compatible change to enable client-supplied TTL overrides via a Cache-Control header is planned. This task is to check if this "proves inadequate". We're done when we've... * checked MediaWiki code to see if we set different session TTLs for different sessions within a wiki for some reason * checked if we have session TTLs set at different values for different wikis ----- ## More on TTL semantics One (implicit) design goal of Kask is to be better about our use of namespacing than our previous implementation under Redis (for session storage, central auth, and object stash). For example, we want sessions to be isolated in their own store, not intermixed with other, arbitrary data; Kask instances should be thought of as mapping 1:1 with some specific use-case. The status quo at the time of this writing (both code and RFC) is that Kask supports a single TTL value. This value is configured server-side (Kask-side), and applies to every value written. This was done under the assumption that this behavior would fit that 1:1, instance/use-case mapping. The RFC states that if this assumption proves false, any supplied TTL must be less-than or equal-to the default. Put another way, what is at question is //NOT// whether arbitrary TTLs are possible, but //whether the client can override the default with something shorter//. The rationale for limiting client TTLs like this is about bounding retention expectations. Unlike Redis, sessions in Kask are persisted and fall within Foundation policy with respect to retention of PII data. It should be possible to reason about retention and expiration based on an instances configuration, and this will no longer be the case if clients are able to write arbitrary TTLs.

At @Fjalapeno 's request, I'm reviewing the old task list from [[ https://etherpad.wikimedia.org/p/kask | this Etherpad ]]. One task is for TTLs. The [[ https://www.mediawiki.org/wiki/Requests_for_comment/SessionStorageAPI | RFC ]] doesn't allow for setting TTLs per-request, and explicitly states that the service will have a single TTL configured per-server. > In the interest of simplicity, set operations as described here use a TTL defined on a service-wide basis (read: a single, configurable TTL, applied to all writes). In the event this proves inadequate, a backward-compatible change to enable client-supplied TTL overrides via a Cache-Control header is planned. This task is to check if this "proves inadequate". We're done when we've... * checked MediaWiki code to see if we set different session TTLs for different sessions within a wiki for some reason * checked if we have session TTLs set at different values for different wikis ----- ## More on TTL semantics One (implicit) design goal of Kask is to be better about our use of namespacing than our previous implementation under Redis (for session storage, central auth, and object stash). For example, we want sessions to be isolated in their own store, not intermixed with other, arbitrary data; Kask instances should be thought of as mapping 1:1 with some specific use-case. The status quo at the time of this writing (both code and RFC) is that Kask supports a single TTL value. This value is configured server-side (Kask-side), and applies to every value written. This was done under the assumption that this behavior would fit that 1:1, instance/use-case mapping. The RFC states that if this assumption proves false, any supplied TTL must be less-than or equal-to the default. Put another way, what is at question is //NOT// whether arbitrary TTLs are possible, but //whether the client can override the default with something shorter//. The rationale for limiting client TTLs like this is about bounding retention expectations. Unlike Redis, sessions in Kask are persisted and fall within Foundation policy with respect to retention of PII data. It should be possible to reason about retention and expiration based on an instances configuration, and this will no longer be the case if clients are able to write arbitrary TTLs.