Intent to Implement and Ship: URL protocol setter: New restrictions for file URLs

105 views
Skip to first unread message

Adam Rice

unread,
Feb 17, 2021, 8:55:49 AM2/17/21
to blink-dev

Contact emails

ri...@chromium.org

Explainer

None (minor interoperability fix)

Prior to this change:
  > url.href = 'http://localhost:8001';
  > url.protocol
  <- "http:"
  > url.protocol = "file";
  > url.href
  <- "file://localhost:8001/"
  > url.protocol
  <- ":"


After this change:
  > url.href = 'http://localhost:8001';
  > url.protocol
  <- "http:"
  > url.protocol = "file";
  > url.href
  <- "http://localhost:8001/"
  > url.protocol
  <- "http:"


Specification

https://url.spec.whatwg.org/#scheme-state

API spec

Yes

Summary

Aligns behavior with the standard in edge cases when changing the URL protocol to or from "file". Previously, attempting to change the protocol of a URL with credentials or a port to "file" would lead to an invalid URL. Similarly, attempting to change a URL with no host from "file" to "http" would lead to an invalid URL. Now the invalid change will be ignored for consistency with other browsers. This affects the "protocol" attribute on the URL API, location, and <a> and <area> elements.



Blink component

Blink>Network

TAG review

No TAG review as this is a trivial change to align with the standard.

TAG review status

Not applicable

Risks



Interoperability and Compatibility

The new restrictions only apply in cases where the URL would end up broken anyway, so compatibility risk is minimal. The old behavior was not interoperable. The new behavior is interoperable with Safari, and hopefully Firefox will also align.



Gecko: Worth prototyping (https://github.com/mozilla/standards-positions/issues/486)

WebKit: Shipped/Shipping (https://wpt.fyi/results/url/url-setters.html)

Web developers: No signals

Activation

Developers should avoid exercising these cases, as they don't do anything useful.



Security

Generally no security impact. If any web developers were depending on the old behavior for security purposes, their code was definitely broken in other engines and likely wasn't working as intended in Blink.



Debuggability

No special support needed.



Is this feature fully tested by web-platform-tests?

Yes

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5370811722498048

This intent message was generated by Chrome Platform Status.

Daniel Bratell

unread,
Feb 18, 2021, 2:48:31 PM2/18/21
to Adam Rice, blink-dev

LGTM1

/Daniel

--
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/CAC_ixdzwhzLbEG1ub-crgAGew3N6geDbS1sVG%2BEWi%2BQsDGfCBA%40mail.gmail.com.

Yoav Weiss

unread,
Feb 18, 2021, 3:54:34 PM2/18/21
to Daniel Bratell, Adam Rice, blink-dev

Mike West

unread,
Feb 23, 2021, 4:38:46 AM2/23/21
to blink-dev, yo...@yoav.ws, Adam Rice, blink-dev, Daniel Bratell
LGTM3.
Reply all
Reply to author
Forward
0 new messages