The validator should catch submissions that have appcache errors. These apps can't even be installed, so it's better for the dev to get this feedback right away rather than wait for the app review team.
Is what you're asking me to do: 1. Write a parser for appcache 2. Make assertions for each component of the appcache spec I'm not sure if a non-2xx from an item in the appcache will cause the manifest to fail. Does it?
all non-2xx responses will cause a failure (redirects are apparently considered harmful). Including the appcache_path in the cache itself will render an app permanently unusable, so detecting that might be good too.
We cap the number of requests that the validator is allowed to make at about 16 right now (larger numbers could be used as an attack vector for people trying to ddos a website). That will prevent us from being thorough.
The vast majority of apps aren't going to get anywhere near 16 though, right? If you do hit 16, just initiate a warning that you weren't thorough because there were too many.
(In reply to Wil Clouser [:clouserw] from comment #4) > The vast majority of apps aren't going to get anywhere near 16 though, > right? If you do hit 16, just initiate a warning that you weren't thorough > because there were too many. Every appcache asset needs to be tested. If there are 25 PNGs in the appcache, we need to make 25 individual requests. The Marketplace alone makes at least two dozen appcacheable requests for stylesheets, scripts, SVGs, PNGs, language packs, etc.