| Summary: | Remove runtime setting for enabling/disabling the Cache API? | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Sam Weinig <sam> |
| Component: | WebCore Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | koivisto, webkit-bug-importer, webkit-unassigned |
| Priority: | P2 | Keywords: | InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | |||
| Bug Blocks: | 216512 | ||
|
Description
Sam Weinig
2020-09-15 09:25:28 PDT
Looking at the implementation, it looks like this feature was never implemented for WebKitLegacy and seems to be intertwined with the network disk cache in WebKit2. Antti, Chris, can you remind me why the disk cache logic was put into WebKit2? Is it something we could bring into WebCore at some point and use for both WebKitLegacy and WebKit2? It was easier to make it WK2 only. It is not clear that risking breaking legacy clients by changing cache behavior is even desirable. The feature was introduced for WK2 clients with linked-on-or-after check. We have plenty of other APIs that are not supported in WK1, right? (In reply to Antti Koivisto from comment #2) > It was easier to make it WK2 only. It is not clear that risking breaking > legacy clients by changing cache behavior is even desirable. The feature was > introduced for WK2 clients with linked-on-or-after check. > > We have plenty of other APIs that are not supported in WK1, right? I don't know. We certainly don't have it well documented what works in WebKit1 vs. WebKit2, which seems lie a pretty big potential footgun waiting to happen. |