If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

"appcache validate" says cache-control: no-store but ... it isn't?

RESOLVED WORKSFORME

Status

()

Firefox
Developer Tools: Graphic Commandline and Toolbar
RESOLVED WORKSFORME
a year ago
a year ago

People

(Reporter: geoffrey.wiseman, Unassigned)

Tracking

49 Branch
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

a year ago
Created attachment 8798010 [details]
IMG_5067.jpg

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/602.1.50 (KHTML, like Gecko) Version/10.0 Safari/602.1.50

Steps to reproduce:

Opened the developer console. Entered "appcache validate". Waited for the results. Compared results with network tab.


Actual results:

Firefox says resources are cache-control: no-store. Local curl output and Firefox itself imply that's not true.


Expected results:

Validation of my appcache that matches the actual headers.

Updated

a year ago
Component: Untriaged → Developer Tools: Graphic Commandline and Toolbar
Product: Core → Firefox
Summary: appcache validate says cache-control: no-store but ... it isn't? → "appcache validate" says cache-control: no-store but ... it isn't?
Mike - I think you're better placed to triage this..
Flags: needinfo?(mratcliffe)
Let's take a look:
A33E6935F5693DA0398D4254D399D20B.cache.html has cache-control set to no-store. This will prevent the application cache from storing the file at line 7.

$ curl -I https://cloud.eaccess.ca/apollo/A33E6935F5693DA0398D4254D399D20B.cache.html
HTTP/1.1 200 OK
Date: Tue, 11 Oct 2016 13:20:39 GMT
Server: Apache/2.4.23 (Amazon) OpenSSL/1.0.1k-fips
Last-Modified: Sat, 24 Sep 2016 23:21:48 GMT
ETag: "1dd53f-53d4928aebb00"
Accept-Ranges: bytes
Content-Length: 1955135
Expires: 1
Content-Type: text/html; charset=UTF-8

The header contains an Expires value of 1. The RFC (https://tools.ietf.org/html/rfc2616#page-127) states:
"The format is an absolute date and time as defined by HTTP-date in section 3.3.1"

And then in section 3.3.1:
"Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format"

So, in short, you have an invalid Expires header which is forcing the cache to expire.
Status: UNCONFIRMED → RESOLVED
Last Resolved: a year ago
Flags: needinfo?(mratcliffe)
Resolution: --- → WORKSFORME
It's a good idea to set expires headers on your web server for *.appcache files to expire immediately. This avoids the risk of caching manifest files. For example, in Apache you can specify such a configuration as follows:
ExpiresByType text/cache-manifest "access plus 0 seconds"

You shouldn't do this for non-manifest files though.
(Reporter)

Comment 4

a year ago
The '1' was just a test value I changed in testing the apache conf with firefox -- although I believe what was there before was also bad. I've tweaked the Apache config and that change alone caused the validation to pass. Thanks.

I guess you're saying the invalid Expires value is causing the validation (or some component of Firefox) to think of it as "no-store" even though it isn't set to no-store? 

A more clear error would be nice here, if possible. Maybe the true values aren't accessible to the validator?
You need to log in before you can comment on or make changes to this bug.