How to introduce a new experimental URL scheme?

[Yutaka Hirano]

Hi,

We are developing QuicTransport, and planning to add a new URL scheme. We are tentatively using "quic-transport", but that may change in the future.

Chromium URL (GURL and KURL) does not parse URLs with an unknown scheme. On the other hand, when we add a scheme (via SchemeRegistry::standard_schemes for example), that will be exposed to the Web - A web developer can detect that change with executing "new URL('quic-transport://foo.bar').host".

We think the current Chromium behavior is not spec conformant. For example. jsdom implementation parses a quic-transport: URL correctly, so we are not sure if we should worry  about this potential compatibility issue.

We would like to add "quic-transport" as a standard scheme. What do API owners think about this?

Alternatives considered:

- Add "quic-transport" as a standard scheme only when QuicTransport is enabled.

  This works now, but this won't work when we start an origin trial.

- Use "https" URLs as internal representation.

  This is too hacky I think.

Thanks,

[Ryan Sleevi]

On Wed, Nov 6, 2019 at 1:10 AM Yutaka Hirano <yhi...@chromium.org> wrote:

Hi,

We are developing QuicTransport, and planning to add a new URL scheme. We are tentatively using "quic-transport", but that may change in the future. 

Chromium URL (GURL and KURL) does not parse URLs with an unknown scheme. On the other hand, when we add a scheme (via SchemeRegistry::standard_schemes for example), that will be exposed to the Web - A web developer can detect that change with executing "new URL('quic-transport://foo.bar').host".

We think the current Chromium behavior is not spec conformant. For example. jsdom implementation parses a quic-transport: URL correctly, so we are not sure if we should worry  about this potential compatibility issue.

Correct. The Chromium GURL and KURL significantly diverges in parsing from what the spec requires. This is basically https://bugs.chromium.org/p/chromium/issues/detail?id=734880 where we've been dumping them.

 

We would like to add "quic-transport" as a standard scheme. What do API owners think about this?

If Chromium properly implemented the URL standard, as other UAs do, this would be a non-issue; that is, you would not have to explicitly add as a standard scheme.

So it seems like this should be fine, and the ideal way of doing this would be to align our parsing to be closer to the WHATWG spec ;)

[Domenic Denicola]

+1 to Ryan. IMO the web-detectable change here is more along the lines of a bugfix than anything else.

It'd be neat if we also fixed the general case (web devs have been pinging that bug a lot recently), but even then it'd feel more like a PSA than an intent-to-ship level change, in my opinion.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CACvaWvYFA5_4wmVQ1iG0bRa38T8n%3D50OOG1FfqdVz45MCJJydw%40mail.gmail.com.

[Yutaka Hirano]

Thank you! I'm going to add it to the standard scheme list.