Updated suborigin serialization to latest spec proposal

Updated suborigin serialization to latest spec proposal

This modifiest the serialization format of suborigins so they are now
represented in the form https-so://suboriginname.host.name (or,
alternatively, with the scheme http-so). This change removes collisions
with potentially valid URLs that were being deserialized as suborigins.

Additionally, this adds suborigins back as an experimental web platform
feature rather than a testing feature.

BUG=336894
R=mkwst@chromium.org

Committed: https://crrev.com/2cdad9ef3161ee39783c8e62e180da82797bfa78
Cr-Commit-Position: refs/heads/master@{#420828}

[jww, 2016-09-13 05:03:43]

Hey Mike, given the serialization update in
https://github.com/w3c/webappsec-suborigins/pull/45, can you review this change?
Thanks!

[Mike West, 2016-09-13 18:00:19]

Thanks, Joel!

https://codereview.chromium.org/2332263002/diff/1/content/browser/child_proce...
File content/browser/child_process_security_policy_unittest.cc (right):

https://codereview.chromium.org/2332263002/diff/1/content/browser/child_proce...
content/browser/child_process_security_policy_unittest.cc:123:
EXPECT_TRUE(p->IsWebSafeScheme(url::kHttpSecureScheme));
s/SecureScheme/SuboriginScheme/?

https://codereview.chromium.org/2332263002/diff/1/content/browser/child_proce...
content/browser/child_process_security_policy_unittest.cc:125:
EXPECT_TRUE(p->IsWebSafeScheme(url::kHttpsSecureScheme));
Ditto.

https://codereview.chromium.org/2332263002/diff/1/url/url_constants.cc
File url/url_constants.cc (right):

https://codereview.chromium.org/2332263002/diff/1/url/url_constants.cc#newcode21
url/url_constants.cc:21: const char kHttpSuboriginScheme[] = "http-so";
Perhaps not for this CL, but WDYT about locking suborigins to HTTPS and skipping
the plaintext serialization?

https://codereview.chromium.org/2332263002/diff/1/url/url_constants.h
File url/url_constants.h (right):

https://codereview.chromium.org/2332263002/diff/1/url/url_constants.h#newcode29
url/url_constants.h:29: URL_EXPORT extern const char kHttpsSuboriginScheme[];
I don't think it's a good idea to let these live in //url. They're a platform
concept, and could instead be injected by //content (see
//content/common/url_schemes.cc, for example).

[jww, 2016-09-13 18:36:05]

https://codereview.chromium.org/2332263002/diff/1/content/browser/child_proce...
File content/browser/child_process_security_policy_unittest.cc (right):

https://codereview.chromium.org/2332263002/diff/1/content/browser/child_proce...
content/browser/child_process_security_policy_unittest.cc:123:
EXPECT_TRUE(p->IsWebSafeScheme(url::kHttpSecureScheme));
On 2016/09/13 18:00:18, Mike West wrote:
> s/SecureScheme/SuboriginScheme/?

Yikes. I thought I complied this test, but I guess not?. Fixed.

https://codereview.chromium.org/2332263002/diff/1/content/browser/child_proce...
content/browser/child_process_security_policy_unittest.cc:125:
EXPECT_TRUE(p->IsWebSafeScheme(url::kHttpsSecureScheme));
On 2016/09/13 18:00:18, Mike West wrote:
> Ditto.

Done.

https://codereview.chromium.org/2332263002/diff/1/url/url_constants.cc
File url/url_constants.cc (right):

https://codereview.chromium.org/2332263002/diff/1/url/url_constants.cc#newcode21
url/url_constants.cc:21: const char kHttpSuboriginScheme[] = "http-so";
On 2016/09/13 18:00:18, Mike West wrote:
> Perhaps not for this CL, but WDYT about locking suborigins to HTTPS and
skipping
> the plaintext serialization?

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 :-)

https://codereview.chromium.org/2332263002/diff/1/url/url_constants.h
File url/url_constants.h (right):

https://codereview.chromium.org/2332263002/diff/1/url/url_constants.h#newcode29
url/url_constants.h:29: URL_EXPORT extern const char kHttpsSuboriginScheme[];
On 2016/09/13 18:00:18, Mike West wrote:
> I don't think it's a good idea to let these live in //url. They're a platform
> concept, and could instead be injected by //content (see
> //content/common/url_schemes.cc, for example).

Aren't blob:, javascript:, and filesystem also platform concepts? That having
been said, I suppose it keeps things cleaner, especially since it's not
explicitly used inside of GURL, so I updated it to register it through content.
I spoke to sleevi about this a few days ago, though, and it does seem like
there's some future where it would be useful and good to explicitly teach GURL
about suborigins (but that day is not today).

[Mike West, 2016-09-14 12:51:21]

LGTM.

Let's argue about HTTPS in some other venue. :)

[Mike West, 2016-09-14 12:51:26]

The CQ bit was checked by mkwst@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-14 12:51:37]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-14 13:06:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-14 13:06:10]

Dry run: Try jobs failed on following builders:
  android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[jww, 2016-09-14 17:08:57]

nasko@, since you're taking a look at my other suborigin CL, would you mind
reviewing content/ here?

[jww, 2016-09-14 17:09:37]

jww@chromium.org changed reviewers:
+ nasko@chromium.org

[jww, 2016-09-14 17:09:38]

nasko@, since you're taking a look at my other suborigin CL, would you mind
reviewing content/ here?

[nasko, 2016-09-19 22:20:21]

Apologies about the delay.

https://codereview.chromium.org/2332263002/diff/60001/content/browser/child_p...
File content/browser/child_process_security_policy_impl.cc (right):

https://codereview.chromium.org/2332263002/diff/60001/content/browser/child_p...
content/browser/child_process_security_policy_impl.cc:300:
RegisterWebSafeScheme(kHttpSuboriginScheme);
Why not put those in url:: namespace?

https://codereview.chromium.org/2332263002/diff/60001/content/browser/child_p...
content/browser/child_process_security_policy_impl.cc:302:
RegisterWebSafeScheme(kHttpsSuboriginScheme);
Registering these here is a bit dangerous, as it will lead us to allow
committing of suborigin URLs, which I don't think we can. Can we?

Why not register it as a PseudoScheme? I think it matches more closely the
semantics of suborigins.

https://codereview.chromium.org/2332263002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp (right):

https://codereview.chromium.org/2332263002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp:488: newProtocol
= oldProtocol.substring(0, protocolEnd);
Should we verify that the newProtocol is a valid registered protocol? What if I
managed to hit this method with "http-so-so"?

https://codereview.chromium.org/2332263002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/weborigin/SecurityOriginTest.cpp
(right):

https://codereview.chromium.org/2332263002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/weborigin/SecurityOriginTest.cpp:267: }
What about "http-so-so://foobar.test.com"?

[jww, 2016-09-20 00:24:32]

Thanks, nasko. I've inlined a response and question about treating it as a
PseudoScheme vs WebSafe. Let me know what you think!

https://codereview.chromium.org/2332263002/diff/60001/content/browser/child_p...
File content/browser/child_process_security_policy_impl.cc (right):

https://codereview.chromium.org/2332263002/diff/60001/content/browser/child_p...
content/browser/child_process_security_policy_impl.cc:300:
RegisterWebSafeScheme(kHttpSuboriginScheme);
On 2016/09/19 22:20:21, nasko (slow) wrote:
> Why not put those in url:: namespace?

See earlier comments from Mike. Mike prefers them as content-level definitions,
rather than in GURL, since he feels that they're a content-level concept (hence
they're defined in content/public/common/url_constants.h). This has the nice-ish
effect that users of cronet (sp?) don't have to ever see suborigins, at least
for now.

https://codereview.chromium.org/2332263002/diff/60001/content/browser/child_p...
content/browser/child_process_security_policy_impl.cc:302:
RegisterWebSafeScheme(kHttpsSuboriginScheme);
On 2016/09/19 22:20:21, nasko (slow) wrote:
> Registering these here is a bit dangerous, as it will lead us to allow
> committing of suborigin URLs, which I don't think we can. Can we?
> 
> Why not register it as a PseudoScheme? I think it matches more closely the
> semantics of suborigins.

That is what I did initially. The trick I ran into is when the renderer requests
resources. When the resource request is made, the resource dispatcher checks the
Origin header of the request (specifically at
https://cs.chromium.org/chromium/src/content/browser/loader/resource_dispatch...)
to see if it's a "valid" origin header. However, at this point, the Origin
header, per the pec, is serialized with the suborigin, , and part of what makes
it "valid" is if CanCommitURL passes (which requires a WebSafeScheme). Thus
simple resource requests kill the renderer if they're coming from a suborigin.

So maybe this needs to change? But my intuition is that this is, in a sense,
commitable, since a renderer has this effective origin for making requests. What
do you think?

https://codereview.chromium.org/2332263002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp (right):

https://codereview.chromium.org/2332263002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/weborigin/SecurityOrigin.cpp:488: newProtocol
= oldProtocol.substring(0, protocolEnd);
On 2016/09/19 22:20:21, nasko (slow) wrote:
> Should we verify that the newProtocol is a valid registered protocol? What if
I
> managed to hit this method with "http-so-so"?

I think we should only deserialize if it's https-so or http-so, and in other
cases we should return false and throw our hands up. Since KURL doesn't
generally check for valid protocols on creation, I think the appropriate thing
is simply to not deserialize as a suborigin, and to instead leave it to the
caller to decide what to do with the protocol.

https://codereview.chromium.org/2332263002/diff/60001/third_party/WebKit/Sour...
File third_party/WebKit/Source/platform/weborigin/SecurityOriginTest.cpp
(right):

https://codereview.chromium.org/2332263002/diff/60001/third_party/WebKit/Sour...
third_party/WebKit/Source/platform/weborigin/SecurityOriginTest.cpp:267: }
On 2016/09/19 22:20:21, nasko (slow) wrote:
> What about "http-so-so://foobar.test.com"?

Test added to reject.

[jww, 2016-09-22 18:58:39]

nasko@, can you take another look? I've converted the suborigin schemes to
pseudo schemes and added a "CanSetAsOriginHeader" check to
ChildProcessSecurityPolicyImpl.

[nasko, 2016-09-22 23:53:43]

I'll take a deeper dive tomorrow, but wanted to send a couple of high level
questions.

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
File content/browser/child_process_security_policy_impl.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_impl.cc:311:
RegisterPseudoScheme(kHttpSuboriginScheme);
I'll poke at this tomorrow, but now that we have a special method to check for
valid origin header, do we need it to be registered at all here?

https://codereview.chromium.org/2332263002/diff/100001/content/common/url_sch...
File content/common/url_schemes.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/common/url_sch...
content/common/url_schemes.cc:38: url::AddStandardScheme(kHttpSuboriginScheme,
url::SCHEME_WITH_PORT);
What breaks if we don't add it as a standard scheme?

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

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
File content/browser/child_process_security_policy_impl.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_impl.cc:311:
RegisterPseudoScheme(kHttpSuboriginScheme);
On 2016/09/22 23:53:42, nasko (slow) wrote:
> I'll poke at this tomorrow, but now that we have a special method to check for
> valid origin header, do we need it to be registered at all here?

Fair question. My impression was that all schemes that are "used" by Chrome, but
are not web-safe, are registered as pseudo-schemes. That is, looking at the
comment before pseduo_schemes_ in child_process_security_policy_impl.h:

// These schemes do not actually represent retrievable URLs.  For example,
// the the URLs in the "about" scheme are aliases to other URLs.  This set is
// protected by |lock_|.

Which, to me, sounds like suborigin schemes.

https://codereview.chromium.org/2332263002/diff/100001/content/common/url_sch...
File content/common/url_schemes.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/common/url_sch...
content/common/url_schemes.cc:38: url::AddStandardScheme(kHttpSuboriginScheme,
url::SCHEME_WITH_PORT);
On 2016/09/22 23:53:42, nasko (slow) wrote:
> What breaks if we don't add it as a standard scheme?

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]

https://codereview.chromium.org/2332263002/diff/100001/content/common/url_sch...
File content/common/url_schemes.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/common/url_sch...
content/common/url_schemes.cc:38: url::AddStandardScheme(kHttpSuboriginScheme,
url::SCHEME_WITH_PORT);
On 2016/09/23 04:12:44, jww wrote:
> On 2016/09/22 23:53:42, nasko (slow) wrote:
> > What breaks if we don't add it as a standard scheme?
> 
> 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".

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]

Thanks for sticking through the scrutiny I've put on your work. I just want to
make sure we have done our due diligence on thinking through all of the cases we
can. Few nits and tests and this will be ready to go.

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
File content/browser/child_process_security_policy_impl.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_impl.cc:311:
RegisterPseudoScheme(kHttpSuboriginScheme);
On 2016/09/23 04:12:44, jww wrote:
> On 2016/09/22 23:53:42, nasko (slow) wrote:
> > I'll poke at this tomorrow, but now that we have a special method to check
for
> > valid origin header, do we need it to be registered at all here?
> 
> Fair question. My impression was that all schemes that are "used" by Chrome,
but
> are not web-safe, are registered as pseudo-schemes. That is, looking at the
> comment before pseduo_schemes_ in child_process_security_policy_impl.h:
> 
> // These schemes do not actually represent retrievable URLs.  For example,
> // the the URLs in the "about" scheme are aliases to other URLs.  This set is
> // protected by |lock_|.
> 
> Which, to me, sounds like suborigin schemes.

Yeah, I poked around a bit and indeed it is a good idea to add it to the
PseudoScheme set.

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_impl.cc:628: if
(IsPseudoScheme(url.scheme()) && (url.scheme() == kHttpSuboriginScheme ||
You technically don't need the IsPseudoScheme check here, as it is guaranteed to
return true given we added it in the constructor. Maybe just DCHECK inside the
if statement body that it returns true for either of those two.

Also, multiline if statements should use {}.

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
File content/browser/child_process_security_policy_unittest.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_unittest.cc:198:
EXPECT_FALSE(p->CanSetAsOriginHeader(kRendererID, GURL("chrome://foo/bar")));
Hmm, do we really want to leak chrome:// origins to the web?

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_unittest.cc:290: // Suborigin URLs
are not requestable or commitable.
nit: committable?

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_unittest.cc:305: 
Let's add coverage to ensure that even after calling GrantRequestURL with a
suborigin we still cannot request/commit it.

https://codereview.chromium.org/2332263002/diff/100001/content/common/url_sch...
File content/common/url_schemes.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/common/url_sch...
content/common/url_schemes.cc:38: url::AddStandardScheme(kHttpSuboriginScheme,
url::SCHEME_WITH_PORT);
On 2016/09/23 04:12:44, jww wrote:
> On 2016/09/22 23:53:42, nasko (slow) wrote:
> > What breaks if we don't add it as a standard scheme?
> 
> 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".

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!

[jww, 2016-09-23 22:52:27]

Thanks, nasko@. I left you one question. Let me know how things look.

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
File content/browser/child_process_security_policy_impl.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_impl.cc:628: if
(IsPseudoScheme(url.scheme()) && (url.scheme() == kHttpSuboriginScheme ||
On 2016/09/23 21:59:47, nasko (slow) wrote:
> You technically don't need the IsPseudoScheme check here, as it is guaranteed
to
> return true given we added it in the constructor. Maybe just DCHECK inside the
> if statement body that it returns true for either of those two.
> 
> Also, multiline if statements should use {}.

Done.

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
File content/browser/child_process_security_policy_unittest.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_unittest.cc:198:
EXPECT_FALSE(p->CanSetAsOriginHeader(kRendererID, GURL("chrome://foo/bar")));
On 2016/09/23 21:59:48, nasko (slow) wrote:
> Hmm, do we really want to leak chrome:// origins to the web?

Well, we already are :-) chrome:// headers already return true for CanCommitURL,
so the header can be sent for them. I think it's certainly worth considering
locking it down, but I fear that they're might be unexpected consequences, so
I'd rather not tie that chance to this CL.

What do you think?

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_unittest.cc:290: // Suborigin URLs
are not requestable or commitable.
On 2016/09/23 21:59:48, nasko (slow) wrote:
> nit: committable?

Done.

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_unittest.cc:305: 
On 2016/09/23 21:59:48, nasko (slow) wrote:
> Let's add coverage to ensure that even after calling GrantRequestURL with a
> suborigin we still cannot request/commit it.

Done.

[jww, 2016-09-23 22:52:38]

The CQ bit was checked by jww@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-09-23 22:53:04]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[nasko, 2016-09-23 23:29:43]

LGTM!

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
File content/browser/child_process_security_policy_unittest.cc (right):

https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
content/browser/child_process_security_policy_unittest.cc:198:
EXPECT_FALSE(p->CanSetAsOriginHeader(kRendererID, GURL("chrome://foo/bar")));
On 2016/09/23 22:52:27, jww wrote:
> On 2016/09/23 21:59:48, nasko (slow) wrote:
> > Hmm, do we really want to leak chrome:// origins to the web?
> 
> Well, we already are :-) chrome:// headers already return true for
CanCommitURL,
> so the header can be sent for them. I think it's certainly worth considering
> locking it down, but I fear that they're might be unexpected consequences, so
> I'd rather not tie that chance to this CL.
> 
> What do you think?

Definitely the job for another CL. We shouldn't be putting different fixes in
the same CL.
Can you file a bug, if one doesn't exist, so we can follow up on this?

[commit-bot: I haz the power, 2016-09-24 00:13:39]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-24 00:13:40]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[jww, 2016-09-24 00:27:27]

On 2016/09/23 23:29:43, nasko (slow) wrote:
> LGTM!
> 
>
https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
> File content/browser/child_process_security_policy_unittest.cc (right):
> 
>
https://codereview.chromium.org/2332263002/diff/100001/content/browser/child_...
> content/browser/child_process_security_policy_unittest.cc:198:
> EXPECT_FALSE(p->CanSetAsOriginHeader(kRendererID, GURL("chrome://foo/bar")));
> On 2016/09/23 22:52:27, jww wrote:
> > On 2016/09/23 21:59:48, nasko (slow) wrote:
> > > Hmm, do we really want to leak chrome:// origins to the web?
> > 
> > Well, we already are :-) chrome:// headers already return true for
> CanCommitURL,
> > so the header can be sent for them. I think it's certainly worth considering
> > locking it down, but I fear that they're might be unexpected consequences,
so
> > I'd rather not tie that chance to this CL.
> > 
> > What do you think?
> 
> Definitely the job for another CL. We shouldn't be putting different fixes in
> the same CL.
> Can you file a bug, if one doesn't exist, so we can follow up on this?
Done: https://crbug.com/649888

[jww, 2016-09-24 00:49:30]

The CQ bit was checked by jww@chromium.org

[jww, 2016-09-24 00:49:30]

The patchset sent to the CQ was uploaded after l-g-t-m from mkwst@chromium.org,
nasko@chromium.org
Link to the patchset: https://codereview.chromium.org/2332263002/#ps160001
(title: "Temp disable LayoutTest")

[commit-bot: I haz the power, 2016-09-24 00:49:59]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-24 01:50:59]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-24 01:51:00]

Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[jww, 2016-09-24 03:25:02]

The CQ bit was checked by jww@chromium.org

[jww, 2016-09-24 03:25:03]

The patchset sent to the CQ was uploaded after l-g-t-m from mkwst@chromium.org,
nasko@chromium.org
Link to the patchset: https://codereview.chromium.org/2332263002/#ps180001
(title: "Actually disable test")

[commit-bot: I haz the power, 2016-09-24 03:25:17]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-24 04:47:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-09-24 04:47:12]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[jww, 2016-09-24 05:05:30]

The CQ bit was checked by jww@chromium.org

[commit-bot: I haz the power, 2016-09-24 05:05:44]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-09-24 05:42:21]

Committed patchset #10 (id:180001)

[commit-bot: I haz the power, 2016-09-24 05:44:36]

Description was changed from

==========
Updated suborigin serialization to latest spec proposal

This modifiest the serialization format of suborigins so they are now
represented in the form https-so://suboriginname.host.name (or,
alternatively, with the scheme http-so). This change removes collisions
with potentially valid URLs that were being deserialized as suborigins.

Additionally, this adds suborigins back as an experimental web platform
feature rather than a testing feature.

BUG=336894
R=mkwst@chromium.org
==========

to

==========
Updated suborigin serialization to latest spec proposal

This modifiest the serialization format of suborigins so they are now
represented in the form https-so://suboriginname.host.name (or,
alternatively, with the scheme http-so). This change removes collisions
with potentially valid URLs that were being deserialized as suborigins.

Additionally, this adds suborigins back as an experimental web platform
feature rather than a testing feature.

BUG=336894
R=mkwst@chromium.org

Committed: https://crrev.com/2cdad9ef3161ee39783c8e62e180da82797bfa78
Cr-Commit-Position: refs/heads/master@{#420828}
==========

[commit-bot: I haz the power, 2016-09-24 05:44:37]

Patchset 10 (id:??) landed as
https://crrev.com/2cdad9ef3161ee39783c8e62e180da82797bfa78
Cr-Commit-Position: refs/heads/master@{#420828}