[whatwg] Fragments included in Application Cache master entries

[Maria Khomenko]

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