HTML and CSS Reference
In-Depth Information
manifest and it can't be accessed with the existing connection,
then serve up the file specified on the right side, in my case
fallback-server-time.js . The fallback file fallback-server-time.js
is included in the files that are cached by the browser, just as
files are in the CACHE category. We'll look at the fallback category
in more detail in the next section.
FALLBACK also allows you to use URL paths, so you could use the
following:
FALLBACK:
server-time.js fallback-server-time.js
/ offline.html
This tells the browser that if server-time.js is requested and it's
unavailable, then serve up fallback-server-time.js . If any other
path is requested, such as /foo.html , and it's unavailable (either
because you're offline or it's not in the cache), the browser will
serve offline.html . This method can be used to easily define an
entire portion of your site to only be available online and redi-
rect the user to offline.html if they try to access a resource while
they're not connected. Note that giving this rule that is catch-
ing all failed requests, it also means that currently, if an image
URL results in a 404, it will be served offline.html—so you would
need to add multiple sensible rules to your fallback category.
Figure 7.2 shows my time application when the app doesn't
have connectivity to the site, and the request for server-time.js
falls back to fallback-server-time.js showing an entirely differ-
ent message.
NoTE Cachebusting
means to forcefully prevent
the resource from being cached.
In the example of the manifest,
this is achieved by changing its
contents.
FIguRE 7.2 My time
application continues to work
whilst offline, pulling a different
resource for the server-time
JavaScript file.
Finally, I've included a comment in the file, starting with the
#  symbol (note that comments must be on their own line, too).
This tells me the version number. This is important to cachebust
the manifest. It's not that a comment is required, but something in
the manifest file must change. Personally I like to use a comment
or revision number of MD5 hash of all the files in the application.
This change in the manifest file tells the browser to reload the
contents of the offline manifest. Also, you can't just change the
timestamp on the manifest or any of the assets to force a reload,
but changing anything inside the manifest will force a reload.
NoTE Browsers like the
manifest and don't let go of
their cache easily. Make sure you
include a comment that has a
version number, revision, or time-
stamp that you can change and
force an update to the browser's
manifest for your domain.
 
Search WWH ::




Custom Search