- From: Maria Khomenko <maria.khomenko@gmail.com>
- Date: Mon, 6 Jul 2009 19:13:00 -0700
Actually, I believe the spec does address the question in the following passage (this is in the manifest parsing algorithm): > If mode is "explicit" Resolve the first item in tokens, relative to base URL; ignore the rest. > If this fails, then jump back to the step labeled "start of line". > 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". > *Drop the <fragment> component of the resulting absolute URL, if it has > one.* > Add the resulting absolute URL to the explicit URLs. So it must be an implementation issue. Cheers, Maria On Mon, Jul 6, 2009 at 3:37 PM, Andrew Grieve <agrieve at google.com> wrote: > > The current behavior in Webkit is for URL fragments to be stored in the > URLs for master entries. I believe this to be a bug in Webkit, but cannot > determine from the spec if this is or not. > > Example: > > 1. Navigate to: http://www.thecssninja.com/demo/offline_webapp/#foo > 2. Go offline > 3. Do a browser refresh and ensure the page refreshes from AppCache. > 4. Change the URL hash to #bar > 5. Do a browser refresh and notice that it fails to load. > > I've filed a bug on webkit.org ( https://bugs.webkit.org/show_bug.cgi?id=26925) > regarding this, but realized that the spec is unclear about what is > expected here. Since fragments are not sent to servers, I can't see > why they would be included in the master entry URLs as they make no > difference in the content that is served. > > Anyone know if the spec does in fact address this issue? > > Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20090706/62800e5c/attachment.htm>
Received on Monday, 6 July 2009 19:13:00 UTC