Intent to implement and ship: Disallow some invalid characters from URL host names

[Brett Wilson]

Contact email:

bre...@chromium.org

Spec:

https://url.spec.whatwg.org/

Bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=652808

Summary:

Stop supporting certain percent-escaped characters in host names. We currently do this in violation of the spec. This isn't a normal web platform launch, but I'm sending this to blink-dev due to possible compat risk.

Design doc:

https://docs.google.com/document/d/1KezMGpTwMJSYW3Jb9cvvi4fRuZ0r5AGbS-Phe-A6WeQ

[Chris Harrelson]

Hi Brett,

Do you have any data on how often these characters appear in URLs that Chrome attempts to load?

Chris

--
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+unsubscribe@chromium.org.

[Brett Wilson]

No, but it would be substantially less than the numbers in the document since most of the bad URLs are from places like unusual blogs. On top of that, most of the URLs with such characters in the hosts are typos on the source page, so knowing the frequency wouldn't tell us much anyway.

Brett

[Elliott Sprehn]

What do other browsers do? This is changing the web facing api which seems like it needs the usual Intent to Ship process.

[Brett Wilson]

On Tue, Oct 4, 2016 at 9:07 PM, Elliott Sprehn <esp...@chromium.org> wrote:

What do other browsers do? This is changing the web facing api which seems like it needs the usual Intent to Ship process.

This is discussed in the document.

 

Brett

[Elliott Sprehn]

You should put it in the email and use the standard Intent to Ship template. :)

 

 

Brett

[Philip Jägenstedt]

From the expected impact part of the doc and the analysis (using what dataset?) the risk here seems fairly low. For some things that already don't work in multiple other browsers the whole intents process is sometimes skipped, but changing how URLs work is scary, so thanks for the paperwork. On that note, can you turn crbug.com/652808 into an OWP launch bug and add a chromestatus.com entry?

Do you have any hunch about what proportion of page loads would have links that will stop working? I'm skeptical of a deprecation message for this as it might be very low signal:noise, but WDYT?

[PhistucK]

According to the document, the risk is limited to non-Windows and non-Android users. That means it is a significantly low risk (since those links are uncommon anyway and there are much less users on those platforms).

(Chrome does not support Windows Vista, XP, 2000 and earlier anyway, on which those links would have worked)

☆PhistucK

[Adam Rice]

Note in support: there is at least one web-platform-test that fails due to Chrome's behaviour here: http://w3c-test.org/websockets/constructor/002.html

I was planning to do a WebSocket-specific fix,but it would be nice if I didn't have to.

[Chris Harrelson]

LGTM1

Please make sure there is a chromestatus entry tracking this change. In the future, please also use the official Intent to Ship template; this makes it easier for us to monitor the intents.

Chris

[Rick Byers]

LGTM2

Thanks for getting our behavior closer to the URL spec - I know Anne will be happy about this.

[Philip Jägenstedt]

LGTM3

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Brett Wilson]

On Wed, Nov 9, 2016 at 10:18 AM, Chris Harrelson <chri...@chromium.org> wrote:

LGTM1

Please make sure there is a chromestatus entry tracking this change. In the future, please also use the official Intent to Ship template; this makes it easier for us to monitor the intents.

Done: https://www.chromestatus.com/feature/6059320944885760