[Bug 25914] No definition of parsing blob's scheme data

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25914

--- Comment #16 from Arun <arun@mozilla.com> ---
(In reply to Glenn Maynard from comment #15)
> (In reply to Arun from comment #14)
> > So, origin extraction is currently defined as string manipulation. What
> > follows after the "/" is a UUID.
> 
> > Well, the file scheme, along with user-agent proprietary schemes like
> > chrome, are not defined. In fact, the spec. restricts us to what the Web
> > Origin specification (http://tools.ietf.org/html/rfc6454) defines as an
> > origin.
> 
> Pulling it out as a string is fine, I think, but don't define it in a way
> that fails if the origin contains a slash.  Find the *last* "/" in the URL
> and strip off everything after it.  For example,
> blob:file://home/glenn/test.html/10d88a40-b6b1-45ec-8aba-a626037613a0 would
> parse out "file://home/glenn/test.html" and not "file://home".


Slash-containing origins are really only in the file scheme arena, and right
now the spec. disallows them, which I think is right.

> 
> This doesn't actually matter for file URLs, since browsers don't expose the
> origin for file URLs in the first place (for privacy reasons, I assume), but
> it helps ensure that this will work for all future and unknown schemes that
> blob URLs might be used in.
> 
> (Actually, file URLs are a bit broken with blob URLs in Chrome: it results
> in a URL like "blob:null/uuid".  Firefox's current blob URLs don't have this
> problem, since they don't include the origin.)


This might be right, actually. If the origin of the incumbent settings object
returns a null when parsing for tuples in the Unicode Serialization of an
Origin algorithm, the Unicode Serialization of a Blob algorithm allows
implementations to write out an implementation defined value. It could be null,
or something else. 

But file scheme use is disallowed.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 5 June 2014 16:55:35 UTC