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

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

--- Comment #31 from Arun <arun@mozilla.com> ---
(In reply to Anne from comment #30)
> (In reply to Arun from comment #29)
> > It's true that it could be a relative scheme, so I check for a relative
> > scheme per your advice. But, it will never be a relative URL; that is, the
> > recursive invocation of the basic URL parser will never also be fed a base
> > URL. So, host will always be extractable, since the emitter methods
> > (URL.createFor and URL.createObjectURL) will always emit a full origin
> > string, namely the effective script origin specified by the settings object.
> 
> This is not true, e.g.
> 
> blob:data:test
> 
> would not have a host when recursively parsed.


True; outside of http and https URLs, which are always going to have a host
based on how the emitting methods work, this won't be an issue. In Chrome I can
generate Blob URLs of the sort:
blob:chrome://newtab/d1cec0be-a757-4a91-923c-9be1f7fb8ff4 which will be an
issue. These aren't defined for use here.


> Anyway, of the algorithm you have now step 3 could be removed and then it
> seems fine. I'll look into defining the origin of URLs in the URL Standard.


Done!

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

Received on Wednesday, 25 June 2014 19:15:12 UTC