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

Blob URL Origin

From: Arun Ranganathan <arun@mozilla.com>
Date: Fri, 9 May 2014 17:29:40 -0400
Message-Id: <4E3245D3-4F25-447E-A5FA-B0AC0E15C54C@mozilla.com>
Cc: Adam Barth <w3c@adambarth.com>, jonas <jonas@sicking.cc>, Anne Van Kesteren <annevk@annevk.nl>
To: Web Applications Working Group WG <public-webapps@w3.org>
This email is about the origin of a blob: URL, and corresponds to this specification bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=24998

1. Syntax on the web, present day.

This is what a blob:URL might look like in Safari:


Chrome does it like this:


Firefox and FxOS, like so:


You can see that Safari and Chrome *both* preface the UUID part of the scheme data with a string corresponding to the origin of the URL that coined the blob: URL; they differ on the matter of the ":" (U+003A COLON) character (either using %3A URL encoding or ď:Ē itself).

Only Firefox follows the letter of the present day specification correctly. But, all of these treat the origin of the blob: URL as the origin of the incumbent script settings object of the script which coined the blob: URL. In Firefox, however, you cannot deduce this from the URL alone; it is hidden and part of the context of the URL. 

So this is problematic: we donít have a common syntax on the web, and even implementations which share code donít do it exactly the same. Of course, blob: URLs arenít supposed to be human readable, or really viewed by the developer. But not having a good way to denote origin within the URL that signifies the origin of the incumbent settings object is problematic for Fetch and Parse specifications that need origin information.

Iíll also note that the filesystem URLs, used to access temporary or permanent filesystems on a per domain basis (works only in Chrome for now), look like this:
2. Syntax on the web, future day.
I think we should officialize the Safari version of the blob: URL, and apply some formal strictures around it. For instance, should we allow:
(or other variants of things)? Or leave those undefined?
I think we can safely spec. things for at least the lionís share of the use cases, but some edge cases will exist.
The origin policy might be that we maintain that the origin is that of the incumbent settings object, and denote this syntactically in the blob: URL, and that the origin of a resource identified by the blob: URL is of that origin, even in cross-origin cases like <img >. This should apply for various proliferating schemes; for instance, filesystem: and mediastream:, which havenít been formally defined yet.
Feedback / thoughts on this welcome, either on list or in the bug.
ó A*

Received on Friday, 9 May 2014 21:30:12 UTC

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