Cross Origin request blocked by HTML5 cache manifest on Firefox - html

Question

I am having problems doing some cross-origin requests with Firefox and the application cache.
The error handler of my XHR request get called, and the status of the XHR request is 0.
When I see the network logs with firebug, I see an OPTIONS request that looks fine :
OPTIONS /foo.bar HTTP/1.1
Host: localhost:1337
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Origin: http://localhost:8080
Access-Control-Request-Method: GET
Access-Control-Request-Headers: content-type
Connection: keep-alive
To which the server respond something that looks OK :
HTTP/1.1 200 OK
Expires: Sun, 19 Nov 1978 05:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Access-Control-Allow-Origin: http://localhost:8080
Access-Control-Allow-Methods: GET, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: content-type
Date: Thu, 14 Mar 2013 17:55:22 GMT
Connection: keep-alive
Transfer-Encoding: chunked
Then the GET itself gets no responses :
GET /foo.bar HTTP/1.1
Host: localhost:1337
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 Firefox/19.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: fr,fr-fr;q=0.8,en-us;q=0.5,en;q=0.3
Accept-Encoding: gzip, deflate
Origin: http://localhost:8080
Connection: keep-alive
(When looking at the server logs, the server never receives the request)
I am using the html5 application cache mechanism, and here is the network section of my manifest :
NETWORK:
default.php
resource.php
http://localhost:1337/
Here is what I tried :
Replace http://localhost:1337/ with * in the manifest file : It works, but I don't like it, I found blocking non explicit network request handy when it comes to detecting missing CACHE entries.
Replace the GET method with a POST method : it works, but I don't like it as it is semantically wrong (I am trying to get a resource, not to post data).
Replace the GET method with a custom-but-semantically-correct READ method : it doesn't work, but it was fun.
It is my understanding that what I am trying to do falls into the step 3 of the Changes to the networking model in the W3C's specs and should work as is.
So, after all this, my questions are :
What am I doing wrong ?
Is this a bug with firefox ? (I forgot to tell, my site works like a charm in Chrome and IE10 (yes, IE10, like Microsoft Internet Explorer version 10)
If I had to do a quirk to make it work with Firefox, which one should I do ? Is there a better solution than the 2 bad ones I found ?

Answer 1

Although the spec says that http://localhost:1337 in the NETWORK section of your cache manifest should be sufficient, it might be worth trying the full URL (http://localhost:1337/foo.bar) to see if there's a bug in Firefox's implementation.
If that doesn't do the trick and all else fails, I would just go with putting * in your NETWORK section, at least until you figure out what's causing the problem. Value code that works for your users over code that works for you. Besides, there are other ways to find missing entries in the manifest.

Answer 2

That problem was mentioned in A List Apart: Application Cache is a Douchebag. See Gotcha #9.
You have to listen to each response and then filter for response or error on your own.
$.ajax( url ).always( function(response) {
// Exit if this request was deliberately aborted
if (response.statusText === 'abort') { return; } // Does this smell like an error?
if (response.responseText !== undefined) {
if (response.responseText && response.status < 400) {
// Not a real error, recover the content resp
} else {
// This is a proper error, deal with it
return;
}
}
// do something with 'response'
});

Answer 3

There is an open defect in Firefox (see also the linked duplicate) that any cross domain resource referenced in the manifest gets blocked on subsequent refreshes. Not much you can do at this point except vote and wait.
Note that this issue should be resolved in Firefox 33 onwards.