- From: Arun Ranganathan <arun@mozilla.com>
- Date: Mon, 12 May 2014 11:57:02 -0400
- To: Boris Zbarsky <bzbarsky@MIT.EDU>
- Cc: Web Applications Working Group WG <public-webapps@w3.org>
On May 12, 2014, at 10:31 AM, Boris Zbarsky <bzbarsky@MIT.EDU> wrote: > On 5/12/14, 5:28 AM, Anne van Kesteren wrote: >> so blob:https://origin:42/uuid would be fine. > > I'd really rather we didn't make web pages parse these strings to get the origin. A static method on Blob that takes a valid blob: URI and returns its origin seems like it should be pretty easy for UAs to implement, though. We actually aren’t obliging web pages parse these strings to get the origin. In fact, blob: URL strings shouldn’t even be of interest to web pages. They aren’t today, and I don’t envision them being of interest even with “origin tagging.” That is, I can’t think of why exactly a web developer would want to look into the blob: URL strings. UA’s should just “do the right thing” once a Blob URL is coined. The question is really whether origin should be implicit or explicit. Fx’s implementation makes it implicit. so that there’s no way to deduce origins from the Blob URL itself, but it just “does the right thing” in terms of origin strictures. That hasn’t been a problem, but it’s hard to spec. it that way. Also, it makes Blob URLs only usable within APIs that are aware of them, which honestly is the case today. So what if we tag origin into the strings? Would that be so bad? It’s not doing anything other than denoting the incumbent script setting object’s origin, no? Even in the Chrome/Safari cases, I can’t think of web developers using that information. — A*
Received on Monday, 12 May 2014 15:57:35 UTC