- From: <bugzilla@jessica.w3.org>
- Date: Thu, 05 Jun 2014 14:29:35 +0000
- To: public-webapps-bugzilla@w3.org
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