On 7/1/2013 12:43 PM, Anne van Kesteren wrote:
I'm interested in hearing what people think. I outlined two issues
below, but I'm sure there are more. By the way, independently of the
parser bit, we are proceeding with implementing the URL API as drafted
in the URL Standard in Gecko, which should make testing URL parsing
easier.
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?
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?
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?
--BDS
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
