Updated suborigin serialization to latest spec proposal

url/url_constants.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "url/url_constants.h"
 
 namespace url {
 
 const char kAboutBlankURL[] = "about:blank";
 
 const char kAboutScheme[] = "about";
 const char kBlobScheme[] = "blob";
 const char kContentScheme[] = "content";
 const char kContentIDScheme[] = "cid";
 const char kDataScheme[] = "data";
 const char kFileScheme[] = "file";
 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";
 const char kWssScheme[] = "wss";
 
 const char kStandardSchemeSeparator[] = "://";
 
 const size_t kMaxURLChars = 2 * 1024 * 1024;
 
 }  // namespace url