Re: devtools re-fetching problem
Honza Bambas <[email protected]> Thu, 7 Jan 2016 17:53:49 +0100
| Newsgroups | gmane.comp.mozilla.devel.netlib |
|---|---|
| Message-ID | <[email protected]> |
On 1/7/2016 15:50, Michal Novotny wrote: > On 12/20/2015 12:36 AM, Jason Duell wrote: >>> We can't cache the resources if the web server tells us "don't cache >>> this", so even if we use things such as LOAD_ONLY_FROM_CACHE, we >>> still need >>> a solution for that case. >>>> > > I might be wrong, but I think we cache resources whenever possible. > no-store entries are kept in memory and no-cache entries are never > reused, no-cache entries are used and very often. no-cache means to revalidate (do a conditional request) if possible (having LM/Etag). > but we have them for viewsource etc... > > >>> How about forcing Gecko retain the original source text when >>> devtools are >>> being used? >> >> Sounds like we need something like a CACHE_GECKO_COPY flag that keeps a >> "secret" cache only for internal gecko use? >> >> 1) if the resource would normally be cached, does nothing (the resource >> gets cached normally) >> 2) If the resource wouldn't be cached, cache it (perhaps only in >> RAM? Or >> maybe we'd need that only if INHIBIT_PERSISTENT_CACHING is set), with >> some >> sort of flag that indicates it should be invisible to cache reads unless >> CACHE_HIDDEN_COPY is again present. > > How does this differ from what we already do as described above? > > Btw, I think it's really hard to solve this on the cache level. Let's > say there is some no-cache, no-store resource which is different on > every load. We load it in 2 tabs so every tab has a different version. A deferred cache storage would keep a storage per-tab (ideally). So, no, it would be separated between tabs. > We would need to keep multiple different copies that we received from > the server. And how would devtools identify which one it wants? As said above, docshell or chrome window would be the ident (holder of the deferred cache storage) -hb- > > Michal > > _______________________________________________ > dev-tech-network mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-tech-network >