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

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

--- Comment #14 from Arun <arun@mozilla.com> ---
(In reply to Glenn Maynard from comment #12)
> Oh, forgot about the nested-URL aspect of blob URLs now.  The scheme data
> (if I read correctly) of "blob:http://foo.com/1111-2222?data" is
> "http://foo.com/1111-2222".  Should the scheme data just be recursively
> parsed as a URL, so it can retrieve the origin of any nested scheme?


So yes in blob:http://example.org:8080/33107ee0-ecbd-11e3-ac10-0800200c9a66 the
scheme data is http://example.org:8080/33107ee0-ecbd-11e3-ac10-0800200c9a66 and
is also the identifier entered in the Blob URL Store.

It *could* be recursively parsed, but Blob URLs are just strings, and
recursively parsing the URL doesn't do anything useful (e.g., it isn't handed
off to Fetch).

So, origin extraction is currently defined as string manipulation. What follows
after the "/" is a UUID.


> 
> Speaking of which, the "blob:origin/UUID" encoding assumes that
> "origin/path" makes sense for every possible scheme that can be an origin
> for blob URLs.  Is that safe?  


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.


(In reply to Anne from comment #9)
> Yeah, you should define 2 as part of the blob URL definition. Would make
> sense.


It *is* defined as part of the Blob URL definition, which asks for a
Unicode-serialization of the origin of the incumbent settings object + "/" +
UUID, which is the scheme data, which identifies a Blob resource.

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

Received on Thursday, 5 June 2014 14:29:41 UTC