Pages containing "multipart/x-mixed-replace" resources should not be cached.

• Component: Page Loading
• Status: UNCONFIRMED ---

[Chris.Guan]

If a page has multiparts with "multipart/x-mixed-replace", we should not cache it in pageCache.

[Chris.Guan]

Created attachment 133981 [details]
Patch

[Rob Buis]

Comment on attachment 133981 [details]
Patch

LGTM.

[WebKit Review Bot]

Comment on attachment 133981 [details]
Patch

Clearing flags on attachment: 133981

Committed r112252: <http://trac.webkit.org/changeset/112252>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.

[Alexey Proskuryakov]

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?

[Chris.Guan]

(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.

[Brady Eidson]

(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.

[Brady Eidson]

Reopening because this is a cross platform bug.

[Brady Eidson]

(In reply to comment #8)
> Reopening because this is a cross platform bug.

...that wasn't fixed properly.

[Brady Eidson]

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"

[Brady Eidson]

https://bugs.webkit.org/show_bug.cgi?id=47222 is quite relevant

[Chris.Guan]

(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.