Updated suborigin serialization to latest spec proposal

content/common/url_schemes.cc

Index: content/common/url_schemes.cc
diff --git a/content/common/url_schemes.cc b/content/common/url_schemes.cc
index 96f487b2f04ed4fff7e89985ad827985967b7e93..253bfd32bbf931a298e7694d0ca1000e545a1a9e 100644
--- a/content/common/url_schemes.cc
+++ b/content/common/url_schemes.cc
@@ -35,6 +35,11 @@ void RegisterContentSchemes(bool lock_schemes) {
   url::AddStandardScheme(kChromeUIScheme, url::SCHEME_WITHOUT_PORT);
   url::AddStandardScheme(kGuestScheme, url::SCHEME_WITHOUT_PORT);
 
+  url::AddStandardScheme(kHttpSuboriginScheme, url::SCHEME_WITH_PORT);

[nasko, 2016/09/22 23:53:42]

What breaks if we don't add it as a standard scheme?

[jww, 2016/09/23 04:12:44]

This is more important for KURL parsing. I'll have to dig down to recall exactly
why, but KURL won't parse the URLs correctly if the scheme isn't "standard".

[jww, 2016/09/23 16:33:48]

Just digging a little further through my memory here, I believe that KURL will
only treat a URL as hierarchical if the scheme is listed as a standard scheme. I
believe there are a couple of other IsStandard checks as well, but that's the
one I was consistently running into.

[nasko, 2016/09/23 21:59:48]

Hmm, why would KURL depend on content/? This is very much backwards in terms of
layering. However, it is indeed the case because content/ populates url::'s view
of what is a standard scheme and KURL uses url:: ... Fun!

+  url::AddReferrerScheme(kHttpSuboriginScheme, url::SCHEME_WITH_PORT);
+  url::AddStandardScheme(kHttpsSuboriginScheme, url::SCHEME_WITH_PORT);
+  url::AddReferrerScheme(kHttpsSuboriginScheme, url::SCHEME_WITH_PORT);
+
   for (const url::SchemeWithType& scheme : additional_standard_schemes)
     url::AddStandardScheme(scheme.scheme, scheme.type);