Open Bug 739178 Opened 14 years ago Updated 3 years ago

Caching persistence of expiry time

Categories

(Core :: Networking: HTTP, defect, P3)

13 Branch
x86_64
Linux
defect

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.
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
QA Contact: untriaged → networking.http
I'm guessing this is wfm but it should be confirmed
Whiteboard: [necko-backlog]
Priority: -- → P1
Priority: P1 → P3
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.