Closed
Bug 299031
Opened 19 years ago
Closed 8 years ago
Necko does not honor HTTP 410 Gone
Categories
(Core :: Networking: Cache, defect)
Core
Networking: Cache
Tracking
()
RESOLVED
FIXED
mozilla46
Tracking | Status | |
---|---|---|
firefox46 | --- | fixed |
People
(Reporter: cv2pf6ip50, Assigned: mcmanus)
References
Details
Attachments
(1 file)
6.36 KB,
patch
|
mayhemer
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.0.3705; .NET CLR 1.1.4322) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 If our server returns HTTP 410, Firefox ignores it and treats it as if it was 404. Our server returns 410 for the /favicon.ico file. Despite that Firefox keeps requesting the file while the user continues browsing other pages on the same site (e.g. domainc.com/index.html and then domain.com/some.html). 410 means _permanently_ gone (unlike 404) so the file should NOT be requested again. In the case of favicon.ico, it is Firefox that makes the request (not the user or any external linking entity). So it is Firefox who has to remember that it should not request the file again (at least for the session). Reproducible: Always
Comment 1•19 years ago
|
||
->Core:Networking:HTTP
Assignee: nobody → darin
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Version: unspecified → 1.7 Branch
Comment 2•19 years ago
|
||
there are two issues here... 1) favicons should cache nonexistance (not a necko issue) 2) 410 Gone should make necko not re-request the page (a necko issue)
Updated•19 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: Firefox does not honor HTTP 410 Gone → Necko does not honor HTTP 410 Gone
Version: 1.7 Branch → Trunk
Comment 3•18 years ago
|
||
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Assignee | ||
Updated•14 years ago
|
Component: Networking → Networking: Cache
QA Contact: networking → networking.cache
Assignee | ||
Comment 5•9 years ago
|
||
I've adjust the heuristic approach for 410 to allow more caching (because I agree that 410 is a strong implicit signal).. explicit response headers should still be honored. https://treeherder.mozilla.org/#/jobs?repo=try&revision=3da4a1c6b67e
Assignee | ||
Comment 6•9 years ago
|
||
Attachment #8701191 -
Flags: review?(honzab.moz)
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → mcmanus
Status: NEW → ASSIGNED
Comment 7•8 years ago
|
||
Comment on attachment 8701191 [details] [diff] [review] heuristic cache rule for 410 should be longer Review of attachment 8701191 [details] [diff] [review]: ----------------------------------------------------------------- ::: netwerk/test/unit/test_cacheflags.js @@ +280,5 @@ > var test = gTests.shift(); > test.run(); > } > > +function handler(okStatus, metadata, response) { s/okStatus/httpStatus/ ?
Attachment #8701191 -
Flags: review?(honzab.moz) → review+
Assignee | ||
Comment 8•8 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/ed4c1a14f442bbcb584ac1eaeb7c1fd95d373313 Bug 299031 - heuristic cache rule for 410 should be longer r=mayhemer
Comment 9•8 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/ed4c1a14f442
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
status-firefox46:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla46
You need to log in
before you can comment on or make changes to this bug.
Description
•