Hey folks - I don't have time to look at in detail right now, but in debugging a problem with OAuth I stumbled across the HttpCache interface. I think it may be broken in at least two ways.
1) It doesn't take into account request method when checking the cache. URI alone is sufficient. The requests HEAD /foo, POST /foo and GET /foo have totally different cache semantics. Are these being handled somewhere? 2) It doesn't take into account authentication. A signed request for a GET /foo shares the same cache namespace as an unsigned GET /foo. It looks like the SigningFetcher class is very careful to strip out any unpredictable portions of the URI to improve the cache hit rate, with the end result that you can retrieve data intended for another user simply by knowing their opensocial id: just send a makeRequest with authn=NONE, and craft the URL to match what SigningFetcher creates for the cache! Again, excuse me if I'm missing something here; I've only read the code briefly, I haven't really tested either of these, and I may have missed the code that addresses these issues. Cheers, Brian
