Closed
Bug 1017636
Opened 10 years ago
Closed 10 years ago
Pages not loading completely requiring a force-refresh
Categories
(Core :: Networking: Cache, defect)
Core
Networking: Cache
Tracking
()
RESOLVED
FIXED
mozilla32
People
(Reporter: RyanVM, Assigned: mayhemer)
References
Details
(Keywords: regression, Whiteboard: [qa-] )
Attachments
(1 file)
(deleted),
patch
|
mcmanus
:
review+
Sylvestre
:
approval-mozilla-aurora+
mayhemer
:
checkin+
|
Details | Diff | Splinter Review |
Since I updated my local build to m-c tip this morning, I've had many instances of pages not loading or loading incompletely. Only a force-refresh has worked.
I wasn't experiencing this problem with an m-c tip build from yesterday's round of merges performed by myself. Looking at what has landed on m-c since, bug 1014394 seems the most likely candidate. I'll backout locally to try and confirm.
Assignee | ||
Comment 1•10 years ago
|
||
Hmm.. something our infra would not catch? Weird. Any URLs or just "anything"? Going to try my self. Thanks for the report.
(In reply to Honza Bambas (:mayhemer) from comment #1)
> Hmm.. something our infra would not catch? Weird. Any URLs or just
> "anything"? Going to try my self. Thanks for the report.
bugzilla.mozilla.org bug pages and addons.mozilla.org definitely affected.
To reproduce, you'll likely need to use yesterday's nightly to first load those sites. Next, update to today's nightly then revisit those pages.
After a forced reload (i.e. ctrl + F5) the specific page seems to no longer exhibits the issue. This is, of course, a problem if you have a lot of affected visited pages.
Assignee | ||
Comment 3•10 years ago
|
||
OK, got it, this is actually regression from bug 995801. Not related to 1014394 at all. Anyway, it just uncovers bug in cache2 code, or actually http channel code that badly handles the missing sec info.
Going to provide a patch.
Assignee | ||
Comment 4•10 years ago
|
||
Patrick, please one quick review on this simple and urgent patch. Thanks.
The problem was that when we failed to open the cache entry's sec info, not all conditional headers were removed. So, the channel rejected correctly the entry but left the "If-None-Match" request header. It was then getting 304 but provided no content (304 empty body actually), since there were (correctly) no cache entry to read from.
Attachment #8430931 -
Flags: review?(mcmanus)
Reporter | ||
Updated•10 years ago
|
Flags: in-testsuite?
Updated•10 years ago
|
Attachment #8430931 -
Flags: review?(mcmanus) → review+
Updated•10 years ago
|
Assignee | ||
Comment 5•10 years ago
|
||
Comment on attachment 8430931 [details] [diff] [review]
v1
https://hg.mozilla.org/integration/mozilla-inbound/rev/ea48287c48a7
Thanks, Patrick!
Attachment #8430931 -
Flags: checkin+
Reporter | ||
Comment 6•10 years ago
|
||
I cherry-picked this to m-c so we could get a nightly respin.
https://hg.mozilla.org/mozilla-central/rev/b85b57f05fda
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
status-firefox32:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Comment on attachment 8430931 [details] [diff] [review]
v1
[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 995801 uncovered it
User impact if declined: Needed to uplift the patch in bug 995801
Testing completed (on m-c, etc.): landed last week on m-c
Risk to taking this patch (and alternatives if risky): low, as I understand it
String or IDL/UUID changes made by this patch: none
Attachment #8430931 -
Flags: approval-mozilla-aurora?
Updated•10 years ago
|
status-firefox31:
--- → affected
Updated•10 years ago
|
Attachment #8430931 -
Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Reporter | ||
Comment 10•10 years ago
|
||
Whiteboard: [qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•