Skip to content

Instantly share code, notes, and snippets.

@annevk
Last active December 21, 2015 10:59
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save annevk/6295844 to your computer and use it in GitHub Desktop.
Save annevk/6295844 to your computer and use it in GitHub Desktop.
zip fragments

Overview

This is a revision of https://gist.github.com/annevk/6174119 focusing on putting the semantics in the fragment identifier instead. The fragment identifier would follow http://www.w3.org/TR/media-frags/ (media-frags) and we'd introduce a new keyword http://www.w3.org/TR/media-frags/#processing-name-value-lists "path":

The general structure would be:

{URL-to-zip}#{media-frags}

http://fetch.spec.whatwg.org/ would be modified to support sub-responses for zip resources. First the resource would be fetched and then if it's a zip resource (signature sniffing) the fragment identifier would be processed per media-frags. The "path" keyword would be used to locate the sub-resource.

Examples

/package.zip#path=image.jpg
/package.zip#path=image.jpg&xywh=160,120,320,240

Non-support in browsing contexts

Because navigating to such zip resources would create more complicated processing for inline links (e.g. what would #test do?) that is not supported for now.

Updating fragment identifiers

We should make sure that the various contexts that allow for manipulation of the URL do the same thing for updating the fragment as they would do for updating the path.

@chery7278
Copy link

This will pose some challenges to implement since fragment resolution is at least in Gecko completely separate from the network stack. And we really want the network stack to deal with the zip support since otherwise we'll never get it consistently working.

But hopefully we can ensure that the fragment reaches the network stack, even though in most cases it doesn't use it.

But it's a bummer to not supporting putting the HTML file in the zip bundle. Obviously a lot better than status quo though.

Is there really no character that's not allowed (i.e. used rarely enough) in URLs that we could steal for "bundle support". I.e. something like

{URL-to-zip}`{relative-URL-inside-zip}[#{resource-fragment}]

If we had something like that then relative URLs could even be defined to work within the bundle. So if the base URL is

http://example.com/bundle.zip`files/index.html

then something lie like would resolve to

http://example.com/bundle.zip`image/pic.jpg

If we can't find a character like that then I agree that using fragments is a big step forward.

@sicking
Copy link

sicking commented Aug 21, 2013

Previous comment was from me on a borrowed computer :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment