- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 31 Jan 2011 23:28:35 +0000 (UTC)
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. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 31 January 2011 15:28:35 UTC