Re: [w3ctag/design-reviews] Web Share Target API (#221)

Hi David,

Thanks for the write-up. Sorry it's been awhile. I have been dealing with the URL escaping issue which is blocking the WST spec.

> * I'm slightly disturbed that WebAppManifest uses underscores in the names of the members of the dictionary... but this is at least consistent with that, which is better than being inconsistent. (I mean... I actually like underscores in general, but they haven't been popular in web APIs elsewhere.)

I think this is out of scope here (as you say, WST is consistent with the rest of the Manifest API). FWIW, this has caused some trouble already (we've talked about APIs that share the IDL dictionaries in the Manifest spec, and the issue came up that we would need to modify the IDL spec to automatically convert between underscore and camel-case because underscores would be unacceptable in JavaScript APIs). Well that never eventuated, but it is annoying. I think it's too late to not add underscores to Manifest members.

> * I've been wondering for a while about having something MIME-type specific, for example, to address things like the use case of calendar apps that want to receive text/calendar files (even those not coming from the Web Share API). See, for example, a recent discussion on mozilla.dev.platform about removal of navigator.registerContentHandler. That's perhaps broader than a general share/share target API, but I've thought it was something useful to solve. (Consider, for example, pages from those for WebEx conference calls to my dentist that offer ICS files (text/calendar) that I'd love to add to my google calendar from my browser.) It seems at least worth thinking about whether this API could be extended to handle that case, even if it doesn't happen right now.

Yes. I don't want this right now, but we need to make sure it can be extended into this. There's a proposal for Web Share to be able to [share blobs](https://github.com/WICG/web-share/issues/7). This has been a big feature request for WST also (mostly, receiving images). I think they would come in through the same mechanism; a Blob would be created in the document context containing the file, and then a new field would be added to the ShareData (and thus, come in as a URL parameter) referencing the Blob URL.

We can also filter by MIME type by adding new parameters to the share_target dictionary (which currently has just one field; it’s designed to be extended).

I think the existing WST proposal can be extended into this later.

> * a dummy parse using empty values (or nonempty alphabetic values) seems reasonable to me; I can't think of anything better offhand, though maybe @annevk has ideas

So @annevk and I have been talking on WICG/web-share-target#31 about parsing the template. It looks like we want to pre-parse the template at manifest parse time (resolving the relative URL before substituting template parameters), and that would address the above issue. The downside of this is it appears we need to change the syntax from "{text}" to "%(text)". I'm hesitant about this because of @plinss comment (I'll address below).

> * sites supporting this presumably need to be pretty careful even if the arbitrary data ends up in the query string. Limiting to being in the query string or the hash seems less than ideal, but allowing things like .. also seems less than great. (What are the rules on interpreting escaped /?) Imposing a particular URL structure seems less than ideal -- but on the other hand, you could think of it like form submission, which is where I suppose query strings came from in the first place. I suppose I can't make a particularly strong argument either way, but maybe others have thoughts.

The path is ... unfortunate, but it looks like we'll have to limit this to query and fragment only.

* The biggest concern is "." and ".." path segments, which would, at best, be lost or mis-interpreted, and at worst, represent a path escape.
* The second concern is an escaped '/'. We would automatically be escaping the '/' character as "%2F" (not possible for the sharer to inject a raw "/" into the path). So it depends on the URL processing. If a URL processor "properly" processes the path; splitting on raw '/'s and then decoding, then raw '/' characters in the share data will be correctly carried through to the target (not mis-interpreted as a path separator). But if the URL processor decodes the path before splitting on '/' (e.g., to look up in a real file system), then slashes in the share data will be interpreted as path separators. Basically, it depends on the share target implementation.

Processing a query string is pretty fool-proof. We will automatically escape '=' and '&' and any other reserved characters, so as long as the receiver processes the query by: 1. Splitting on '&', 2. Splitting those parameters on '=' to a key,value pair, 3. Decoding percent-escapes... then any arbitrary string can be handled correctly. As you say, this is the same as a form submission, so all web sites need to be able to handle this.

> * the spec probably should describe the escaping of data that implementations do when substituting into the placeholders in the url_template; it doesn't currently appear to describe this.

It does: see Step 1.7 of the [replace placeholders](https://wicg.github.io/web-share-target/#dfn-replace-placeholders) algorithm: "Replace each character of value, c, with the result of UTF-8 percent encoding c using the userinfo percent-encode set."

However, I've recently discovered that this is wrong. The userinfo percent-encode set doesn't encode nearly enough characters (notably '&' and '+'). I've been looking into exactly how to define this properly for the past week in whatwg/url#369. It's complicated, but I basically want to define it as "the complement of the unreserved set from [RFC 2896](https://tools.ietf.org/html/rfc2396)". (That is, the same algorithm as `encodeURIComponent`.) We're just figuring out how to write that out in web spec language (since we use URL Standard, not RFCs).

> Maybe a bigger issue here is thinking about what the path forward for better integration with both newer (mobile-focused) operating systems and older desktop-focused operating systems is. On desktop operating systems, there's often a mechanism for registration and handling of file MIME types, but registerContentHandler never took off. (On the other hand, registerProtocolHandler did, to match the parallel systems for protocol handling, which have sometimes been abused substantially to do things that aren't really protocols.) Is it the right mechanism, or as Anne suggests above, not? (Maybe it's right for native→web but doesn't work well for web→web?)

It’s harder on a system without a native intent system. There are a couple of answers (unfortunately some of these overlap with one another):

- Some desktop platforms do have a native share system. Both macOS and Windows do, to a certain degree. A user agent could potentially hook into those native share systems.
- Opening *files* (MIME types) doesn’t really make sense for the current standard. As described above, we could extend the share_target field, allowing a MIME type filter and file uploads. A UA could automatically register a share target accepting a MIME type as an operating system file handler. This would allow local files to be “opened” in the web app, but not edited and saved back to the disk. I’d love to tackle that at some point (perhaps as an extension to WST?) FYI this was the goal of the original research project that led to Web Share, [Ballista](https://github.com/chromium/ballista). We’ve deliberately reduced the scope of that project to one-way sharing.
- Failing that, web to web sharing should work on any browser on any platform (with navigator.share). If we extend these specs with blob / MIME type sharing, you should still be able to do that web to web.

> Oh, and a final comment related to registries: it seems like there ought to be a master list somewhere of the extensions to WebAppManifest (and, for that matter, other uses of WebIDL partial) so that we don't end up with conflicting ones. (That's particularly interesting in this case given our discussion about preserving the ability for the origin policy and the web app manifest being the same file.) That's sort of the risk of partial... but eventually shouldn't these extensions get rolled back into the original spec so people can keep track of them?

I think we can avoid this by simply standardizing this into the Web App Manifest spec. At the moment, it makes sense for it to be its own separate spec, but if we do put this on a standards track, I would expect it to be merged into that spec, so we don’t need to keep track of a list of extensions.

> @plinss:
> There's also already a standard syntax for URL templates: https://tools.ietf.org/html/rfc6570 (with several npm module implementations) suggest we re-use that rather than reinventing the wheel there.

Yikes! I wasn’t aware of this. It certainly looks relevant (just “Level 1” specifically). And coincidentally, it’s the exact syntax we settled on *before* the proposed syntax change in WICG/web-share-target#31. There’s just one problem: we reference the URL Standard, not RFC 3986, for our definition of a URL and URL processing. (This seems to be true of all new web standards.) I don’t see how to reconcile RFC 6570 with URL Standard.

Aside from URL Standard compatibility, there are a few other problems with this:

- The same problem we have with WICG/web-share-target#25 --- that we can’t *resolve* the URL template against the Manifest URL *before* substituting parameters. RFC 6570 doesn’t define an algorithm for resolving a URL template. In fact, it explicitly states: “A [relative] template is expanded before the resulting reference is resolved from relative to absolute form.” We want to be able to resolve the template at manifest parse time, before we have values for expansion.
- There doesn’t appear to be a way to limit expressions to just the query and fragment sections in this template syntax. For reasons discussed in WICG/web-share-target#30, we want to limit these from appearing in the path.
- We only want “Level 1” of this standard. Obviously an implementation could just implement Level 1 without the rest, but it’s a little strange depending on such a complex spec when we only need a small sliver of its functionality.

Still, this gives me renewed interest in keeping the `“{text}”` syntax instead of changing to `”%(text)”`, for compatibility with RFC 6570. I will discuss on WICG/web-share-target#31.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/221#issuecomment-360029367