W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

Re: Blob URL Origin

From: Arun Ranganathan <arun@mozilla.com>
Date: Mon, 12 May 2014 11:57:02 -0400
Cc: Web Applications Working Group WG <public-webapps@w3.org>
Message-Id: <2CE66BC8-F365-48B2-8731-974EB44A6617@mozilla.com>
To: Boris Zbarsky <bzbarsky@MIT.EDU>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC