Open
Bug 739178
Opened 14 years ago
Updated 3 years ago
Caching persistence of expiry time
Categories
(Core :: Networking: HTTP, defect, P3)
Tracking
()
UNCONFIRMED
People
(Reporter: simon, Unassigned)
Details
(Whiteboard: [necko-backlog])
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120325 Firefox/13.0a2
Build ID: 20120325042010
Steps to reproduce:
Web server was originally configured to deliver 304 requests without an expiry time.
I corrected the web server to deliver an expiry time with 304 requests.
Client has Firebug, and was behind Squid proxy.
On correcting the expiry headers, the objects continued to behave as if they were expired despite headers appearing correct.
I assume this is a rare occurrence that web servers fail to provide expires headers with 304 requests (although this did affect early versions of Apache2). However the concern is the problem persists indefinitely afterwards.
It is conceivable that the bug might affect other content that was previously excluded from caching, but now caching is allowed, but which is marked with a zero expiry time in the browser.
Actual results:
The parameter 'cache "expires"' as displayed by Firebug for the objects in disk cache remains at "1 Jan 1970". Even when the object was specifically refreshed.
Only explicitly clearing the browser cache permitted the expected behaviour (content be cached for one day) to start functioning.
The behaviour isn't fully characterised by the description above as Squid proxy was also not caching the images, until I requested the object using wget, at which point the unnecessary requests were correctly served via Squid Proxy rather than web server. So it is possible that a similar bug exists in Squid, or that I am missing some relevant concept or idea.
Expected results:
The disk cache "expires" should be updated to be the same as the current "expires" header when processing a 304 response, even if previously no "expires" header was included in the HTTP response.
Updated•14 years ago
|
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
QA Contact: untriaged → networking.http
Comment 1•10 years ago
|
||
I'm guessing this is wfm but it should be confirmed
Whiteboard: [necko-backlog]
Comment 2•8 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Comment 3•8 years ago
|
||
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3
Updated•3 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•