Offline support about web-share HOT 5 CLOSED

@terales using blob URL's sounds like a solid web platform capability to me, but by not sharing URLs you have no ability to meaningfully talk to 3rd parties about whatever it is you the target have been sent. That makes sharing blob URL dangerously anti-web in my view. I've commented more directly in #7. It's a good idea and would offer a direct path to better offline support, but I'd much rather see something that integrates well with the web and it's growing offline capabilities.

from web-share.

So to clarify what you're requesting: when a native app receives a shared URL, it then fetches the URL and that fetch gets proxied through the user agent's service worker (allowing for URLs to be fetched while offline)?

That sounds cool, but I think "pretty complicated" is an understatement. This isn't really a feature request of Web Share, but a feature request for operating systems. All of them would need to change their URL fetch mechanism to proxy through the browser, or provide a new API for doing so. I think that's quite outside the realm of possibility, and certainly outside of the scope of Web Share.

I agree with terales@; I think sending blob data instead of URLs is the offline story for Web Share. And I will respond to your objections on #7.

from web-share.

Sure, there are mechanisms for setting an application as a proxy in an operating system. Above all other concerns, this is absolutely outside of the scope of Web Share. You are essentially proposing a new web platform feature (or perhaps browser feature?), which is that a web browser should:

1. Register itself as a proxy by which all HTTP requests throughout the system are fed.
2. When an HTTP request comes in through the OS, pass that request through any matching service worker fetch handler.

Off the top of my head (without giving much serious consideration), here are some concerns with this proposal:

• Different operating systems have different proxy mechanisms. It's unclear whether all HTTP requests (from any app) would go through these proxies. What about apps that provide their own HTTP implementation on top of the TCP stack?
• Some operating systems would likely not allow arbitrary HTTP proxying.
• You don't set a proxy app, but a proxy server. Therefore, the browser would have to be running a TCP server on localhost to receive and proxy all HTTP requests from the system.
• The browser would have to assert itself as the HTTP proxy for the entire operating system. That raises security and privacy concerns (essentially by installing a browser it would automatically put some pretty deep hooks into the OS).
• Would the user be able to decline to install the browser as the proxy? This would break stuff depending on this feature.
• What would it mean if you have two browsers installed? Only one can be the proxy. What if you shared a URL (pointing at a URL accessible from your service worker) from one browser but the other browser is the system proxy?

This sounds like an incredibly complex solution in search of a problem (considering we can have offline support for Web Share by simply passing a blob object as I was originally intending).

from web-share.

Maybe for such scenario it's better to share image as Blob #7?

With such approach there is no need to change anything on the OS side, but only in the browser. Browser can execute request to get mime-type and if it's applicable then share binary content.

from web-share.

This isn't really a feature request of Web Share, but a feature request for operating systems. All of them would need to change their URL fetch mechanism to proxy through the browser, or provide a new API for doing so.

Whoa whoa, what??? No no no no. That sounds truly mad.

First off, there are established HTTP proxy protocols. The browser need only implement one of those.

Historically the HTTP_PROXY environment variable is all that's required to point most applications to a proxy! That could be set in the environment variables for any system wanting to use a proxy the browser provides. A browser could try to install this into the system envs if desired.

What the browser would have to provide is a proxy implementation that A) looks for the resource in foreign fetch Service Workers & tries to reply with those and B) passes all remaining requests through to the OS. This is non-trivial, but also doable.

This could perhaps even be implementable as a website + local proxy daemon on the device, without needing browser support at all. It'd be complex and scary devising some transport to funnel requests- a ServiceWorker using long running Fetch requests against a local proxy daemon, which funnels requests to the ServiceWorker who then runs a new Fetch for that requests & funnels it back down & out. Hopefully such antics need not be considered and this issue can be reopened here or in some other venue in the future. Maybe needs it's own WICG perhaps, and for this spec to perhaps maybe mention this.

from web-share.