- From: Mike West <notifications@github.com>
- Date: Wed, 24 May 2017 12:47:19 -0700
- To: whatwg/url <url@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/url/pull/284/c303831622@github.com>
> I think since this is trying to prevent an HTML parsing attack, it belongs in the HTML spec. I oppose to putting this in the URL spec. Strings in HTML are such a small subset of the uses of URLs. > > Note: I don't oppose to preventing the attack. If I were to implement the attack prevention, I would iterate through the string that the HTML/SVG parser is about to feed into the URL parser and search for this one attack in that one place. I think the spec could be more similar to that, and if we want to instead put concepts here then they should not change the behavior of all URL parsing or require more memory for all URLs. I'm sympathetic to this, but if WebKit implemented something along these lines, wouldn't y'all do it in the URL parser? I don't think Blink would accept running through the string again. In fact, I know we wouldn't, because my first pass at adding metrics for this did three string scans when completing URLs, caused a ~30% drop in parsing performance on Android and triggered exciting alerts in my inbox (https://bugs.chromium.org/p/chromium/issues/detail?id=682300). :) Given that it makes sense for the implementation to live in the URL parser, defining it there seems to also make sense. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/url/pull/284#issuecomment-303831622
Received on Wednesday, 24 May 2017 19:48:27 UTC