{"action":"created","issue":{"url":"https://api.github.com/repos/plataformatec/faraday-http-cache/issues/80","labels_url":"https://api.github.com/repos/plataformatec/faraday-http-cache/issues/80/labels{/name}","comments_url":"https://api.github.com/repos/plataformatec/faraday-http-cache/issues/80/comments","events_url":"https://api.github.com/repos/plataformatec/faraday-http-cache/issues/80/events","html_url":"https://github.com/plataformatec/faraday-http-cache/issues/80","id":110136161,"number":80,"title":"Ability to cache GET requests that include a message body","user":{"login":"cgagon","id":3595788,"avatar_url":"https://avatars.githubusercontent.com/u/3595788?v=3","gravatar_id":"","url":"https://api.github.com/users/cgagon","html_url":"https://github.com/cgagon","followers_url":"https://api.github.com/users/cgagon/followers","following_url":"https://api.github.com/users/cgagon/following{/other_user}","gists_url":"https://api.github.com/users/cgagon/gists{/gist_id}","starred_url":"https://api.github.com/users/cgagon/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/cgagon/subscriptions","organizations_url":"https://api.github.com/users/cgagon/orgs","repos_url":"https://api.github.com/users/cgagon/repos","events_url":"https://api.github.com/users/cgagon/events{/privacy}","received_events_url":"https://api.github.com/users/cgagon/received_events","type":"User","site_admin":false},"labels":[],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":1,"created_at":"2015-10-07T01:38:24Z","updated_at":"2015-10-07T17:59:45Z","closed_at":"2015-10-07T17:59:45Z","body":"It's legal, although perhaps controversial in terms of REST, to include a message body in a GET.   For example, there are services such as Elasticsearch which require a verbose JSON-encoded message be included in the body along with the search endpoint in the URI in order to use its query DSL.  \r\n\r\nAs such, we'd like to be able to leverage this caching middleware but in order to do so, the message body needs be included in the strings that are fed to the SHA1 hexdigest when constructing the cache key.  This is of course straightforward in and of itself.  The problem arises in workflows where the cache should be invalidated and only the relevant resource URI is given.\r\n\r\nIn the current implementation, a cache prefix and the url are used to construct the key.   And when invalidating the cache the URL is fed back to the storage instance:  https://github.com/plataformatec/faraday-http-cache/blob/master/lib/faraday/http_cache.rb#L285-L290 \r\n\r\nHas anyone attempted to solve this problem previously?  It would be helpful to support caching messages with the body included in the hexdigest for the key, but invalidation needs to be solved in order for this to be a safe general purpose modification to the middleware."},"comment":{"url":"https://api.github.com/repos/plataformatec/faraday-http-cache/issues/comments/146278816","html_url":"https://github.com/plataformatec/faraday-http-cache/issues/80#issuecomment-146278816","issue_url":"https://api.github.com/repos/plataformatec/faraday-http-cache/issues/80","id":146278816,"user":{"login":"lucasmazza","id":80978,"avatar_url":"https://avatars.githubusercontent.com/u/80978?v=3","gravatar_id":"","url":"https://api.github.com/users/lucasmazza","html_url":"https://github.com/lucasmazza","followers_url":"https://api.github.com/users/lucasmazza/followers","following_url":"https://api.github.com/users/lucasmazza/following{/other_user}","gists_url":"https://api.github.com/users/lucasmazza/gists{/gist_id}","starred_url":"https://api.github.com/users/lucasmazza/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/lucasmazza/subscriptions","organizations_url":"https://api.github.com/users/lucasmazza/orgs","repos_url":"https://api.github.com/users/lucasmazza/repos","events_url":"https://api.github.com/users/lucasmazza/events{/privacy}","received_events_url":"https://api.github.com/users/lucasmazza/received_events","type":"User","site_admin":false},"created_at":"2015-10-07T17:59:45Z","updated_at":"2015-10-07T17:59:45Z","body":"@cgagon I think in such cases one might implement this through a generic caching like dalli or `Rails.cache` rather than in the HTTP level, since using the GET body makes it way more complicated to deal with invalidations and request equivalence inside the caching logic.\r\n\r\nRegardless of the solution, we rather keep the gem spec compliant without adding non standard rules to how the middleware works on dealing with the cache.\r\n\r\n"}}