Re: [Wpack] package: URL scheme

[Ted Hardie <[e-mail]>]

Howdy,

On Thu, Jun 11, 2020 at 11:47 AM Jeffrey Yasskin <[e-mail]>
wrote:

> On Wed, Jun 10, 2020, 3:44 PM Ted Hardie <[e-mail]> wrote:
>
>> Hi Jeffrey,
>>
>> On Wed, Jun 10, 2020 at 3:00 PM Jeffrey Yasskin <jyasskin=
>> [e-mail]> wrote:
>>
>>> Hi all,
>>>
>>> I wanted to raise awareness of a discussion about the URL scheme for
>>> addressing resources within bundles (draft-yasskin-wpack-bundled-exchanges).
>>>
>>> We seem to be heading toward a URL of the form
>>> package:<encoded-package-url>$<encoded-resource-uri>, which for a package
>>> URL of https://distributor.example/package.wbn and resource URI of
>>> https://publisher.example/page.html?q=query would lead to a URL of:
>>>
>>>
>>> *package:https:,,distributor.example,package.wbn;q=query$https:,,publisher.example/page.html?q=query*
>>>
>>> RFC 3986, section 2.2 notes:
>>
>>    If data for a URI component would conflict with a reserved
>>    character's purpose as a delimiter, then the conflicting data must be
>>    percent-encoded before the URI is formed.
>>
>> Wouldn't that apply to a couple of the delimiters in the package example
>> above, e.g. the  ":" in "https:"?  If so, that seems like it would change
>> the display form a bit (though not the basic idea).  If that is needed, I
>> think it reinforces the notion that showing these to users or expecting the
>> users to grok them is a non-starter.
>>
>> regards,
>>
>> Ted Hardie
>>
>
> I looked at that, and I think it's ok to leave the `:` unescaped.
> Specifically, since `:` is only used as a delimiter to separate the scheme,
> the later `:`s in the package and resource URLs don't conflict. blob: URLs
> <https://w3c.github.io/FileAPI/#blob-url> already do this, and go a bit
> farther in leaving their `/`s unescaped too.
>

It's certainly the case that some schemes permit ":" after the scheme to be
presented unescaped (URNs require one, separating the NID from NSS).  My
concern here is really that these constructions, including the later ":"s ,
are actually being used in ways that might be read as conflicting with
their original purpose as delimiters.  "https:" occurs multiple times with
contextual cues on meaning, in essence.  That might be okay, but I think
the percent encoded version might match expected practice  bit better.
It's unreadable to the end user, but I think that true either way.

Is your concern with that approach that the origin-matching code might have
forgiving  algorithms for matching against percent-encoded elements of URIs?

regards,

Ted


>
> We could probably get away without escaping the `/`s here too: the
> origin-finding algorithm would split on `$` instead of looking for the
> first `/`, but I worry that it would be easier to write bugs in that case,
> which could give packaged resources access to their distributor's storage.
>




>
> Jeffrey
>