Subject: [Wpack] Fragment-based URL scheme

From: Larry Masinter <[email-masked]>
Date: Wed, 8 Jul 2020 17:55:21 -0700

I don't understand the cases where this doesn't meet the goal.

"the fragment might sometimes get dropped."  when? By what process?

"some code might only be looking at the host" This is some existing code?
Something web packaging would work with?

And the advantage seem to be enough to take a harder look

*	being able to use other "kinds of things with subresources, like
zip, tar, 7z, etc. files" 
gives you instant deployment  " (including PDF)
*	works with nested containers to any depth
*	You don't need to deploy a new URL scheme seem compelling

--

https://LarryMasinter.net <https://larrymasinter.net/>
https://going-remote.info <https://going-remote.info/>

---

From: Jeffrey Yasskin <[email-masked]>
Date: Thu, 9 Jul 2020 13:32:32 -0700

Thanks for the counter-proposal. I'm going to argue here in order to make
sure that we've fully understood the pros and cons of the fragment-based
scheme, not because I'm firmly opposed to it.

https://github.com/WICG/webpackage/blob/master/explainers/bundle-urls-and-origins.md#fragment-based-url-scheme
describes downsides of:

1. “the fragment might sometimes get dropped…”: I believe this would
primarily be by code inside browsers that hasn't ever needed to pay
attention to the fragment when making security decisions. I'm not certain
that this code exists.
2. “some code might only be looking at the host”: Here I'm more worried
about server-side or Javascript code that receives this new kind of URL in
an Origin header or the 'event.sender' field of a postMessage(). If they
parse the URL but don't check the scheme, their bug might become more
exploitable with a fragment-based scheme.

I think the three advantages you mention aren't actually differences
between a fragment-based and an encoding-based scheme. Specifically:

A. It's straightforward to define that `package:bundle$content` looks up
the `content` part in a way that depends on the mime type of the `bundle`,
and I think we should do that no matter what URL format we pick. For PDF,
we could define that as a mapping to the existing fragment format.
B. Because the `bundle` and `content` parts of a `package:bundle$content`
URL are themselves encoded URLs, they can also be `package:` URLs, which
allows nested containers of any depth. The fragment format might win on
readability here, like it does for non-nested containers.
C. As
https://github.com/WICG/webpackage/blob/master/explainers/bundle-urls-and-origins.md#fragment-based-url-scheme
mentions, it looks difficult to say that `
https://distributor.example/package.wbn#url=content` uses different storage
than `https://distributor.example/index.html`. I think we'd need to
define `pkg+https://distributor.example/package.wbn#url=content` as you
suggested
<https://mailarchive.ietf.org/arch/msg/wpack/XkQ8OSlGn18xsVNtSXvoD7s0FIU/>
last month, at which point we need to deploy a new URL scheme anyway.

Jeffrey

On Wed, Jul 8, 2020 at 5:55 PM Larry Masinter <[email-masked]> wrote:

> I don’t understand the cases where this doesn’t meet the goal.
>
>
>
> “the fragment might sometimes get dropped…”  when? By what process?
>
> “some code might only be looking at the host” This is some existing code?
>    - being able to use other “kinds of things with subresources, like
>    zip, tar, 7z, etc. files”
>    gives you instant deployment  “ (including PDF)
>    - works with nested containers to any depth
>    - You don’t need to deploy a new URL scheme seem compelling
>
> --
>
> https://going-remote.info
>
>
> _______________________________________________
> Wpack mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/wpack
>