Re: [whatwg] Appcache feedback (various threads)
On 2/1/11 11:47 AM, Adam de Boor wrote:
On Mon, Jan 31, 2011 at 3:28 PM, Ian Hickson wrote:
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.
The one concern I'd add to this mix is cache installation in the presence of
funny network environments, specifically misbehaving proxies, or browser
extensions / plugins. As an app developer, it's always helpful to have as
many tools as possible to debug problems that happen in the wild. For a
supposedly-standardized environment like the web, it's amazing to me how
many there are... It's feasible to have a small set of users click something
to create a log file they can email you, but asking them to fire up the
debugger in their browser? No.
Yes, that was my intention - not something for web developers, but
something I can put in my code that would collect diagnostics that I
could report to the user ("problem with cache file: xyz.abc").
I just tested Chrome beta this morning and saw nothing interesting in
appcache error events, however progress events have now grown "loaded"
and "total" properties (think those were the names, and I think they're
new-ish). That's nice, as I can provide a progress meter during cache
load/reload. I wouldn't mind having the URL of the resource being
loaded (that was just loaded?) as well as those numbers. And for errors
it would be nice to know, in the case of an error caused by a cache
manifest entry 404'ing (or otherwise unavailable), what URL it was.
HTTP error code, if appropriate, etc.
Cache resources that aren't available is a particularly nasty issue,
since the result is rather heavy-handed - the entire cache reload is
canceled. That's fine (or a fight for another day anyway), but it would
be nice to know WHY the cache reload failed. Programmatically. Today,
all we know is it failed. The browser knows WHY it failed, but has no
way to inform us, outside of an appcache-grokkable debugger.
--
Patrick Mueller - http://muellerware.org
Re: [whatwg] Appcache feedback (various threads)
On Mon, Jan 31, 2011 at 3:28 PM, Ian Hickson wrote: > 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. > The one concern I'd add to this mix is cache installation in the presence of funny network environments, specifically misbehaving proxies, or browser extensions / plugins. As an app developer, it's always helpful to have as many tools as possible to debug problems that happen in the wild. For a supposedly-standardized environment like the web, it's amazing to me how many there are... It's feasible to have a small set of users click something to create a log file they can email you, but asking them to fire up the debugger in their browser? No. a
Re: [whatwg] Appcache feedback (various threads)
On Mon, Jan 31, 2011 at 7:43 PM, Ian Hickson wrote: > It appears you're actually talking about ClickOnce manifests, not SxS > manifests (though they use the same format). > (In that particular case, SxS manifests distributed standalone for people to drop into application installations when troubleshooting--but the main point was just that it's a name likely to collide.) I've changed the suggested extension to ".appcache". > That seems fine. Thanks. -- Glenn Maynard
Re: [whatwg] Appcache feedback (various threads)
On Mon, 31 Jan 2011, Glenn Maynard wrote: > On Mon, Jan 31, 2011 at 7:12 PM, Ian Hickson wrote: > > > > Given that SxS manifests don't seem like they'd ever be something > > you'd want to make available to download standalone, and that if you > > were going to expose them to a user you'd want a text/* type anyway, > > and that cache manifests are clearly different (no valid SxS manifest > > can be a valid appcache manifest), I'm honestly not finding a very > > compelling reason to make appcache manifsts have a more verbose > > extension. The clash here seems rather theoretical. > > I've exposed cache manifests for standalone download many times. It appears you're actually talking about ClickOnce manifests, not SxS manifests (though they use the same format). These would indeed be distributed. I've changed the suggested extension to ".appcache". -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Appcache feedback (various threads)
On Mon, Jan 31, 2011 at 7:12 PM, Ian Hickson wrote: > On Mon, 31 Jan 2011, Glenn Maynard wrote: > > On Mon, Jan 31, 2011 at 6:46 PM, Ian Hickson wrote: > > > > > > That's far too generic for servers to default to mapping *.manifest > > > > to text/cache-manifest. For example, Windows uses *.manifest for > > > > SxS assembly manifests. > > > > > > Do they have a MIME type? If not, it doesn't much matter. > > > > It does if they're ever served by a webserver, because they'll be served > > with a completely unrelated Content-Type. (Also, the file format is > > actually XML, so arguably they do--application/xml--though I wouldn't > > configure a server that way in general.) > > > > Microsoft's mistake is using such a generic name--but these files > > shouldn't make the same mistake and lay claim to "*.manifest" as if it's > > the only type of manifest that exists. File extensions will never be > > without collisions, but an effort should at least be made... > > Given that SxS manifests don't seem like they'd ever be something you'd > want to make available to download standalone, and that if you were going > to expose them to a user you'd want a text/* type anyway, and that cache > manifests are clearly different (no valid SxS manifest can be a valid > appcache manifest), I'm honestly not finding a very compelling reason to > make appcache manifsts have a more verbose extension. The clash here seems > rather theoretical. > I've exposed cache manifests for standalone download many times. And of course they're clearly different--that's exactly why it's wrong for a SxS manifest to be served with a content-type as if they're a cache manifest. And, more importantly, it's rather bad practice to be laying claim to generic names like "manifest". Even "cmanifest" would be much better. -- Glenn Maynard
Re: [whatwg] Appcache feedback (various threads)
* Glenn Maynard wrote: >On Mon, Jan 31, 2011 at 6:46 PM, Ian Hickson wrote: >> > That's far too generic for servers to default to mapping *.manifest to >> > text/cache-manifest. For example, Windows uses *.manifest for SxS >> > assembly manifests. >> >> Do they have a MIME type? If not, it doesn't much matter. > >It does if they're ever served by a webserver, because they'll be served >with a completely unrelated Content-Type. (Also, the file format is >actually XML, so arguably they do--application/xml--though I wouldn't >configure a server that way in general.) http://lmgtfy.com/?q=application+manifest+file+mime -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Appcache feedback (various threads)
On Mon, 31 Jan 2011, Glenn Maynard wrote: > On Mon, Jan 31, 2011 at 6:46 PM, Ian Hickson wrote: > > > > That's far too generic for servers to default to mapping *.manifest > > > to text/cache-manifest. For example, Windows uses *.manifest for > > > SxS assembly manifests. > > > > Do they have a MIME type? If not, it doesn't much matter. > > It does if they're ever served by a webserver, because they'll be served > with a completely unrelated Content-Type. (Also, the file format is > actually XML, so arguably they do--application/xml--though I wouldn't > configure a server that way in general.) > > Microsoft's mistake is using such a generic name--but these files > shouldn't make the same mistake and lay claim to "*.manifest" as if it's > the only type of manifest that exists. File extensions will never be > without collisions, but an effort should at least be made... Given that SxS manifests don't seem like they'd ever be something you'd want to make available to download standalone, and that if you were going to expose them to a user you'd want a text/* type anyway, and that cache manifests are clearly different (no valid SxS manifest can be a valid appcache manifest), I'm honestly not finding a very compelling reason to make appcache manifsts have a more verbose extension. The clash here seems rather theoretical. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Appcache feedback (various threads)
On Mon, Jan 31, 2011 at 6:46 PM, Ian Hickson wrote: > > That's far too generic for servers to default to mapping *.manifest to > > text/cache-manifest. For example, Windows uses *.manifest for SxS > > assembly manifests. > > Do they have a MIME type? If not, it doesn't much matter. > It does if they're ever served by a webserver, because they'll be served with a completely unrelated Content-Type. (Also, the file format is actually XML, so arguably they do--application/xml--though I wouldn't configure a server that way in general.) Microsoft's mistake is using such a generic name--but these files shouldn't make the same mistake and lay claim to "*.manifest" as if it's the only type of manifest that exists. File extensions will never be without collisions, but an effort should at least be made... -- Glenn Maynard
Re: [whatwg] Appcache feedback (various threads)
On Mon, 31 Jan 2011, Glenn Maynard wrote: > On Mon, Jan 31, 2011 at 6:28 PM, Ian Hickson wrote: > > 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's far too generic for servers to default to mapping *.manifest to > text/cache-manifest. For example, Windows uses *.manifest for SxS > assembly manifests. Do they have a MIME type? If not, it doesn't much matter. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Appcache feedback (various threads)
On Mon, Jan 31, 2011 at 6:28 PM, Ian Hickson wrote: > 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's far too generic for servers to default to mapping *.manifest to text/cache-manifest. For example, Windows uses *.manifest for SxS assembly manifests. -- Glenn Maynard
Re: [whatwg] Appcache feedback (various threads)
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Appcache feedback (various threads)
On 2010/8/13, at 上午6:42, Anne van Kesteren wrote: > On Fri, 13 Aug 2010 15:02:01 +0200, 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. > > 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. 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. 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. David
Re: [whatwg] Appcache feedback (various threads)
On Fri, 13 Aug 2010 15:02:01 +0200, 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. 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. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Appcache feedback (various threads)
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. - for all error conditions, some indication of WHAT error occurred. Presumably an error code. If the error involved a particular resource, I'd like the URL of the resource as well. I'm not sure what the best mechanisms might be to provide this info: - extend the events used to add this information - provide this information in the ApplicationCache interface - lastErrorCode, lastResourceDownloaded, etc - define a new object as the target for these events (currently undefined,or at least not clear to me), and add that info to the target - something else Could you describe how you would use this information? What would you do differently based on this information? again: diagnostic information. Of course, there's not much I can "do" differently, based on this information, since there's little I can "do" with app-cache to begin with, being largely declarative. I understand the typical response here is: use a debugger. That's fine, and that's right, for most of my purposes, but means I'm relying on a tool to get information, that a normal application might not be able to retrieve. 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". There's a good argument for not providing this information, I suppose: you can't get it for non-app-cache scenarios, why should you get it for app-cache scenarios? (I'm assuming here that you can't get HTTP-transport level information from anything but XHR, WebSocket, etc sort of APIs - you don't get that sort of information about a .css file you referenced in your .html file, for instance). Additionally, are there security issues that I'm not aware of (haven't though enough about)? None-the-less, we do have these nice events coming in, there's plenty of room for more information in them, and they would serve a useful purpose since app-cache has proven, to me, to be an occasionally challenging corner of the room to play in. -- Patrick Mueller - http://muellerware.org
Re: [whatwg] Appcache feedback (various threads)
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. -- Patrick Mueller - http://muellerware.org
Re: [whatwg] Appcache feedback (various threads)
On Aug 12, 2010, at 3:29 PM, Ian Hickson wrote: >> These quotas are often global, some kind of user setting, or are >> per-origin. Application Caches are missing such a quota. >> >> The entire "Disk Space" section of Web SQL Databases could equally apply >> to Application Caches: http://dev.w3.org/html5/webdatabase/#disk-space > > I suppose that's not unreasonable. I've added a similar section to the > appcache section. Excellent. The text [1][2] looks great. >> The likely behavior would be the user agent emits an "error" event. >> However, storage limits are not specified in the spec as an error >> condition: >> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#event-appcache-error > > In general the specification does not specify behaviour in handling > constraints of the operating environment (e.g. out of memory, out of disk > space). I've added some generic handling for this. We can add more > detailed error reporting in a future version if there are good reasons to > do this. Good to know. Thanks. - Joe [1]: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#disk-space [2]: http://html5.org/tools/web-apps-tracker?from=5286&to=5287
