Hi Eli, The implementation is not fully in line with the spec. Though hosts are not percent encoded by the browser. The browser will percent decode host strings. Thus 'test%22.com' is a valid host string. If all the browsers are spec compliant when parsing the hosts. I believe simply setting url.host and checking for errors will work. (This is not the case now)
Jiacheng Guo On Tue, Mar 14, 2023 at 3:05 PM Eli Grey <m...@eligrey.com> wrote: > I've updated my isValidHost() util to support this change. Could someone > please have another look and let me know if my implementation now aligns > well with the spec? > > > > On Monday, March 13, 2023 at 6:26:18 PM UTC-7 dom...@chromium.org wrote: > >> On Mon, Mar 13, 2023 at 6:46 PM Philip Jägenstedt <foo...@chromium.org> >> wrote: >> >>> To simplify and keep this moving, I've filed >>> https://github.com/mozilla/standards-positions/issues/759 as an >>> umbrella issue for anything URL in Interop 2023. >>> >>> My view is that we can't improve our risk assessment of this by much >>> with metrics, because we can't distinguish between harmless and serious >>> breakage. Instead what we should do is take some comfort in the fact that >>> the behavior is already shipping in Safari, try to ship it and revert at >>> the first sign of trouble to evaluate. In other words, I'll happily LGTM >>> this, but I'll send this round of feedback first, in case Yoav disagrees >>> with that. >>> >>> Some additional replies inline: >>> >>> On Mon, Mar 13, 2023 at 5:30 AM Yoav Weiss <yoav...@chromium.org> wrote: >>> >>>> Thanks for working on interop! :) >>>> >>> >>> Indeed, I'm very grateful and happy to see this work! >>> >>> Can you please explain what would be the impact of this change and >>>> provide examples of cases that are currently working and would stop working >>>> after this change is landed? >>>> Web developers are asking questions on this thread, and it'd be good to >>>> have an explainer that answers such questions. >>>> >>> >>> I've replied to Eli. >>> >>> More generally, since this is a change in the nitty gritty details, my >>> concrete advice for web developers would be to test what Safari currently >>> does and assume that's what Chrome is going to start doing. If one doesn't >>> have access to Safari, then https://www.browserstack.com/screenshots >>> can be used for one-off tests, as long as the test result appears on the >>> page. >>> >>> The other difference to Safari that's easy to test for is when >>> exceptions are thrown. `new URL('https://example|.com')` returns a URL >>> escaped as "https://example%7C.com"; in Chrome, but throws TypeError in >>> Safari. >>> >> >> Developers can also use the whatwg-url Node.js package >> <https://github.com/jsdom/whatwg-url>, including the live URL viewer >> <https://jsdom.github.io/whatwg-url/>. It is kept 1:1 with the URL >> Standard and so reflects the behavior that all browsers will be aiming >> toward as part of Interop 2023 (and that Safari is already compliant with). >> Examples: >> >> - Parsing https://example|.com >> >> <https://jsdom.github.io/whatwg-url/#url=aHR0cHM6Ly9leGFtcGxlfC5jb20=&base=YWJvdXQ6Ymxhbms=> >> - Testing Eli's isValidHost usage of the host setter >> <https://runkit.com/embed/lwn8l7w4yyj5> >> >> >> >>> >>> Do we have use counters for content that would start throwing once this >>>> change lands? >>>> >>> >>> I'll let Jiacheng answer, but if the answer is no, I'm skeptical that >>> adding use counters will meaningfully help us judge the risk of this. >>> Breaking it down: >>> >>> - Many invalid URLs already throw exceptions, which may be caught. >>> Knowing that new exceptions will be thrown in X% of page views will not >>> help know how often those are caught and the web app still behaves >>> correctly. >>> - Changes in serialization are akin to changing a return value. We >>> can't instrument the downstream effects of that and determine if the >>> difference led to a different outcome. >>> >>> Can you provide a link to the tests? >>>> >>> >>> >>> https://wpt.fyi/results/url?label=experimental&label=master&product=chrome&product=firefox&product=safari&aligned&view=interop&q=label%3Ainterop-2023-url >>> >>> There's no way to link to exactly the subtests that will be affected, >>> but "Parsing: <http://example example.com> against <http://other.com/>" >>> in url-constructor.any.html is one of them. >>> >>> Best regards, >>> Philip >>> >>> -- >>> >> You received this message because you are subscribed to the Google Groups >>> "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to blink-dev+...@chromium.org. >>> >> To view this discussion on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdKrtMS10VJxvzKntoXMBOEaA1doTYqpQ1W4%2BX1q40-bg%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYdKrtMS10VJxvzKntoXMBOEaA1doTYqpQ1W4%2BX1q40-bg%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1Ny1_d6OPsvR6ua9v8CqgZN90T6EzW%2BeSA1hdMqpxjYSsw%40mail.gmail.com.
