The idea is to make it easy for sites to access to public resources, instead of forcing them to proxy everything through their own servers like they do today. That's why it would have to be opt-out (via default restrictions, enterprise policy, origin policy, header, etc.).
-
-
for what sorts of public resources exactly? I assume you're not just talking about CDNs? is the intent to do things like "generate link previews in a messenger client-side"?
1 reply 0 retweets 0 likes -
No, by "public" I'm literally referring to anything that I could hit with an anonymous HTTP GET from a random host sitting outside of your network. That's the kind of stuff that people proxy all over the place today.
1 reply 0 retweets 1 like -
can you be more specific than "all over the place"? which proxying usecases do you want to replace? AFAIU some sites specifically use a proxy for privacy reasons, and for others (like messaging sites), letting the sending client generate the preview causes authenticity problems
2 replies 0 retweets 0 likes -
No one could claim that there's a magic wand to make all proxies disappear. But, the pattern I'm talking about is a very common practice for pulling in public data from a third-party origin.
1 reply 0 retweets 1 like -
can you give some examples of specific uses of this pattern that you'd want to replace?
1 reply 0 retweets 0 likes -
Replying to @tehjh @justinschuh and
I can't immediately come up with any examples where getting rid of the proxy wouldn't have some annoying side effects
1 reply 0 retweets 0 likes -
Replying to @tehjh @justinschuh and
image search by URL: you could let the client download the image and then upload it to the search engine, but especially with asymmetric down/up link speeds on customer internet connections, that might be much slower
1 reply 0 retweets 0 likes -
Replying to @tehjh @justinschuh and
image display in webmailers: the whole reason you use a proxy is to hide the client IP
2 replies 0 retweets 0 likes -
I think you misunderstand the use case, because neither example makes sense for this proposal. Try this: A podcast listening app. It reads RSS and caches audio files for use offline. Today all that routes through the app's server, even though it's handling public resources.
2 replies 0 retweets 3 likes
ah, that makes sense. (but can't you already cache the audio file as an opaque response with service workers, or something like that?)
-
-
Fair, but you still have to proxy the RSS feed, since CORS headers are pretty uncommon. Anyway, I was just using it as a contrived example since I'm literally listening to a podcast right now.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.