Obsolete
Status Update
Comments
la...@gmail.com <la...@gmail.com> #3
There is no info, how to enable caching in Chrome over https. I used all mentioned headers without success. It's great, that some heuristics is used for caching decision, but it's obviously not working.
Silverlight application (.xap) or other static resources (e.g. images) can be significantly big and download of all resources after each page refresh makes it unuseable.
Silverlight application (.xap) or other static resources (e.g. images) can be significantly big and download of all resources after each page refresh makes it unuseable.
ke...@google.com <ke...@google.com> #4
[Empty comment from Monorail migration]
rv...@chromium.org <rv...@chromium.org> #5
Do you mind following http://www.chromium.org/for-testers/providing-network-details and posting the result here?
In particular, there should be a first request that caches a resource that was not previously cached, followed by the simple refresh.
In particular, there should be a first request that caches a resource that was not previously cached, followed by the simple refresh.
la...@gmail.com <la...@gmail.com> #6
There is initial load of the page and two refreshes - only in case of .js file are used If-Modified-Since & If-None-Match headers in second and third request, other files are downloaded each time.
rv...@chromium.org <rv...@chromium.org> #7
In fact nothing is being cached (on the persistent cache)... are you using a self-signed certificate and going through the interstitial? Any kind of SSL error will prevent us from caching anything from that site.
la...@gmail.com <la...@gmail.com> #8
Great, that's it! So, now the problem is much less serious.
But it is still strange behaviour, e.g. for small business is internal usage of self-signed certificates common practice, not to mention troubles in development.
+ It's different from other browsers
+ It's unpredictable - I have no idea why/how (in)validity of certificate can affect cache behaviour?
But it is still strange behaviour, e.g. for small business is internal usage of self-signed certificates common practice, not to mention troubles in development.
+ It's different from other browsers
+ It's unpredictable - I have no idea why/how (in)validity of certificate can affect cache behaviour?
rv...@chromium.org <rv...@chromium.org> #9
The rule is actually quite simple: any error with the certificate means the page will not be cached.
Seehttps://crbug.com/chromium/110649#c8 on https://crbug.com/chromium/103875 for more context.
See
bu...@chromium.org <bu...@chromium.org> #10
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
bu...@chromium.org <bu...@chromium.org> #11
[Empty comment from Monorail migration]
is...@google.com <is...@google.com> #12
This issue was migrated from crbug.com/chromium/110649?no_tracker_redirect=1
[Multiple monorail components: Internals, Internals>Network>Cache]
[Monorail components added to Component Tags custom field.]
[Multiple monorail components: Internals, Internals>Network>Cache]
[Monorail components added to Component Tags custom field.]
Description
Chrome Version : 16.0.912.75
OS Version : 6.1 (Windows 7, Windows Server 2008 R2)
Other browsers tested :
Safari 5: Not tested
Firefox 4.x: OK
IE 7/8/9: OK
What steps will reproduce the problem?
Cache-Control: max-age=31536000, public, must-revalidate, proxy-revalidate
Pragma: public
Expires: <current datetime + 1 year>
ETag: 123456789
Last-Modified: <current datetime>
What is the expected result?
After refresh of the webpage "If-None-Match" or rather "If-Modified-Since" headers should be present in the GET requests. OR if max-age/Expires should cause hard caching, but it is not necessary ant it is not the point of my report.
What happens instead?
No request 'caching' headers in GET requests and all files*), especially big .xap file, are downloaded from the server again and again with each next refresh.
*) except .js which is sometimes! cached