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

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

From: <bugzilla@jessica.w3.org>
Date: Mon, 23 Jun 2014 18:38:39 +0000
To: public-webapps@w3.org
Message-ID: <bug-25914-2927-ynXdGvnzYx@http.www.w3.org/Bugs/Public/>

Arun <arun@mozilla.com> changed:

           What    |Removed                     |Added
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #29 from Arun <arun@mozilla.com> ---
(In reply to Anne from comment #28)
> Don't check for "parse error", see if the algorithm returns failure.


> Also, it may not return a host or port. You should probably check if it's a
> relative scheme.

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.

> I think you probably just want to parse it and then say something like
> "return /parsedURL/'s origin".


> But maybe I should just bite the bullet and define origin for all URL
> schemes we care about.

If you do this, some portions of this in File API might be made redundant.
We've already made the section on request-response informative; other sections
may follow suit.

Please give it a check: 

You are receiving this mail because:
You are on the CC list for the bug.
Received on Monday, 23 June 2014 18:38:42 UTC

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