{"issue":{"title":"Caching of ALLOW/DENY result should not be time based","user":{"id":1240282,"login":"jsamuel","url":"https://api.github.com/users/jsamuel","avatar_url":"https://secure.gravatar.com/avatar/bc1d195cedb959a3946572b08ce9e7c7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"bc1d195cedb959a3946572b08ce9e7c7"},"milestone":null,"created_at":"2011-12-22T02:41:13Z","labels":[{"name":"extension","url":"https://api.github.com/repos/RequestPolicy/tractest/labels/extension","color":"ededed"}],"state":"open","updated_at":"2011-12-22T02:41:17Z","id":2632378,"html_url":"https://github.com/RequestPolicy/tractest/issues/123","closed_at":null,"pull_request":{"patch_url":null,"html_url":null,"diff_url":null},"body":"Currently ALLOW/DENY results are cached based on a seemingly arbitrary time interval:\r\n\r\n  '''/components/requestpolicyService.js'''\r\n\r\n{{{\r\n  /**\r\n   * Number of elapsed milliseconds from the time of the last shouldLoad() call\r\n   * at which the cached results of the last shouldLoad() call are discarded.\r\n   *\r\n   * @type Number\r\n   */\r\n  _lastShouldLoadCheckTimeout : 200,\r\n}}}\r\n\r\nWhile the chosen interval is short, it does not preclude the possibility that the user may have changed policy in that interval.\r\n\r\nFurther, if a cache is warranted (and is secure), the cache should ONLY be invalidated IF policy changes (and perhaps if the user clears browser cache).  This should also have the benefit of improving performance...","number":123,"url":"https://api.github.com/repos/RequestPolicy/tractest/issues/123","comments":2,"assignee":null},"comment":{"user":{"id":1240282,"login":"jsamuel","url":"https://api.github.com/users/jsamuel","avatar_url":"https://secure.gravatar.com/avatar/bc1d195cedb959a3946572b08ce9e7c7?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"bc1d195cedb959a3946572b08ce9e7c7"},"created_at":"2011-12-22T02:41:17Z","updated_at":"2011-12-22T02:41:17Z","id":3243077,"body":"[eibwen] Requesting further details regarding what is being interpreted as \"repeated\" requests, such as an example page that generates such repeated requests.\r\n\r\nFrom my testing it appears that what is likely referred to as \"repeated\" requests include:\r\n * Multiple partial content requests (potentially overlapping in whole or part)\r\n * Repeated inclusions of blocked and non-cached resources on a page\r\n\r\nRegardless of whether repeated requests are actually being made, the cache needs to be invalidated on policy change, regardless of the cache duration.  If a user changes policy, it should take effect immediately, not after the cache expires.  This may also include closing of connections that violate the new policy.\r\n\r\nIf cache is not always invalidated on policy change, priority should be restored.\r\n\r\nIf cache is invalidated on policy change, this should be changed to an enhancement and priority reassessed accordingly.\r\n\r\nFurther, unless use of the cache is substantially faster, the cache should likely be eliminated regardless.  Browsing with the cache duration set to -1 ms (cache always expired), have not perceived any slow down due to repeated policy checks.  It would be an interesting experiment to see if increasing the cache duration results in a perceived performance increase...","url":"https://api.github.com/repos/RequestPolicy/tractest/issues/comments/3243077"},"action":"created"}