From:  Honza Bambas <>
Date:  08 Jan 2016 00:53:49 Hong Kong Time

Re: devtools re-fetching problem


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)


> Michal
> _______________________________________________
> dev-tech-network mailing list