Closed
Bug 373824
Opened 18 years ago
Closed 3 years ago
in-progress uncacheable object is cached anyway and blocks other threads
Categories
(Core :: Networking: Cache, defect, P3)
Tracking
()
RESOLVED
INCOMPLETE
People
(Reporter: quartz12h, Unassigned)
Details
(Whiteboard: [necko-backlog])
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre) Gecko/20070111 SeaMonkey/1.1
I deliver a text/plain dynamic content over https with (or without, makes no difference) response headers
Cache-Control: no-cache
Pragma: no-cache
Expires: Thu, 01 Jan 1970 00:00:00 GMT
The thing is, this resource is a stream of text that never ends.
When a 2nd browser tab is opened and hits the same url, it doesn't get the text data stream.
However the 2nd browser tab start as expected as soon as I clear the cache.
As you can guess, this is not happenning in IE (stupider or smarter? who knows...). This doesn't happen either in seamonkey/mozilla/firefox if I serve the dynamic text data over plain http instead of https.
I suspect the URL entry is put in the cache, but the object is pending, so the other threads are waiting for the object to arrive. This is smart. Perhaps not smart enough... The object http response is already in, and declares "no-cache", so how come the 2nd or other threads are waiting for an object that will explicitly not be left in the cache upon completion?
Reproducible: Always
Steps to Reproduce:
1.serve a never-ending text/plain content over https, with all the no-cache headers and expires in 1970. (likely, a servlet, or a very slow server or cgi-bin, whatever).
2.open that url in a 1st tab, observe some response lines of text
3.open a 2nd tab on same url
Actual Results:
You won't get any content in 2nd tab.
Clear the cache and the 2nd tab start to download.
Expected Results:
The 2nd tab should get live uncached content immediately.
The 1st thread should have known better than putting an uncacheable object in the cache, no matter if the object is completed or not.
Updated•18 years ago
|
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking
Version: unspecified → 1.8 Branch
using firefox 1.5.0.10, mozilla 1.7.12, seamonkey 1.1
Component: Networking → General
Product: Core → Firefox
Version: 1.8 Branch → 1.5.0.x Branch
mistakenly changed the cathegories, back to core/networking/1.8
Component: General → Networking: Cache
Product: Firefox → Core
Version: 1.5.0.x Branch → 1.8 Branch
Correction: it does happen on both http and https. I was fooled by a redirect with a unique uri query param.
So, connection threads are queued for the same object but disregard the response headers already arrived that says this object cannot be cached.
The response handling should remove the object URI from the cache as soon as it detects it cannot be cached.
Comment 4•18 years ago
|
||
everything is cached, some things only in memory cache. that's required for view source and such to work correctly.
Sure, but that layer is a content viewer that doesn't require waiting for uncompleted objects. This layer is opportunistic in a sense. If the object is completed, you can view it sure.
But here, the networking layer is trying to implement caching smartly to avoid hitting the to often, like one would expect from any decent browser. Except that the engine isn't reacting swifly to the response headers and leaves concurrent requests dangling and waiting, queue until the unusable content of the first connection is completed.
The symptom appears clearly with tabbed browsing on similar resources. A good example is flash or applet getting a live stream of data (news, ads, etc...)
From the seamonkey 1.1 source tar ball, nsHttpChannel.cpp line 6140
// If the data in the cache hasn't expired, then there's no need to
// talk with the server, not even to do an if-modified-since. This
// method creates a stream from the cache, synthesizing all the various
// channel-related events.
nsresult
nsHttpChannel::ReadFromCache()
[.....]
There is a test to skip the cache and download if instructed to do so.
This seem to be the spot to update to check the response headers for no-cache
mCachedResponseHead->NoCache()
Comment 7•18 years ago
|
||
no, this code doesn't have cached response headers (or even a cache entry) until the first load finished writing to the entry.
I guess it would require a less trivial refactoring to have a 3-states progress (headers in progress, content in progress, completed) instead of just 2 (partial/not-partial)
I hope the listeners pattern there could be updated without too much disruption.
I believe it is worth it, not only for quicker detection of cache-miss and so faster content download (since parallelized instead of serialized queries), but also to set cookies early.
Updated•15 years ago
|
QA Contact: networking → networking.cache
Updated•9 years ago
|
Whiteboard: [necko-backlog]
Comment 9•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Comment 10•7 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Comment 11•3 years ago
|
||
Marking this as Resolved > Incomplete since the real last activity on this issue was 6 years ago and it might not be relevant anymore. Feel free to re-open if the issue is still reproducible on your end in the latest FF versions.
Status: UNCONFIRMED → RESOLVED
Closed: 3 years ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•