Google Git
Sign in
chromium / chromium / src.git / 0daf72ec0ca1b77b1617843f33dd8300b8b7748d / . / content / browser / background_fetch / storage
tree: 071348a74d7312da06169d75b69fcd4bf171635c [path history] [tgz]
  1. cache_entry_handler_impl.cc
  2. cache_entry_handler_impl.h
  3. cleanup_task.cc
  4. cleanup_task.h
  5. create_metadata_task.cc
  6. create_metadata_task.h
  7. database_helpers.cc
  8. database_helpers.h
  9. database_task.cc
  10. database_task.h
  11. delete_registration_task.cc
  12. delete_registration_task.h
  13. get_developer_ids_task.cc
  14. get_developer_ids_task.h
  15. get_initialization_data_task.cc
  16. get_initialization_data_task.h
  17. get_metadata_task.cc
  18. get_metadata_task.h
  19. get_registration_task.cc
  20. get_registration_task.h
  21. image_helpers.cc
  22. image_helpers.h
  23. image_helpers_unittest.cc
  24. mark_registration_for_deletion_task.cc
  25. mark_registration_for_deletion_task.h
  26. mark_request_complete_task.cc
  27. mark_request_complete_task.h
  28. match_requests_task.cc
  29. match_requests_task.h
  30. README.md
  31. start_next_pending_request_task.cc
  32. start_next_pending_request_task.h
content/browser/background_fetch/storage/README.md

Background fetch state storage

content/browser/background_fetch/storage contains a set of tasks that read to and write from the service worker database, to store the state of the currently running background fetches.

DatabaseTask is the abstract base class that all other tasks extend.

Service Worker DB UserData schema

Design doc

  • Each key will be stored twice by the Service Worker DB, once as a “REG_HAS_USER_DATA:”, and once as a “REG_USER_DATA:” - see content/browser/service_worker/service_worker_database.cc for details.
  • Non-padded integer values are serialized as a string by base::Int*ToString().

Keys and values

key: "bgfetch_active_registration_unique_id_<developer_id>"
value: "<unique_id>"

key: "bgfetch_registration_<unique_id>"
value: "<serialized content::proto::BackgroundFetchMetadata>"

key: "bgfetch_ui_options_<unique_id>"
value: "<serialized content::proto::BackgroundFetchUIOptions>"

key: "bgfetch_pending_request_<unique_id>_<request_index>"
value: "<serialized content::proto::BackgroundFetchPendingRequest>"

key: "bgfetch_active_request_<unique_id>_<request_index>"
value: "<serialized content::proto::BackgroundFetchActiveRequest>"

key: "bgfetch_completed_request_<unique_id>_<request_index>"
value: "<serialized content::proto::BackgroundFetchCompletedRequest>"

Cache Storage UserData schema

The downloaded responses of every fetch will be stored in their own private cache.

Cache identifiers

  • origin: <origin>
  • owner: CacheStorageOwner::kBackgroundFetch
  • cache_name: <unique_id>

The cache will contain all the Request/Response key/value pairs of the fetch. Note that the Request value stored isn't comprehensive, and only the url value is used to as a key to find the matching Response.

Expansions

  • <unique_id> is a GUID (v4) that identifies a background fetch registration. E.g. 17467386-60b4-4c5b-b66c-aabf793fd39b
  • <developer_id> is a string provided by the developer to differentiate background fetches within a service worker. As such it may contain any characters and so it should be used very carefully within keys as it may introduce ambiguity.
  • <request_index> is an int containing the index of a request within a multi-part fetch. These must be padded with zeros to ensure that the ordering is maintain when reading back from the database, e.g. 0000000000.
  • <ui_title> is the notification title provided by the developer. It can also be updated by calling BackgroundFetchUpdateEvent.updateUI.