New issue
Advanced search Search tips
Starred by 6 users

Issue metadata

Status: Archived
Owner: ----
Closed: Aug 2015
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug



Sign in to add a comment

Accept header on GET request for appcache manifest

Reported by hubert.s...@gmail.com, Aug 3 2012

Issue description

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?
 
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.
Project Member

Comment 2 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-Undefined

Comment 3 by Deleted ...@, 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?
Status: Archived
Archiving unconfirmed issues, which have not been modified (commented on, updated, etc...) in over 2 years.

Sign in to add a comment