82291 2012-03-26 20:40:45 -0700 Pages containing "multipart/x-mixed-replace" resources should not be cached. 2012-03-28 19:57:44 -0700 1 1 1 Unclassified WebKit Page Loading 528+ (Nightly build) All All UNCONFIRMED P2 Normal --- 0 logingx webkit-unassigned ap beidson rwlbuis tonikitoo webkit.review.bot oldest_to_newest 588525 0 logingx 2012-03-26 20:40:45 -0700 If a page has multiparts with "multipart/x-mixed-replace", we should not cache it in pageCache. 588584 1 133981 logingx 2012-03-26 23:03:47 -0700 Created attachment 133981 Patch 588744 2 133981 rwlbuis 2012-03-27 04:19:56 -0700 Comment on attachment 133981 Patch LGTM. 588773 3 133981 webkit.review.bot 2012-03-27 04:55:22 -0700 Comment on attachment 133981 Patch Clearing flags on attachment: 133981 Committed r112252: <http://trac.webkit.org/changeset/112252> 588775 4 webkit.review.bot 2012-03-27 04:55:50 -0700 All reviewed patches have been landed. Closing bug. 589264 5 ap 2012-03-27 14:14:45 -0700 This patch has no explanation of why this is desirable, and no regression test. Is this something all platforms need, or something all other platforms already have? 589668 6 logingx 2012-03-27 22:56:42 -0700 (In reply to comment #5) > This patch has no explanation of why this is desirable, and no regression test. Is this something all platforms need, or something all other platforms already have? "multipart/x-mixed-replace" is HTTP server push. If we stored them in Page Cache, some images( most of cases) can not show up on back/forward. I also checked other platforms, QT does not support "multipart/x-mixed-replace", Chrome has own pageCache management, Mac has the issue with "multipart/x-mixed-replace" on back/forward. I have not a strong power to unify them:). So I would like take this as a specific platform issue to fix it so far. 590089 7 beidson 2012-03-28 10:18:32 -0700 (In reply to comment #6) > (In reply to comment #5) > > This patch has no explanation of why this is desirable, and no regression test. Is this something all platforms need, or something all other platforms already have? > > "multipart/x-mixed-replace" is HTTP server push. If we stored them in Page Cache, some images( most of cases) can not show up on back/forward. Not clear what you're trying to say here. I think what you're saying is that if we cache such a page, we'd stopAllLoaders therefore cutting off the stream to the image. Then when the page is restored the user would just see the most recent frame rendered before the loaders were stopped. Is that correct? >QT does not support "multipart/x-mixed-replace" But if they ever add support, they will have this bug. Correct? > Chrome has own pageCache management Currently they simply have no page cache. They're experimenting with enabling the WebCore page cache now and - when they do - they could presumably be affected. >Mac has the issue with "multipart/x-mixed-replace" on back/forward. The same issue as Blackberry? Therefore this fix should be applied to Mac also? > I have not a strong power to unify them:). There is nothing "blackberry specific" about this bug. This bug exists for "platforms that use the page cache that also support multipart/x-mixed-replace". That current includes Blackberry, Mac, and Windows. Chrome is experimenting with joining that club by enabling the page cache. If Qt ever supports multipart/x-mixed-replace they will also join that club. You don't have to make Chrome support the page cache or make Qt support multipart/x-mixed-replace to fix this bug. You just have to fix it cross-platform in a way they can benefit from in the future. Also - since this is a cross platform bug and is something that is testable in the layout tests - this patch should include a regression test. 590091 8 beidson 2012-03-28 10:19:22 -0700 Reopening because this is a cross platform bug. 590093 9 beidson 2012-03-28 10:19:41 -0700 (In reply to comment #8) > Reopening because this is a cross platform bug. ...that wasn't fixed properly. 590115 10 beidson 2012-03-28 10:38:22 -0700 To add a further point of clarification on the very premise of this bug: In general we should work to fix any exemption to the page cache on a case-by-case basis. Some of the reasons a page can't be cached are policy decisions: HTTPS with certain caching headers, for example. We have to maintain those exemptions to keep financial institutions happy, for example. But *many* reasons on the list of exemptions are *current* technical shortcomings that we should strive to solve. This "multipart/x-mixed-replace" issue is a technical one. Currently we have no acceptable solution for caching such a page then restoring it: Images would be frozen mid-frame, for example. But there are clever solutions we implement in the future. Replace the image with a paused frame that could be gracefully resumed automatically or by explicit user action to re-establish the network connection, for example. Once we get this bug resolved in a proper cross platform manner we need to make sure to have a bug tracking "Remove the multipart/x-mixed-replace exemption by gracefully allowing such resources in the page cache" 590122 11 beidson 2012-03-28 10:43:28 -0700 https://bugs.webkit.org/show_bug.cgi?id=47222 is quite relevant 590747 12 logingx 2012-03-28 19:08:15 -0700 (In reply to comment #10) > To add a further point of clarification on the very premise of this bug: > > In general we should work to fix any exemption to the page cache on a case-by-case basis. > > Some of the reasons a page can't be cached are policy decisions: HTTPS with certain caching headers, for example. We have to maintain those exemptions to keep financial institutions happy, for example. > > But *many* reasons on the list of exemptions are *current* technical shortcomings that we should strive to solve. > > This "multipart/x-mixed-replace" issue is a technical one. Currently we have no acceptable solution for caching such a page then restoring it: Images would be frozen mid-frame, for example. > > But there are clever solutions we implement in the future. Replace the image with a paused frame that could be gracefully resumed automatically or by explicit user action to re-establish the network connection, for example. > > Once we get this bug resolved in a proper cross platform manner we need to make sure to have a bug tracking "Remove the multipart/x-mixed-replace exemption by gracefully allowing such resources in the page cache" Thanks a lot. It is reasonable and I understood. 133981 2012-03-26 23:03:47 -0700 2012-03-27 04:55:22 -0700 Patch bug-82291-20120327140341.patch text/plain 2432 logingx U3VidmVyc2lvbiBSZXZpc2lvbjogMTEyMjA3CmRpZmYgLS1naXQgYS9Tb3VyY2UvV2ViS2l0L2Js YWNrYmVycnkvQ2hhbmdlTG9nIGIvU291cmNlL1dlYktpdC9ibGFja2JlcnJ5L0NoYW5nZUxvZwpp bmRleCAxOTdmYTJjZTZlNzQxNTNlMGJmMGZjOTE2MzMzN2U1OTdjYjhhYmE5Li5hNmYxMzA3MDg5 NDk3YTgxMTcwNmQyZTJhNWMyMGEzOTVjZmYxZmFkIDEwMDY0NAotLS0gYS9Tb3VyY2UvV2ViS2l0 L2JsYWNrYmVycnkvQ2hhbmdlTG9nCisrKyBiL1NvdXJjZS9XZWJLaXQvYmxhY2tiZXJyeS9DaGFu Z2VMb2cKQEAgLTEsMyArMSwxOCBAQAorMjAxMi0wMy0yNiAgQ2hyaXMgR3VhbiAgPGNocmlzLmd1 YW5AdG9yY2htb2JpbGUuY29tLmNuPgorCisgICAgICAgIEEgcGFnZSBjb250YWluaW5nIG11bHRp cGFydHMgd2l0aCAibXVsdGlwYXJ0L3gtbWl4ZWQtcmVwbGFjZSIgc2hvdWxkIG5vdCBiZSBjYWNo ZWQuCisgICAgICAgIGh0dHBzOi8vYnVncy53ZWJraXQub3JnL3Nob3dfYnVnLmNnaT9pZD04MjI5 MQorCisgICAgICAgIFJldmlld2VkIGJ5IE5PQk9EWSAoT09QUyEpLgorCisgICAgICAgIElmIHdl IGhhdmUgYSBtdWx0aVBhcnQgcmVwb25zZSB3aXRoIG11bHRpcGFydC94LW1peGVkLXJlcGxhY2Us IAorICAgICAgICB0aGUgY3VycmVudCBwYWdlIHNob3VsZCBub3QgYmUgY2FjaGVkLiBJIHVzZSBp c011bHRpcGFydFBheWxvYWQoKSAKKyAgICAgICAgQVBJIHdoaWNoIHdhcyBzdXBwb3NlZCB0byBi ZSBzZXQgaW4gTmV0d29ya0pvYiB0byBkZWNpZGUgdG8gCisgICAgICAgIGNhY2hlIHBhZ2Ugb3Ig bm90LgorCisgICAgICAgICogV2ViQ29yZVN1cHBvcnQvRnJhbWVMb2FkZXJDbGllbnRCbGFja0Jl cnJ5LmNwcDoKKyAgICAgICAgKFdlYkNvcmU6OkZyYW1lTG9hZGVyQ2xpZW50QmxhY2tCZXJyeTo6 Y2FuQ2FjaGVQYWdlKToKKwogMjAxMi0wMy0yNSAgQXJ2aWQgTmlsc3NvbiAgPGFuaWxzc29uQHJp bS5jb20+CiAKICAgICAgICAgW0JsYWNrQmVycnldIEFjY2VsZXJhdGVkIGNvbXBvc2l0aW5nIGxh eWVycyBmYWlsIHRvIHJlbmRlciB3aGVuIHVzaW5nIFdlYlBhZ2VDb21wb3NpdG9yCmRpZmYgLS1n aXQgYS9Tb3VyY2UvV2ViS2l0L2JsYWNrYmVycnkvV2ViQ29yZVN1cHBvcnQvRnJhbWVMb2FkZXJD bGllbnRCbGFja0JlcnJ5LmNwcCBiL1NvdXJjZS9XZWJLaXQvYmxhY2tiZXJyeS9XZWJDb3JlU3Vw cG9ydC9GcmFtZUxvYWRlckNsaWVudEJsYWNrQmVycnkuY3BwCmluZGV4IDEwZjgyMDgxZGUxOTg3 YTQ2M2VhNmMwZGFiY2RkMDdhZDA0ODNiY2IuLjY0NWY5NTE1YzkxMTcxMjYyYjM2YjZiNzBhMzZj OTU4NWMzZjRmZTcgMTAwNjQ0Ci0tLSBhL1NvdXJjZS9XZWJLaXQvYmxhY2tiZXJyeS9XZWJDb3Jl U3VwcG9ydC9GcmFtZUxvYWRlckNsaWVudEJsYWNrQmVycnkuY3BwCisrKyBiL1NvdXJjZS9XZWJL aXQvYmxhY2tiZXJyeS9XZWJDb3JlU3VwcG9ydC9GcmFtZUxvYWRlckNsaWVudEJsYWNrQmVycnku Y3BwCkBAIC0xMTg4LDcgKzExODgsNyBAQCB2b2lkIEZyYW1lTG9hZGVyQ2xpZW50QmxhY2tCZXJy eTo6ZGlzcGF0Y2hEaWRSZWNlaXZlSWNvbigpCiAKIGJvb2wgRnJhbWVMb2FkZXJDbGllbnRCbGFj a0JlcnJ5OjpjYW5DYWNoZVBhZ2UoKSBjb25zdAogewotICAgIC8vIFdlIHdvbid0IGNhY2hlIHBh Z2VzIGNvbnRhaW5pbmcgdmlkZW8gb3IgYXVkaW8uCisgICAgLy8gV2Ugd29uJ3QgY2FjaGUgcGFn ZXMgY29udGFpbmluZyB2aWRlbywgYXVkaW8gb3IgbXVsdGlwYXJ0IHdpdGggIm11bHRpcGFydC94 LW1peGVkLXJlcGxhY2UiLgogICAgIEFTU0VSVChtX2ZyYW1lLT5kb2N1bWVudCgpKTsKICAgICBS ZWZQdHI8Tm9kZUxpc3Q+IG5vZGVMaXN0ID0gbV9mcmFtZS0+ZG9jdW1lbnQoKS0+Z2V0RWxlbWVu dHNCeVRhZ05hbWUoSFRNTE5hbWVzOjp2aWRlb1RhZy5sb2NhbE5hbWUoKSk7CiAgICAgaWYgKG5v ZGVMaXN0LmdldCgpLT5sZW5ndGgoKSA+IDApCkBAIC0xMTk3LDYgKzExOTcsMTMgQEAgYm9vbCBG cmFtZUxvYWRlckNsaWVudEJsYWNrQmVycnk6OmNhbkNhY2hlUGFnZSgpIGNvbnN0CiAgICAgaWYg KG5vZGVMaXN0LmdldCgpLT5sZW5ndGgoKSA+IDApCiAgICAgICAgIHJldHVybiBmYWxzZTsKIAor ICAgIEFTU0VSVChtX2ZyYW1lLT5sb2FkZXIoKS0+ZG9jdW1lbnRMb2FkZXIoKSk7CisgICAgY29u c3QgUmVzcG9uc2VWZWN0b3ImIHJlc3BvbnNlcyA9IG1fZnJhbWUtPmxvYWRlcigpLT5kb2N1bWVu dExvYWRlcigpLT5yZXNwb25zZXMoKTsKKyAgICBzaXplX3QgY291bnQgPSByZXNwb25zZXMuc2l6 ZSgpOworICAgIGZvciAoc2l6ZV90IGkgPSAwOyBpIDwgY291bnQ7IGkrKykgeworICAgICAgICBp ZiAocmVzcG9uc2VzW2ldLmlzTXVsdGlwYXJ0UGF5bG9hZCgpKQorICAgICAgICAgICAgcmV0dXJu IGZhbHNlOworICAgIH0KICAgICByZXR1cm4gdHJ1ZTsKIH0KIAo=