Thinking about it, caching the 302 response per se may be correct under the conditions where the image itself should be cached.

Anyway, keeping it in the cache even when clearing the cache is obviously a bug, and a really huge one. I don't understand why it's so difficult to just delete EVERY FUCKING THING when clearing the cache (there had already been other issues such as favicons not being deleted from cache).

This could be coming from some other prediction service other than the cache. Try disabling the "use a prediction service to load pages more quickly" privacy setting. Does it still happen?

If it still happens, can you gather a net-log of it happening and attach it to this bug? See https://dev.chromium.org/for-testers/providing-network-details for how to collect a net-log trace. Thanks!

> This could be coming from some other prediction service other than the cache. 
> Try disabling the "use a prediction service to load pages more quickly"
> privacy setting.

Even if that was the case, clearing the cache should clear that too.

I'm trying to figure out where the data is being stored so that we can address it.

I see.
Have you already tried to reproduce it yourself? 

I'm unable to reproduce. I tried on http://cr.kungfoo.net/jkarlin/redirect/. If I clear the cache and navigate to http://cr.kungfoo.net/jkarlin/redirect/ again then the 302 page is not served from cache.

Can you try the suggestions from comment #3 to help us debug the problem?

Thank you for providing more feedback. Adding requester "jkarlin@chromium.org" for another review and adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Still waiting on a repsonse to comment #3.

I don't see the 302 being cached at all, only the final page in my example.   teo8976, can you provide an example page where this issue occurs?

> only the final page in my example

You say "page", that makes me wonder: did you test with an IMAGE, as per the original report? This is about images.

Please be polite. We're only trying to help.

The caching behavior will be the same if it's image or document, though I have added an image example (http://cr.kungfoo.net/jkarlin/redirect/image.html) as well. 

I've adjusted the response cache headers and I do now cache the 302 response. After clearing browsing data the redirect isn't served from cache. So I'm still unable to reproduce the issue. 

Please provide an example site where you're seeing this issue or provide a net-log as requested in comment 3.

I can reproduce it from your very example by opening the image directly (as per the instructions in the original report):
http://cr.kungfoo.net/jkarlin/redirect/image_redirect.php

See the screenshot. The red line is where I cleared the cache.

I do not indeed reproduce it when visiting your html page.


> Please be polite. We're only trying to help.

(I don't think I have been unpolite, anyway) So am I when reporting the bug in the first place, and when providing additional information. You are welcome to ask for additional information; however it's fundamentally wrong to put a bug in the Needs-Feedback status when (A) you are asking for additional information that you can get by testing yourself (it's still ok to ask the OP, they might just be able to provide it more quickly) as in comment 3, or before you have actually followed the "steps to reproduce" as in comments before 14.

Deleted: Untitled.png 41.1 KB

	Untitled.png 41.1 KB View Download

The issue does seem disappear if I disable "Use a prediction service to load data more quickly"

Here is what I'm doing.

1. Navigate to http://cr.kungfoo.net/jkarlin/redirect/image_redirect.php
2. Navigate to http://cr.kungfoo.net/jkarlin/redirect/image_redirect.php again to verify that it loads from cache
3. Clear browser cache
4. Navigate to http://cr.kungfoo.net/jkarlin/redirect/image_redirect.php

The image_redirect.php file is *not* served from cache for me. After clearing your cache, is http://cr.kungfoo.net/jkarlin/redirect/image_redirect.php still in your chrome://cache listing? If so, are you sure you have "cached images and files" checked when clearing your browsing history?

Do you have "Use a prediction service to load data more quickly" checked?

> are you sure you have "cached images and files" checked when clearing
> your browsing history?

Yep

#16, interesting. I do have the option checked as well.

Did you verify after clearing your cache that the resource is not in chrome://cache?

> Did you verify after clearing your cache that the resource is not 
> in chrome://cache?

Yep, it is not.

cc'ing some predictive folks

If it's not in the cache, then my best guess is that some predictive service is fetching the resource ahead of time. Can you start typing the url and, before hitting enter, open a new tab and check your chrome://cache to see if it was inserted? 

could it be because of blink memory cache?

re #20: please try to repro in these two modes:

1. after clearing the cache, before loading the image_redirect.php, open a new tab, and only then load the image_redirect.php in the new tab

2. uncheck the checkboxes in about:settings whose name start with "Use a prediction service to"

Note that we do delete blink memory cache when the user chooses to delete cache in chrome://settings/clearBrowserData

Here: https://cs.chromium.org/chromium/src/chrome/browser/browsing_data/browsing_data_remover_impl.cc?q=BrowsingDataRemoverImpl&sq=package:chromium&dr=CSs&l=499

teo8976@, any updates for comment 22?

Thank you for providing more feedback. Adding "Needs-Review" label for tracking.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Cleaning up "Needs-Review" label as we are not using this label for triage. Ref  bug 684919 

Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I had trouble recreating this issue and began to believe it mite have been
my own configuration mistake not a bug, apologies.


Tom Atkinson - Director
The Tomachi Corporation
M: 021 257 6422 <+64212576422> | Web: tomachi.co
<http://tomachi.co/?utm_source=TomsEmailSignature&utm_medium=email&utm_campaign=TomsEmailSignature>
<http://tomachi.co/?utm_source=TomsEmailSignature&utm_medium=email&utm_campaign=TomsEmailSignature>

<http://www.funk.co.nz/?utm_source=TomsEmailSignature&utm_medium=email&utm_campaign=TomsEmailSignature>

____________________________________
____________________________________
Subscribe
<http://www.funk.co.nz/amu/?utm_source=TomsEmailSignature&utm_medium=email&utm_campaign=TomsEmailSignature>
to
Auckland Music Update
Bands: tomachi.tv | triptonites.com
<http://www.triptonites.com/?utm_source=TomsEmailSignature&utm_medium=email&utm_campaign=TomsEmailSignature>
<http://www.facebook.com/tomachinz>  <https://twitter.com/tomachi>
<http://www.youtube.com/playlist?list=PL4C4799FDA135D2FE>
<http://soundcloud.com/tomachi>  <http://tomachi.tv/>

For f***'s sake, will you ever stop this nonsense policy of automatically closing issues "because" they don't get fixed?? It's ridiculous. If anything, an issue that is still open and hasn't been touched for a year should get a boost in priority.

I have just checked that I still observe the issue if I enable the setting "use a prediction service to load pages more quickly".

The steps in comment 17 systematically reproduce the issue (as long as the abovementioned setting is enabled; they don't if it isn't).

I understand not everybody is able to reproduce it, and I may have failed to reply to some requests for additional information, but none of these is a reason for closing an issue that is not fixed, especially one that has quite disastrous consequences.

Actually yeah now I remember the cause! It IS a cached redirect. It was coming from my application layer. Either WordPress or a hand-rolled one from my NODEJS app. Also... one of them mayb have bee a cached re: https://en.wikipedia.org/wiki/HTTP/1.1_Upgrade_header 

Assigning to pasko@ as this appears to be related to prediction service.

sorry, was out this week ..

It is WAI for prediction service to feed the cache when the omnibox is touched and in a few other circumstances (see: http://goo.gl/EJjTCM and https://goo.gl/iZcovf). When clearing _history_ the predictor state is cleared as well (you can check with about:predictors). However, when clearing cache, the predictor state is not cleared, making it possible for prefetch to kick in (after >=2 hits, though I could not repro - dunno why).

teo8...: please confirm that clearing the history works as intended for you.

I see how this behavior may be non-intuitive. Among realistic ways to make it less confusing I see:
1. additionally clear the predictor state when cache is cleared (same for cookies?)
2. clarify the cache confusion in the privacy whitepaper

I think (1) will be less confusing and won't hurt the predictor performance much, no immediate drawbacks I can see.

msramek: WDYT? Should we also update the privacy whitepaper if we take (1)?

> teo8...: please confirm that clearing the history works as intended for you.

LOL I'm not going to lose my history for a test. 

> However, when clearing cache, the predictor state is not cleared

Well, that's just wrong. When I clear the cache, I expect every f***ing cached thing to be deleted, unless you provide me with a separate option to clear prediction services cache specifically (and one for every other kind of cache that you have), which doesn't exist, or a broader option which also doesn't exist, to clear "all kinds of cache" (as opposed to what you arbitrarily consider "the" cache). 

It is NOT acceptable to be forced to clear browsing history in order to clear some kind of cache. History has nothing to do with caching.

> LOL I'm not going to lose my history for a test.

There are other ways to test:
1. copy your user data directory and test with --user-data-dir
2. delete history only for the past hour (the URL has to be entered in the omnibox during this hour)

> Well, that's just wrong. When I clear the cache, I expect every f***ing cached thing to be deleted

The cache *is* deleted in this case, but when you touch the omnibox the predictor fetches the content again and puts it to disk cache without showing it to you in devtools.

Interestingly you expect every cached thing to be deleted, but the history to remain. Is it because history is not a cache? The predictor service state is not a cache either, this state aggregated by observing the way the the omnibox is used, which does not directly map to cache entries.

> The cache *is* deleted in this case, but when you touch the omnibox the 
> predictor fetches the content again and puts it to disk 
> cache without showing it to you in devtools.

OMG, really?
Then what is clearly wrong is that the requests made by the predictor when typing in the omnibox are not shown in devtools!! Why on earth shouldn't they? If not by default, at least there should be an option such as "show requests made by prediction service", or "show all requests" (including all those that you are hiding for whatever reason)

I expect the devtools to show me EVERY request that is made. Otherwise, debugging is a nightmare as in this case.


By the way, are you absolutely sure that the cached REDIRECT response is also cleared? That is, the redirect served from cache that I see at step 4 in comment 17, is a response that has just been obtained and cached while I was typing in the omnibox, and not the one that had been cached at step 1?

I wish I could check that myself by looking at the devtools.

> Interestingly you expect every cached thing to be deleted, 
> but the history to remain

Of course. The history is not a cached copy of come contents. It's (meta)information on its own. An entry in the history is the fact that on day X at time Y I visited the url Z. Deleting the cached copy of the contents that I got from that url has nothing to do with deleting the information that on that date I visited that URL. I do one or the other for different purposes.

> of come contents

*some

> [...] requests made by the predictor when typing in the omnibox are not shown in devtools!! Why on earth shouldn't they?

Since the requests are initiated outside of the context of the currently open devtools, it is a little difficult to find which instances to attach this request to. Other things the browser initiates (like preconnect or DNS-prefetch) have similar complications and are not showing up in devtools. I guess it will never be a priority to display all these browser smarts 100% correctly in devtools. +pfeldman for authority.

> By the way, are you absolutely sure that the cached REDIRECT response is also cleared?

Yes. Redirects are normal cache entries, when they are cacheable.

WTF??

Why WontFix??

You explained that "it is a little difficult" and that "it will never be a priority to display all these browser smarts 100% correctly" but neither of these are good reasons for giving up fixing this.

I think we should disable NoStatePrefetch when DevTools is open for a tab. This is what we do for prerender, and it avoids surprises when someone is debugging their server and sees some extra requests out of nowhere. Can we do that?

Thanks dgozman!

Oh, indeed we could disable all of NoStatePrefetch when at least a single DevTools tab is open.

We still start prerenders (and affect HTTP cache) when DevTools is open for the tab, we just disallow swapping the prerendered WebContents into the tab (in PrerenderManager::SwapInternal). Here we probably want to prevent NoStatePrefetch from _starting_. Is there a chrome/ way to detect DevTools being open for a Profile?

I'd prefer to do it per-WebContents if possible. Here is the method: https://cs.chromium.org/chromium/src/content/public/browser/devtools_agent_host.h?rcl=d30e0da337828d7cc438181b6d92ce73766d0692&l=87

Prerender/NoStatePrefetch is not attached to any initial WebContents. Omnibox prefetches, in particular, are launched from parts of Omnibox code that know nothing about the current tab/webcontents. In other words, I am not sure plumbing tab into something like OmniboxEditModel would be a good idea.

Even if we manage to discard prefetches from Omnibox drawn on top of the current tab-with-devtools, users would still be confused if they touched Omnibox in another window (though it's not that common I am guessing).

Since nostate-prefetch is chrome/-initiated and affects HTTP disk cache, I think the best discarding would be based on state associated with browser+profile.

I see, this makes sense. There is no easy way to find out whether DevTools is there for a profile. For a browser instance, I guess iterating over tabs and using the method above is the easiest way. Does that work?

That sounds undesirably O(number of tabs), but I guess workable. Adjusting status.

> 302 redirect should never be cached in the first place. Only 301 redirects should be cached.

Chromium is the odd one out here, All other browsers follow 302 redirects properly, Chromium strips get parameters from the redirect and breaks the "redirect from handler" design pattern.