On Mon, Jul 1, 2013 at 6:58 PM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > Currently protocol handlers are extensible and so parsing is spread > throughout the tree. I expect that extensible protocol handling is a > non-goal, and that there are just a few kinds of URI parsing that we need to > support. Is it your plan to replace extensible parsing with a single > mechanism?
Yes. Basically all non-blessed schemes would end up with scheme, scheme data, query, and fragment components (blessed schemes would also have username, password, host, port, and path segments). Any further parsing would have to be done through scheme-specific processing and cannot cause URL parsing to fail. More concretely, data:blah would not fail the URL parser, but http://test:test/ would. The idea here is to provide consistency with regards to URL parsing as far as it's exposed to the web and to remain compatible with the current web. >> Idempotent: Currently Gecko's parser and the URL Standard's parser are >> not idempotent. E.g. http://@/mozilla.org/ becomes >> http:///mozilla.org/ which when parsed becomes http://mozilla.org/ >> which is somewhat bad for security. My plan is to change the URL >> Standard to fail parsing empty host names. I'll have to research if >> there's other cases that are not idempotent. > > I don't actually know what this means. Are you saying that > "http://@/mozilla.org/"; sometimes resolves to one URI and sometimes another? I'm saying that if you parse and serialize it and then parse it again, mozilla.org is suddenly the host rather than the path. Non-idempotency of the URL parser has caused security issues though I'm not really at liberty to discuss them here. >> File URLs: As far as I know in Gecko parsing file URLs is >> platform-specific so the URL object you get back will have >> platform-specific characteristics. In the URL Standard I tried to >> align parsing mostly with Windows, allowing interpretation of the file >> URL up to the platform. This means platform-specific badness is >> exposed, but is risky. > > Files are inherently platform-specific. What are the specific risks you are > trying to mitigate? I want the object you get out of new URL("file://C:/test") to be consistent across platforms. I don't want JavaScript APIs to become platform-specific, especially one as core as URL. (That the algorithm that uses the URL to retrieve the data uses a platform-specific code path is fine, that part is not observable.) I cannot really comment on adding thread safety other than that it seems good to have for the workers implementation. -- http://annevankesteren.nl/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
