Updated suborigin serialization to latest spec proposal

url/url_constants.cc

Index: url/url_constants.cc
diff --git a/url/url_constants.cc b/url/url_constants.cc
index 549819e97f3abdbe6ee24aac569c9b6387f2520e..2c89e4b2a5be06fb024a6a9577ff42b5d6eb39eb 100644
--- a/url/url_constants.cc
+++ b/url/url_constants.cc
@@ -18,7 +18,9 @@ const char kFileSystemScheme[] = "filesystem";
 const char kFtpScheme[] = "ftp";
 const char kGopherScheme[] = "gopher";
 const char kHttpScheme[] = "http";
+const char kHttpSuboriginScheme[] = "http-so";

[Mike West, 2016/09/13 18:00:18]

Perhaps not for this CL, but WDYT about locking suborigins to HTTPS and skipping
the plaintext serialization?

[jww, 2016/09/13 18:36:04]

I think that since they're purely restrictive, I don't necessarily see the
point; it seems like we'd be using suborigins as an HTTPS carrot without an
explicit reason. It's not too dissimilar from our end position on SRI, IMO.

In any case, I think we should have a separate discussion about it since I think
you and I have differing philosophies on limiting features to HTTPS :-)

 const char kHttpsScheme[] = "https";
+const char kHttpsSuboriginScheme[] = "https-so";
 const char kJavaScriptScheme[] = "javascript";
 const char kMailToScheme[] = "mailto";
 const char kWsScheme[] = "ws";