Closed Bug 1119406 Opened 6 years ago Closed 6 years ago

Using empty HTTP cache entries to satisfy requests

Categories

(Core :: Networking: Cache, defect)

defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla38

People

(Reporter: mayhemer, Assigned: michal)

Details

Attachments

(1 file)

See bug 1000338 comment 35.

Leaving this as unconfirmed so far, since I'm not 100% sure this is truly a cache bug.

However, it might happen we have no-data/no-metadata entry that falls through the check logic and ends up as a blank page being rendered.

Michal, do you think this is possible?  According the reports it seems like it is, we may use an empty entry.  Question is, how does it happen to be persisted and how does it happen to be loaded back from disk?
I can reproduce it, I'll have a look at it.
QA Contact: michal.novotny
Assignee: nobody → michal.novotny
QA Contact: michal.novotny
Attached patch patch v1Splinter Review
I can reproduce the problem only partially. I can see empty entries but they are in fact partial entries and the content is served correctly. They are created as follows:

1) HTTP channel downloads some resource, writing to the cache entry fails for some reason (e.g. due to bug 1120945), so the cache entry is doomed, but the downloaded data is cached on some other layer (e.g. imgcache).

2) The same resource is downloaded again and the new cache entry is created.

3) The content is served from the other cache (imgcache in our case) and the HTTP channel is canceled with NS_ERROR_PARSED_DATA_CACHED before we write any data to the cache entry.

4) The channel is resumable, so the entry is not doomed in nsHttpChannel::CloseCacheEntry().

5) The cache entry is closed and an empty entry with valid metadata is written to disk.


There is a bug that we don't doom the entry when writing metadata fails (this patch fixes it). In this case we end up with the cache entry that has no file on the disk but the entry exists in CacheStorageService's hashtable. But this isn't a big issue since we keep the metadata in memory, so this entry is also correctly handled as a partial entry.
Attachment #8549905 - Flags: review?(honzab.moz)
Comment on attachment 8549905 [details] [diff] [review]
patch v1

Review of attachment 8549905 [details] [diff] [review]:
-----------------------------------------------------------------

OK, but how could this cause HTML pages not render?  I don't think there is a cache above the channel.

Could the symptoms be somehow caused by bug 1117763 and this bug in hand?

Anyway, let's land and watch what happens.
Attachment #8549905 - Flags: review?(honzab.moz) → review+
https://hg.mozilla.org/mozilla-central/rev/e85214458163
Status: UNCONFIRMED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.