Comments (5)
@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:
- Register itself as a proxy by which all HTTP requests throughout the system are fed.
- 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.
Related Issues (20)
- What's the reason to remove web intents from web share besides security concerns HOT 2
- Add example of permission policy use with iframe HOT 2
- Promises cannot be manipulated while "in parallel"
- Call for Consensus: Publish as Candidate Recommendation HOT 1
- Explain implementation status
- "current settings object's relevant global object" is not defined
- Call for consensus: publish as a Proposed Recommendation HOT 1
- Is implemented HOT 4
- Indicate explicitly the intent of the Web Share API regarding cross-origin HOT 1
- Support additional media types? HOT 3
- Base isn't needed in main branch of algorithm HOT 2
- Wrong explanation in example
- Suggesting preview for security should mention accessibility HOT 1
- No explicit acknowledgements? HOT 2
- What's the scope of "abort these steps"? HOT 4
- Make Security Considerations an explicitly named section? HOT 2
- ios web share save file to camera roll only works once HOT 3
- CFC to publish Web Share as a W3C Recommendation HOT 3
- Prepare spec for REC
- “Save Image” missing from Share Sheet HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from web-share.