Chrome Version : 21.0.1180.15 (144745) It's not really a bug but it bugs me ;-) When dealing with appcache, the browser has to make an HTTP request to GET the manifest file. The HTTP GET request doesn't have any "accept" header in Chrome (linux). This prevents the appcache to work in certain mod_security configuration since the lack of "accept" is considered bad. Heres' a detail of some headers in some other browsers : Firefox (linux), Default (android), Firefox (android) : Accept:text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Safari (iOS) : Accept:*/* I'm not sure if the different specs provide any informations on that. What do you think?
Oct 21 2012,
The same problem seems to apply when the Chrome requests the page and stores it in the application cache. The first "regular" HTTP request uses this accept header: Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 However when the page gets stored in the application cache, the request doesn't contain any Accept header at all. This behavior makes the page that's stored in the cache differ from the page that the user first views in some cases.
Mar 10 2013, Project Member
Jun 3 2013,
This will be an issue for any offline app using a Web Application Firewall (think PCI, mod_security) and hence is a real issue. @Google - any ideas when this might get resolved?
Aug 25 2015,
Archiving unconfirmed issues, which have not been modified (commented on, updated, etc...) in over 2 years.
Sign in to add a comment