<div dir="ltr">Hi Dave,<div><br></div><div>Thanx for taking a look.<br><br><div class="gmail_quote">On Mon, Sep 15, 2008 at 2:25 PM, Dave Camp <span dir="ltr"><<a href="mailto:dave.camp@gmail.com">dave.camp@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d">On Mon, Aug 25, 2008 at 11:54 AM, Michael Nordman <<a href="mailto:michaeln@google.com">michaeln@google.com</a>> wrote:<br>
<br>
</div><div class="Ih2E3d">> Manifest file section headers:<br>
> * BYPASS: list of url [namespaces/filters]<br>
> * CACHE: list of exact [urls]<br>
> * INTERCEPT: list of [urlnamespaces, namespace-handler url]<br>
> * AUTOCACHE: list of [urlnamespaces, namespace-handler url]<br>
> * FALLBACK: : list of [urlnamespaces, namespace-handler url]<br>
<br>
</div><div class="Ih2E3d">Using namespaces for bypass URIs, and separating auto-caching from<br>
fallback, both seem like big wins. We'd need to specify what to do<br>
when namespaces collide, but I figure "most specific namespace wins"<br>
would be fine.</div></blockquote><div><br></div><div>I like splitting them up too. Everyone I've spoken with thinks the "auto-cache"</div><div>feature is a convenience that really doesn't have to be in the spec. But fallback</div>
<div>and intercept are more than a convenience. The split lets us make decisions about</div><div>these independently.</div><div><br></div><div>Regarding collisions, another possibility is to check each type in order... </div>
<div> bypass, intercept, autocache, fallback.</div><div>This is in keeping with how the current draft treats the relative priorities of 'bypass'<br></div><div>vs 'opportunistic-caching'. </div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="Ih2E3d"><br>
<br>
</div><div class="Ih2E3d">> One idea is to rephrase this feature in terms closer to std http caching for<br>
> all entries that do not explicily appear in the manifest file. In<br>
> effect, closer to telling the http cache to not purge the resource.<br>
><br>
> * at initial cache time<br>
> - cache the resource<br>
><br>
> * at appCache update time<br>
> - validate all non-explicit entries per usual http caching semantics<br>
> (so 404s will remove these entries at update time)<br>
> - network/server errors do not fail the larger update<br>
> - beyond that, not sure what todo on network/server errors... remove or<br>
> retain the resources?<br>
> - perhaps maintain a list of 'failed to update' items that the webapp can<br>
> access via script<br>
<br>
</div>This all makes sense.<br>
<div class="Ih2E3d"><br>
> * at resource load time<br>
> - validate per usual http caching rules going forward<br>
> (so 404s will remove these entries)<br>
> - with the following exceptions<br>
> - use the cached resource as a fallback for network or server(5xx)<br>
> errors<br>
> - do not purge the resource upon expiration<br>
<br>
</div><div><div></div><div class="Wj3C7c">This seems reasonable, but it seems a bit strange that<br>
applicationCache.add() resources will behave differently than<br>
explicitly-listed manifest entries (on a particularly slow/flaky<br>
wireless network, parts of the application will be quick and others<br>
won't).</div></div></blockquote><div><br></div><div>I think as currently spec'd, the update / validation scheme is a non-starter,</div><div>we have to do something different in this area.</div><div><br></div><div>
Also, I can't speak for them... but in working with app teams at Google, I think</div><div>this would be a preferred way of dealing with 'extra' resources pinned in the</div><div>cache outside of the core set of js/css/html/images required to bootstrap an</div>
<div>app.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="Wj3C7c"><br>
<br>
On the subject of fallbacks, I don't think the spec is quite clear on<br>
how the fallbacks are meant to be loaded. There seem to be two<br>
possible interpretations:<br>
<br>
1) The fallback resource is loaded by the client as though it were<br>
loaded from the original URI - security decisions are made with the<br>
original URI, and window.location, bookmarks, history, etc. all<br>
reflect the original URI. This is somewhat analogous to the real<br>
server returning fallback content at the original URI.<br>
<br>
2) The fallback resource is loaded by the client as though it were<br>
loaded from the fallback URI for purposes of security decisions,<br>
window.location, etc. But bookmarks, history, etc all reflect the<br>
original URI. This is somewhat analogous to a server redirect (with<br>
bookmark/history changes to reflect the original URI), or to a frame<br>
at the original URI including the fallback URI (but without the<br>
intermediate window object).<br>
<br>
We need to decide which of these behaviors makes the most sense. The<br>
first seems the most straightforward, though I think we'd want a few<br>
changes:<br>
<br>
a) The fallback URI should be required to have the same origin as the namespace.<br>
b) Maybe there should be some way for the page to know that it was<br>
loaded as a fallback.<br>
<br>
If we settle on the second approach, we need to give the page some way<br>
to find out what the original URI was (since window.location will<br>
point to the fallback URI).<br></div></div></blockquote><div><br></div><div>I think the spec is clear that #1 should be done... or should i say that</div><div>after you've transcoded Ian's pseudo-code in english to something with curly</div>
<div>braces, this becomes apparent :)</div><div><br></div><div>I also think the spec covers the same source and origin matrix appropiately.</div><div>While handler resources may be from a different origin, all of the namespaces</div>
<div>that could be handled by a local resource are constrained to be within the same</div><div>origin of the manifest file. . So siteAs code will not run in siteB's context without</div><div>siteB's consent.</div>
<div><br></div><div>This info was scattered about in the spec, to spare people from having to decrypt</div><div>what the spec says, here are my notes on those constraints with additions for the</div><div>new namespace type (intercept) I'm advocating.</div>
<div><br></div><div><div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008"><div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008"><strong>same-origin, same-scheme
constraints</strong></span></font></div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008"></span></font> </div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">// by entry category</span></font></div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">* manifest - the manifestUrl is the location of the
resource after following redirects</span></font></div>* toplevel - same origin
as manifestUrl</span></font></div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">* explicit - same scheme</span></font></div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008"></span></font><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">* namespace-handler - same
scheme</span></font></div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008"></span></font><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">* auto-cached - same
origin</span></font></div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">* manually-cached - same
scheme</span></font></div></span></font></div></span></font></div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008"></span></font> </div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">// by namespace type</span></font></div>
<div><font size="+0"><span class="039082923-30072008">
<div><span class="039082923-30072008">
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">* bypass - same scheme</span></font></div>
<div><span class="039082923-30072008"></span><font face="Trebuchet MS"><font color="#800000"><font size="2">* intercept - <span class="039082923-30072008">same
origin [new] (although the handler only needs the same
scheme)</span></font></font></font></div></span></div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">* autocache - same origin</span></font></div>
<div><font face="Trebuchet MS" color="#800000" size="2"><span class="039082923-30072008">* fallback - same origin (although the handler only
needs the same scheme)</span></font></div><div><span class="Apple-style-span" style="color: rgb(128, 0, 0); font-family: 'Trebuchet MS'; font-size: 13px;"><br></span></div></span></font></div></div><div><br></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div class="Wj3C7c">
<br>
-dave<br>
</div></div></blockquote></div><br></div></div>