User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0; T312461) Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.4.1) Gecko/20031008 When viewing web pages via a secure connection the browser doesn't respect the specified cache/expires time. This is the case for both when the expires info is given in the HTML header (example: https://www.stree.com/420Beech/Craig/photoAlbum) and when expires info is given in the HTTP header (example: https://www.stree.com/420Beech/Craig/photoAlbum/030724-DSC03552.jpg) The fact that expires info isn't being respected is not only evident by behavior of the browser pulling the file from the server vs. from cache but also by viewing 'page info'. On 'page info' "(no expiration set)" is indicated for "Expires:" It seems that this is only a problem for secure connection (HTTPS). Viewing either of the two examples given above over a non-secure connection (HTTP vs. HTTPS) does give correct Expires: info on 'page info'. I have confirmed that Mozilla 1.5 gives same behave. Reproducible: Always Steps to Reproduce: 1. browse https://www.stree.com/420Beech/Craig/photoAlbum 2. paste same URL into another tab (or window) of Mozilla - see that it pulls from server vs. cache 3. "right click" and select 'View page info' - see that value for Expires: is "(no expiration set)" Actual Results: 2. page is pulled from server 3. see "(no expiration set)" Expected Results: 2. should pull page from cache 3. should show expiration date/time as does when viewing http://www.stree.com/420Beech/Craig/photoAlbum (non-secure)
The page sends (for the image, eg): Expires: Sun, 09-May-2004 23:25:08 GMT That should be (actually a MUST in the http rfc): Expires: Sun, 09 May 2004 23:25:08 GMT The function we use to parse the header handles "09-May-2004 23:25:08 GMT" but not "Sun, 09-May-2004 23:25:08 GMT", it looks like.... See http://lxr.mozilla.org/mozilla/source/nsprpub/pr/include/prtime.h#233 Over to networking, but I'm not sure we care to fix it if this is the only site in the world that's using this incorrect format for the date.
Assignee: general → darin
Component: Browser-General → Networking
QA Contact: general → benc
expires time in the HTML header IS in correct format, browser behaves differently if viewed via HTTP vs. HTTPS https://www.stree.com/420Beech/Craig/photoAlbum http://www.stree.com/420Beech/Craig/photoAlbum
example given in comment #2 worksforme. the documents are getting cached when loaded over HTTPS, and the documents are being reused from the cache. i tested a recent trunk build under linux. it is possible that page-info is not showing the right information. about:cache shows that the documents are valid until sometime in 2004. indeed, they are reused from the local cache for the duration of the browser session. NOTE: content loaded over HTTPS is removed from the cache when you exit the browser.
so, the browser appears to be respecting expiration information correctly. in that regard this bug could be marked WORKSFORME. however, given that page-info seems to be giving the wrong information here, we might want to morph this bug into a bug against page-info.
yes, the problem is that page info is forced to rely on the cache to get that information, but pages from HTTPS connections are never cached. What I need to do is to rewrite page info so that instead of picking up all the half-truths that are left around by accident, all the information we need is explicitly stored for use by page info.
Reassigning and resummarizing based on comment 5
Assignee: darin → db48x
Status: UNCONFIRMED → NEW
Component: Networking → Page Info
Ever confirmed: true
Summary: browser doesn't respect expires info for secure pages → Page info doesn't display expires for https pages
We don't show the expires data these days
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.