[whatwg] Fragments included in Application Cache master entries

Maria Khomenko maria.khomenko at gmail.com
Mon Jul 6 19:13:00 PDT 2009

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.


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 (
> 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-0002.htm>

More information about the whatwg mailing list