[whatwg] Appcache feedback (various threads)

[Ian Hickson]

On Fri, 13 Aug 2010, Patrick Mueller wrote:
> On 8/12/10 6:29 PM, Ian Hickson wrote:
> > On Thu, 29 Jul 2010, Anne van Kesteren wrote:
> > > 
> > > XML would be much too complex for what is needed. We could possibly 
> > > remove the media type check and resort to using the "CACHE MANIFEST" 
> > > identifier (i.e. "sniffing"), but the HTTP gods will get angry.
> > 
> > Yeah, that's pretty much the way it is.
> 
> Although I haven't personally had a problem dealing with the 
> content-type requirement, I have heard from at least one other colleague 
> who did; their server was harder to configure.
> 
> I had assumed the reason for having the specific text/cache-manifest 
> content type was to force people to "opt-in" to support, instead of 
> being able to just read a random URL and having it interpreted, perhaps 
> maliciously, as a manifest.
> 
> If that's not a concern, then I'd like to understand the ramifications 
> of getting the HTTP angry gods angry by ignoring the content-type.

On Fri, 13 Aug 2010, Anne van Kesteren wrote:
> 
> In HTTP (starting HTTP/1.0), entity bodies are identified by the 
> Content-Type header, not by themselves. We violate that for a number of 
> scenarios, but we try to stay clear of it in new, until such time comes 
> that we give up completely on Content-Type. It's a compromise.

Indeed.


On Fri, 13 Aug 2010, David John Burrowes wrote:
> 
> I can understand wanting to do things right, in terms of using 
> Content-Type for the file.  I can also attest that it can be a royal 
> pain to diagnose when this is set wrong.  I wonder it it would make 
> sense to have a recommended file extension for the manifest (e.g. 
> "cachemanifest" so "myapp.cachemanifest"). (maybe "manifest" is a fine 
> extension, as implied in the spec.  It seems a bit generic of a name to 
> me, though). This way, web server developers could add this into their 
> default configurations.

The spec's text/cache-manifest registration suggests "manifest".


> That is, life will be a lot easier for page developers in the future, if 
> (say) apache ships with a rule that automatically delivers 
> "cachemanifest" (or whatever) files with the text/cache-manifest content 
> type.  That way everything will "just work" for normal situations.

Indeed.


On Fri, 13 Aug 2010, Patrick Mueller wrote:
> On 8/12/10 6:29 PM, Ian Hickson wrote:
> > On Wed, 19 May 2010, Patrick Mueller wrote:
> > > 
> > > I've been playing with application cache for a while now, and found 
> > > the diagnostic information available to be sorely lacking.
> > > 
> > > For example, to diagnose user-land errors that occur when using 
> > > appcache, this is the only practical tool I have at my disposal:
> > > 
> > >     tail -f /var/log/apache2/access_log /var/log/apache2/error_log
> > > 
> > > I'd like to be able to get the following information:
> > > 
> > > - during "progress" events, as identified in step 17 of the 
> > > application cache download process steps in 6.6.4 "Downloading or 
> > > updating an application cache"), I'd like to have the URL of the 
> > > resource that is about to be downloaded.  The "progress" event from 
> > > step 18 ( indicating all resources have been downloaded) doesn't 
> > > need this.
> > 
> > What do you need this for?
> 
> See the first sentence: diagnostic information.

Surely if you want to debug the appcache update mechanism it'd be easier 
just to have the browser provide you with a dedicated debugging tool for 
it than for the browser to provide you with more information in an event.


> As an example, an application might collect a log of errors and post 
> them back to a server for diagnostic purposes later.  Not possible if 
> the only way to get app-cache diagnostics is with a "web debugger".

That rather depends on the debugger.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'