Re: Packaging on the Web

Alex,
 
> First, thanks for capturing what seems to be broad consensus  
> on the packaging format (multi-part mime). Seems great!

I tried to capture the rationale for the multipart type for packaging. The one massive disadvantage as far as I’m concerned is the necessity for the boundary parameter in the content type. A new type that had the same syntax as a multipart type but had a sniffable boundary (ie started with --boundary) might be better than using a multipart/* content type.

> I'm intrigued by the way you're handling base URL resolution for relative
> URLs. Do you imagine that base URL metadata will be required inside  
> packages? And if you move a package off-origin, but it is CORS-fetched,  
> does that enable a third-party to "front" for a second-party origin? How
> does the serving URL get matched/merged with the embedded base  
> URL? And if the base URL metadata isn't required, what happens?

Good questions. I wasn’t imagining the base URL would be required inside packages, but would be taken as the location from which the package was fetched.

Since the Content-Location URLs have to be absolute-path-relative or path-relative (ie can’t contain a domain name), you can’t get content from one origin pretending to be from another origin. Obviously that means if you host a package you have to be careful about what it contains, but that’s true of practically any web content.

> I'm curious about the use of fragments. Yehdua covered this pretty  
> thoroughly in the constraints he previously outlined when we  
> went over this in Boston:
>  
> https://gist.github.com/wycats/220039304b053b3eedd0  
>  
> Fragments aren't sent to the server and so don't have any meaningful  
> server-based fallback or service-worker polyfill story. That  
> seems pretty fundamental. Is there something in the URL format proposal that  
> I'm missing?

I’m not sure; it depends what you’re curious about. My assumption is that, for backwards compatibility with clients that don’t understand packages, the files in a package would all be accessible from the server directly as well as through the package. In other words, if a package at `/package.pack` contains `/index.html` and `/images/icon.png` then `/index.html` and `/images/icon.png` will also be available directly on the server.

Given that set up, people who want to point to `#section` within `/index.html` can do so with the plain URL `/index.html#section`. There are no good reasons (so far as I can see) to create a link to something within the package itself when you can point directly to the thing you want to point to. Can you think of any? 

The polyfill story is that when `/index.html` was fetched, its content would be scanned and the package located. This would be used to populate the cache, using the Content-Location headers to work out the relevant URLs that were covered off by the package. On later fetches, the cache would be used for any requests to pages within it. Can you point me to the bit of that that doesn’t work?

Cheers,

Jeni
--
Jeni Tennison
http://www.jenitennison.com/

Received on Sunday, 2 February 2014 17:36:48 UTC