C# 使用Proxy代理请求资源的方法步骤

前言

这是上周在开发 c# 中使用 proxy 代理时开发的一些思考和实践。主要需求是这样的，用户可以配置每次请求是否需要代理，用户可以配置 http代理，https代理和代理白名单。

还是太年轻

因为一直用的c# 网络库中的httpwebrequest，所以自然而然先去找找看这个网络库有没有封装好我所需要的代理呀。果不其然，被我找到了。自从上次发现某些类对老版本不兼容后，每次在微软官方文档上找到都会翻到最后，查看一下支持的最低框架。

我需要的就是这个 proxy 属性，也就是说我最终在发送请求前，设置好这个 proxy 属性就可以了。先去看看 proxy 类

the iwebproxy object to use to proxy the request. the default value is set by calling the select property.

这样的意思就是说我只要构造一个webproxy，然后赋值给 httpwebrequest.proxy就可以了。

看到了webproxy 的构造器，马上锁定了

因为我需要用户传的是 string ，所以直接这样构造就可以了。然后就是测试了，主管大佬写的 node.js的proxy代理 先来测试测试

npm install o_o -g

o_o

这样就启动全局安装并启动了代理，在控制台上可以看到监听的是 8989 端口

 [fact]
public void httpproxy()
{
  var request = new describeaccesspointsrequest();
  client.sethttpproxy("http://localhost:8989");

  var response = client.getacsresponse(request);
  assert.notnull(response.httpresponse.content);

  var expectvalue = "http/1.1 o_o";
  string actualvalue;
  response.httpresponse.headers.trygetvalue("via", out actualvalue);
  assert.equal(expectvalue, actualvalue);
}

如果经过了代理，头部会出现 "http/1.1 o_o" 字段 ，经过ft测试，是成功的。

本来一切都没有问题的，除了我自己想的比较简单外，直到我 code review 了一下组里开发java 的人实现这个功能的 pull request ，我才发现我还真的是想的太简单！！！

开始重构

首先发现的一点是，我连constructor都用错了，用ilspy反编译了一下，发现webproxy(string,bool,string[])所作的事。

// system.net.webproxy
private static uri createproxyuri(string address)
{
  if (address == null)
  {
    return null;
  }
  if (address.indexof("://") == -1)
  {
    address = "http://" + address;
  }
  return new uri(address);
}

即使传进去的是string，最后也是构造成 uri， 为什么会关注的这个呢？因为我发现有些proxy地址是

http://username:password@localhost:8989 长这样的，那么我如果直接以这种形式传入到createproxy里面，它会自动给我分解，然后分credential和 proxy 传入到网络库中吗？接下来就是验证的过程。

首先需要了解到的一个概念：basic access authentication

in the context of an http transaction, basic access authentication is a method for an http user agent (e.g. a web browser) to provide a user name and password when making a request. in basic http authentication, a request contains a header field of the form authorization: basic <credentials>, where credentials is the base64 encoding of id and password joined by a colon.

it is specified in rfc 7617 from 2015, which obsoletes rfc 2617 from 1999.

由于其不安全性，已在 rfc 中弃用了，转而代之的是 tls ssl 那些协议。

问题来了， httpwebrequest 中支持basic authentication吗？我们可以看到webproxy中有一个构造方法最后一个参数是 icredential 的

是的，就是它，知道前因后果和不足后，我继续去重构 http proxy 的代码：

originproxyuri = new uri(proxy);
if (!string.isnullorempty(originproxyuri.userinfo))
{
  authorization = convert.tobase64string(system.text.encoding.getencoding("iso-8859-1").getbytes(originproxyuri.userinfo));
  finalproxyuri = new uri(originproxyuri.scheme + "://" + originproxyuri.authority);
  var userinfoarray = originproxyuri.userinfo.split(':');
  credential = new networkcredential(userinfoarray[0], userinfoarray[1]);

  httprequest.webproxy = new webproxy(finalproxyuri, false, noproxy, credential);
}

先拆分出 userinfo credential 和 uri信息，然后分别重新构造相应的类型传入到 webproxy 中。上面也有一个坑，我之前还想用正则把username和password 分别提取出去了，没想到 uri 已经封装好了，直接取里面的userinfo 信息。哈哈，省力了。

*上也有挺多关于如何传入 credential 到proxy中，基本上用的也是这个方法，按理说这样就完事了，直到我做了测试，我发现微软这个credential根本没有起作用，如果是正确的话，会在 header 中添加

authorization: basic <credentials> ，和上面那段测试代码一样，

[fact]
public void httpproxywithcredential()
{
  describeaccesspointsrequest request = new describeaccesspointsrequest();
  client.sethttpproxy("http://username:password@localhost:8989");
  var response = client.getacsresponse(request);

  var expectvalue = "http/1.1 o_o";
  string actualvalue;
  response.httpresponse.headers.trygetvalue("via", out actualvalue);

  assert.equal(expectvalue, actualvalue);
  assert.notnull(response.httpresponse.content);
}

我去测试了发现，这个头部里面根本没有加这个 authorization 属性啊，尴尬了，是官方文档坑还是我使用不正确呢，基于此，想到了之前 主管 开发的那个 proxy 代理 o_o ，我又去找了一个验证 basic-auth 的node.js 代理服务器

npm install basic-auth

var http = require('http')
var auth = require('basic-auth')
var compare = require('tsscmp')

// create server
var server = http.createserver(function (req, res) {
 var credentials = auth(req)

 // check credentials
 // the "check" function will typically be against your user store
 if (!credentials || !check(credentials.name, credentials.pass)) {
  res.statuscode = 401
  res.setheader('www-authenticate', 'basic realm="example"')
  res.end('access denied')
 } else {
  res.end('access granted')
 }
})

// basic function to validate credentials for example
function check (name, pass) {
 var valid = true

 // simple method to prevent short-circut and use timing-safe compare
 valid = compare(name, 'john') && valid
 valid = compare(pass, 'secret') && valid

 return valid
}

// listen
server.listen(3000)

将上面那段 js代码打包成一个 js文件，然后执行

node tets.js

该代理服务器监听 3000端口，我使用刚才那段代码，果不其然，返回的是 401 ，这不是坑吗，官方文档上这样说可以，然而都不行。

最后只能强制加上这个 authorization 代码

originproxyuri = new uri(proxy);
if (!string.isnullorempty(originproxyuri.userinfo))
{
  authorization = convert.tobase64string(system.text.encoding.getencoding("iso-8859-1").getbytes(originproxyuri.userinfo));
  finalproxyuri = new uri(originproxyuri.scheme + "://" + originproxyuri.authority);
  var userinfoarray = originproxyuri.userinfo.split(':');
  credential = new networkcredential(userinfoarray[0], userinfoarray[1]);

  httprequest.webproxy = new webproxy(finalproxyuri, false, noproxy, credential);
  httprequest.headers.add("authorization", "basic " + authorization);          
}

最后在测试经过 3000 端口的代理服务器，确认是没问题的，把问题想得简单的结果就是发了一个新版本后，还没有下载，然而已经发了新版本说，用户您好，我们又有新版本了。尴尬。需要以此为鉴啊。

后记

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持。