The problem I'm seeing is not with URLs listed in the manifest, but rather for URLs added to the Application Cache because they were navigated to and pointed to an existing manifest. I think the following excerpt is the relevant part of the spec:<br>
<br><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote"> <dfn id="concept-appcache-master" title="concept-appcache-master">Master entries</dfn><br>
<dl><dd>Documents that were added to the cache because a
<a href="http://www.whatwg.org/specs/web-apps/current-work/#browsing-context">browsing context</a> was <a href="http://www.whatwg.org/specs/web-apps/current-work/#navigate" title="navigate">navigated</a> to that document and the
document indicated that this was its cache, using the <code title="attr-html-manifest"><a href="http://www.whatwg.org/specs/web-apps/current-work/#attr-html-manifest">manifest</a></code> attribute.
</dd></dl></blockquote><br>Andrew<br><br><div class="gmail_quote">On Mon, Jul 6, 2009 at 7:13 PM, Maria Khomenko <span dir="ltr"><<a href="mailto:maria.khomenko@gmail.com">maria.khomenko@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Actually, I believe the spec does address the question in the following passage (this is in the manifest parsing algorithm):<br>
<div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
If mode is "explicit"</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
Resolve the first item in tokens, relative to base URL; ignore the rest.</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
If this fails, then jump back to the step labeled "start of line".</blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
If the resulting absolute URL has a different <scheme> component than the manifest's URL (compared in an ASCII case-insensitive manner), then jump back to the step labeled "start of line".</blockquote>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<b>Drop the <fragment> component of the resulting absolute URL, if it has one.</b></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
<br></blockquote><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0px 0px 0px 0.8ex; padding-left: 1ex;">
Add the resulting absolute URL to the explicit URLs.</blockquote><div><br></div><div>So it must be an implementation issue.</div><div><br></div><div>Cheers,</div><div>Maria </div><div><div></div><div class="h5"><br>On Mon, Jul 6, 2009 at 3:37 PM, Andrew Grieve <<a href="mailto:agrieve@google.com" target="_blank">agrieve@google.com</a>> wrote:<br>
><br>> The current behavior in Webkit is for URL fragments to be stored in the<br>> URLs for master entries. I believe this to be a bug in Webkit, but cannot<br>> determine from the spec if this is or not.<br>
><br>> Example:<br>><br>> 1. Navigate to: <a href="http://www.thecssninja.com/demo/offline_webapp/#foo" target="_blank">http://www.thecssninja.com/demo/offline_webapp/#foo</a><br>> 2. Go offline<br>> 3. Do a browser refresh and ensure the page refreshes from AppCache.<br>
> 4. Change the URL hash to #bar<br>> 5. Do a browser refresh and notice that it fails to load.<br>><br>> I've filed a bug on <a href="http://webkit.org" target="_blank">webkit.org</a> (<a href="https://bugs.webkit.org/show_bug.cgi?id=26925" target="_blank">https://bugs.webkit.org/show_bug.cgi?id=26925</a>)<br>
> regarding this, but realized that the spec is unclear about what is<br>> expected here. Since fragments are not sent to servers, I can't see<br>> why they would be included in the master entry URLs as they make no<br>
> difference in the content that is served.<br>><br>> Anyone know if the spec does in fact address this issue?<br>><br>> Andrew<br>
</div></div></blockquote></div><br>