[Webkit-unassigned] [Bug 40627] Limit ApplicationCache Total and Per-Origin Storage Capacity (Quotas)

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=40627





--- Comment #19 from Joseph Pecoraro <joepeck at webkit.org>  2010-06-17 17:20:44 PST ---
(In reply to comment #18)
> I'm discussing this patch with Joseph. Not sure if per-appcache quota
> is the right way to go, given that we usually have per-origin quotas.

Background: 
-----------

I took a look at this and thought about what changes might be necessary
for this to happen. Databases use per-origin quotas. They do so with
"DatabaseTracker" which uses its own sqlite database (for persistence)
to store origins and their quotas. See
DatabaseTracker::openTrackerDatabase in:
http://trac.webkit.org/browser/trunk/WebCore/storage/DatabaseTracker.cpp

In Safari you can see this in ~/Library/Safari/Databases/Databases.db:

>   > sqlite3 ~/Library/Safari/Databases/Databases.db
>   > .dump
>   CREATE TABLE Origins ( origin TEXT UNIQUE ON CONFLICT REPLACE
>                        , quota INTEGER NOT NULL ON CONFLICT FAIL);
>   CREATE TABLE Databases ( guid INTEGER PRIMARY KEY AUTOINCREMENT
>                          , origin TEXT, name TEXT, displayName TEXT, estimatedSize INTEGER, path TEXT);


Application cache's currently only use origins in the fetching
process to select particular resources, ignore others, and so
on. Once the resources are downloading it doesn't look like
the origin is needed. So it didn't need to keep it around.
Instead, if it makes it far enough into the process, just keeps
the manifest url in its permanent tables see
ApplicationCacheStorage::openDatabase in:
http://trac.webkit.org/browser/trunk/WebCore/loader/appcache/ApplicationCacheStorage.cpp

In Safari the tables are put somewhere under /private/var/...:

>   > sqlite3 ApplicationCache.db
>   > .tables
>   CacheAllowsAllNetworkRequests  CacheResources               
>   CacheEntries                   CacheWhitelistURLs           
>   CacheGroups                    Caches                       
>   CacheResourceData              FallbackURLs
>   > .schema CacheGroups
>   CREATE TABLE CacheGroups ( id INTEGER PRIMARY KEY AUTOINCREMENT
>                            , manifestHostHash INTEGER NOT NULL ON CONFLICT FAIL
>                            , manifestURL TEXT UNIQUE ON CONFLICT FAIL
>                            , newestCache INTEGER);


My Patch So Far:
----------------

The patches I put up so far tacked a quota onto the `CacheGroups`
table. This means that if the website used a different manifest
URL, its using a different ApplicationCacheGroup with a different
quota. So, a website would be able use multiple manifests to
work around the individual quota limit. And, as Alexey points out
they could use <iframe>s to make use of each cache group's resources
all on a single page (bypassing the supposed quota). Dirty, but
possible.


Per-Origin Quotas:
------------------

To avoid the above problem we can use per-origin quotas. Taking
an approach similar to Databases we can just add a "Origins"
table to match up origins and quotas. The table schema could even
be the same as the Databases schema above:

    CREATE TABLE Origins ( origin TEXT UNIQUE ON CONFLICT REPLACE
                         , quota INTEGER NOT NULL ON CONFLICT FAIL);

CacheGroups already have a manifest URL from which the origin can
be extracted. WebCore::SecurityOrigin handles this nicely.

The complexity is tracking the quota across multiple cache groups.
WebCore::OriginQuotaManager (currently ENABLE(STORAGE) in
WebCore/storage/OriginQuotaManager.{cpp,h}) and OriginQuotaRecord
does this for Databases. The same model looks like it could carry
over to Application Cache Groups and share some code.


My Conclusion:
--------------

Sounds like real per-origin is probably the best solution. Do you
you think I should take that approach and r- what I have here and
"do it right". Or continue with what I have here, and open up a new
bug to transfer it over to real per-origin?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.