Re: [whatwg/url] Record whether the URL parser removed newlines. (#284)

I'm very sympathetic to @achristensen07's point of view conceptually, but I want to try to tease out the concrete objection.

My take is that it should be an editorial decision (as in, up to the editor) as to where this field is stored---as long as the observable consequences are the same. I strongly urge the editor to include a note similar to mine in https://github.com/whatwg/url/pull/284#issuecomment-303367119 (modified to talk about Fetch instead of HTML) so that people implementing this spec can understand that storing the flag inside the URL is a spec convenience, and they may want to make alternate implementation decisions (e.g. if they plan on flowing the URLs into places that are never Fetched).

However, what I am concerned about is whether we have cross-browser agreement on applying this mitigation, and particularly the scope of it, in terms of observable consequences. My understanding is that @achristensen07 "doesn't oppose" preventing the attack. But does that include preventing it for all other places URLs are parsed and then go through the Fetch spec, as the current set of patches do? His follow-up comment "I would iterate through the string that the HTML/SVG parser is about to feed into the URL parser" implies he might not be on board with the full scope of the currently-proposed mitigation, which includes, as I said, everywhere a URL is parsed and then fed to Fetch. My go-to example in this thread has been `new WebSocket()`, but it will also include `fetch()`, `XMLHttpRequest`, [payment method manifest fetching](https://w3c.github.io/payment-method-manifest/#fetch-pmm), etc. Not just fetches initiated by HTML tags.

So, @achristensen07 ---leaving editorial issues of how the spec is written aside (at least for now), what are your thoughts on the actual mitigation strategy proposed?

-- 
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-303999664