为什么我的REST服务.NET客户端会发送没有身份validation标头的每个请求，然后使用身份validation标头重试它？
我们碰巧运行带有API的REST Web服务，要求客户端使用基本身份validation。 我们用各种语言制作了一套简洁的样本，展示了如何与我们的服务进行交互。 现在我正在检查服务的IIS日志，并发现以下模式经常发生：
- 请求到来，被HTTP代码401拒绝
- 相同的请求被重新发送并成功
看起来像第一个请求没有授权标头发送，然后第二个请求与正确的标头一起发送并成功。 大多数情况下，日志记录包含“user-agent”，这与我们在.NET示例中植入的字符串相同。
所以我认为问题仅在于.NET程序。 我们的示例代码没有重现该问题，因此我假设用户以某种方式修改了代码或从头开始编写自己的代码。
我们尝试联系用户，但显然他们不想花时间研究。 因此，很高兴找到导致.NET程序这种行为的最可能的情况。
他们为什么要这样做？ 他们为什么不在第一次尝试时附上标题？
这是HttpClient和HttpWebRequest类的默认行为，它以下列方式公开。
注意：下面的文字解释了导致问题中描述的问题的次优行为。 很可能你不应该像这样写你的代码。 而是向下滚动到更正的代码
在这两种情况下，都要实例化NetworkCredenatial对象并在其中设置用户名和密码
var credentials = new NetworkCredential( username, password );
如果您使用HttpWebRequest – 设置.Credentials属性：
webRequest.Credentials = credentials;
如果您使用HttpClient – 将凭证对象传递给HttpClientHandler （从此处更改代码）：
var client = new HttpClient(new HttpClientHandler() { Credentials = credentials })
然后运行Fiddler并启动请求。 您将看到以下内容：
- 请求在没有Authorization标头的情况下发送
- 服务回复HTTP 401和WWW-Authenticate：Basic realm =“UrRealmHere”
- 使用适当的Authorization标头重新发送请求（并成功）
此处解释了此行为 – 客户端事先并不知道该服务需要Basic并尝试协商身份validation协议（如果服务需要Digest在open中发送Basic头，则无用且可能危及客户端）。
注意：这里次优的行为解释结束，并解释了更好的方法。 您最有可能使用下面的代码而不是上面的代码。
对于已知服务需要Basic的情况 ，可以通过以下方式消除额外请求：
不要设置.Credentials ，而是使用此处的代码手动添加标题。 编码用户名和密码：
var encoded = Convert.ToBase64String( Encoding.ASCII.GetBytes( String.Format( "{0}:{1}", username, password ) ) );
使用HttpWebRequest将其添加到标题中：
request.Headers.Add( "Authorization", "Basic " + encoded );
并在使用HttpClient将其添加到默认标头：
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue( "Basic", encoded );
执行此操作时，每次都会使用正确的授权标头发送请求。 请注意，您不应该设置.Credentials ，否则如果用户名或密码错误，则同一请求将在错误凭据的两次发送两次，当然两次都会产生HTTP 401。