Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.

@smarterclayton @bgrant0607 @csrwng

Structurally this is sound - essentially we're saying ResourceLocation as a method is providing Storage consumers in the code the ability to locate a remote resource and connect to it (i.e. a Pod has both a local identity in the apiserver and a remote identity on the kubelet). The proxiers can then use this to determine how to connect to a remote agent. It does mean ResourceLocation that returns a transport is not by default remotable (we wouldn't return the transport to the client in almost all cases) but since proxy was consuming resourcelocation and we need to continue consuming that, it seems like the right abstraction for allowing other REST resources to connect to pods.

cc @lavalamp @davidopp, in case they want to review or assign a reviewer

Yes, proxy has been broken in multiple ways. That implies lack of testing.

FYI: proxy-related issues:

namespaces - #5339
problematic rewriting and path structure - #4440
proposal to convert internal resourcelocation API to endpoints subresource: #4440 (comment)
bastion - #3481
dos - #4875

Rebased

LGTM

Will merge in the morning

Travis is failing