Looking for a Uri Builder for non-standard schemes

[sk...@chromium.org]

I need to build uris with a non standard scheme (ipp).  The usage of this scheme should be limited to a small portion of Chromium.  I would like to use GURL but there seems to be a check to verify that the scheme is standard.  

[sk...@chromium.org]

Posted too soon.  GURL seems to verify schemes against this list: https://cs.chromium.org/chromium/src/url/url_util.cc?sq=package:chromium&dr=C&l=29

[Joe Mason]

Where are you seeing a verification failure? It looks to me like the constructors allow non-standard schemes. It ends up calling DoCanonicalize (https://cs.chromium.org/chromium/src/url/url_util.cc?l=200) which checks for file schemes, then the standard schemes you referenced, then mailto, then an else clause for ""Weird" URLs like data: and javascript:"

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/36cc3789-62f6-4ba8-8f70-c23190647b95%40chromium.org.

[Ryan Sleevi]

On Tue, Mar 13, 2018 at 1:54 PM, <sk...@chromium.org> wrote:

I need to build uris with a non standard scheme (ipp).  The usage of this scheme should be limited to a small portion of Chromium.  I would like to use GURL but there seems to be a check to verify that the scheme is standard.  

Can you clarify where it's documented as non-standard? RFC 3510 seems to adopt the Generic Scheme and Semantics of 2396 (obsoleted by 3986), which is generally what we're talking about with regarding to 'standard' schemes in GURL. 

[Joe Mason]

I assume "standard" means "one of the fixed list in kStandardURLSchemes". Maybe that constant should be renamed if "standard" has a different colloquial meaning?

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CACvaWvb%3DXfWEvpmhon-p8PC0sWvYzxo7ArzmvUtnN%2BCutin78Q%40mail.gmail.com.

[Ryan Sleevi]

I'm not sure I understand your response.

I'm trying to understand whether "non-standard" means "Not in the fixed list of kStandardURLSchemes (but can be)" - and we should canonicalize using the existing generic URL canonicalizer - or whether it means "Not following the standard for generic URLs (RFC 3986-et-al, but really, URL Standard these days)" - in which case, the existing logic of treating it opaquely.

[Joe Mason]

Yeah, I shouldn't speak for skau, I'll wait for them to clarify.

My main point is that if we rename kStandardURLSchemes we wouldn't need to ask this question in the future because there wouldn't be a confusingly overloaded term.

[Ryan Sleevi]

Right, but I don't think that renaming the variable would meaningfully address that question - it still remains, because if someone says "non-standard", it's going to be unclear whether they're talking about "not defined by some standard" or "not part of the usual experience". That's just a standard part of English ambiguity :)

[Joe Mason]

That's a third interpretation I hadn't even considered!

English is hard. Can we switch to Rust?

[sk...@chromium.org]

Sorry for the confusion, I should have been more specific.  The "ipp" scheme is registered with IANA https://www.iana.org/assignments/uri-schemes/uri-schemes.xhtml and specified by RFC3510.  However, it's not a uri which Chrome would typically be able to open.  Since the protocol is built on HTTP, all the rules of an HTTP uri will apply.

When I said "standard" I meant that it's not in the kStandardUrlSchemes array.  As a result, GURL parses the authority and port number as part of the path.  Though, it does seem to think that it's valid.

I have an example.

https://chromium-review.googlesource.com/676124

[Ryan Sleevi]

Actually, on looking through 3510/7472, ipp/ipps is not using the Generic URL syntax of STD66 or the URL Standard, because it explicitly wants to reject userinfo from its processing model (hence, doesn't use the authority).

With the current design of GURL, adding it to kStandardUrlSchemes (or to the GURL canonicalizer) would have the effect of making it web-visible via the URL object, which would have impact on https://url.spec.whatwg.org/#special-scheme and the browser representation captured in https://url.spec.whatwg.org/#url-representation

The general solution I've seen to this is bespoke URI parsers, such as the Android facet parser or ChromeOS printer config parser that build upon //url/third_party/mozilla/url_parse to extract each bit. This does not canonicalize URLs (thus wouldn't be suitable for equality testing) nor ensure consistent treatment, but does allow for feature extraction. You could further canonicalize by building up the url::Parsed representation to feed into the Standard URL canonicalizer - the IPP/IPPS schemes are 'close enough' that you'd be able to build a canonical GURL (since the handling is mostly around authority parsing and default ports). You can see this done by code like SafeBrowsing

The more extreme option would be to add it to the URL Standard, but it sounds like it's an explicit non-goal to have this be Web Visible.

[Sean Kau]

Thanks Ryan.  I actually own the ChromeOS printer configuration parser and was hoping for a less bespoke solution.  :(

Would there be support for a version of GURL that was extensible for my use case; allowing arbitrary schemes?  It seems that we now have two instances where leveraging a common library would be helpful and less error prone.

[Ryan Sleevi]

I'm not sure I understand. Both GURL and your code (and others) are built on a common library - the third-party Mozilla URL parser.

GURL is web visible substrate (exposed in a variety of places), built on a common parser, and with the canonicalization, normalization, and validation of the URL standard.

What do you see as the error prone part? You'd still need specific handling for ipp/ipps since they don't strictly adhere to the generic URL syntax - same as several of the other schemes (such as Android). You wouldn't want it web-exposed. Normalization/canonicalization for the ipp/ipps scheme is undefined.

[Sean Kau]

I would like the ReplaceComponents() functionality of GURL that would help to write sound urls.  But it looks like it's not too much code and I can just copy it from GURL as it looks like the functionality is actually in url_util.cc.

Basically, without a clear and convenient url builder, it's tempting to build urls in an undisciplined way (through string concatenation) and it would be nice to have a convenient wrapper.

[Harald Alvestrand]

Is there any reason not to add ipp: to kStandardUrlSchemes?

It's a standard, it's being used (or will be once this project lands its code), and it's so similar to HTTP that most utiliy functions will handle it painlessly.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAHKJWbD1L%2B0HaiiB5kCgYq8COYbX4-eNTUs5VxorbL2GAfXJSA%40mail.gmail.com.

[Ryan Sleevi]

That would cause it to be web exposed, which would require a change to the URL standard and cross-browser coordination - for example, the JS API for parsing URLs would behave differently across browsers for IPP[S] handling.

[Harald Alvestrand]

So the WHATWG URL standard doesn't work with the extensibility implicit in the IETF URL standard (which allows adding schemes)?

Lovely.

[Ryan Sleevi]

Well, to be fair, IPP/IPPS doesn't follow the generic URI model, so to 'correctly' parse an IPP URL, you'd need to have code to ensure that you parse host:port and not as authority. Similarly, you'd need to know default port for C14N and/or to expose it as part of the URL API.