gpt4 book ai didi

.net - System.Net.Caching.HttpRequestCachePolicy 和 CloudBlob.FetchAttributes 之间的冲突

转载 作者:行者123 更新时间:2023-12-02 07:32:02 24 4
gpt4 key购买 nike

我似乎收到了 403:

HTTP/1.1 403 Server failed to authenticate the request. Make sure the value of Authorization header is formed correctly including the signature.

当我在 app.config 中设置 HttpWebRequest.DefaultCachingPolicy 时,会发生这种情况,如下所示:

<system.net>
<requestCaching defaultPolicyLevel="Default" isPrivateCache="false">
<defaultHttpCachePolicy policyLevel="Default"/>
</requestCaching>
</system.net>

我这样做是因为我有一些我无法控制的遗留代码正在调用我提供的 Blob 存储的 API,就好像它是一个文件系统一样(每个文件最多 58 个相同的调用)。显然这并不理想。使用默认 HTTP 样式缓存是我想要的一种行为,因为它会导致我的应用程序仅在文件修改时下载文件。

这个问题似乎在每个其他请求中都会发生(例如,当请求被缓存并且服务器正在检查服务器内容是否已更改时,它似乎会发生)。

失败的请求和成功的请求之间的唯一区别似乎是包含:

If-None-Match: "<a blob etag>"
If-Modified-Since: <a date>

我在 github 上查看了 1.7.1 的 .net API(我正在使用)的代码,假设它与 SDK 1.6(我当前正在使用的)相比没有更改,它应该可以工作很好。

非常感谢任何帮助

更新:我编写了一些重现代码来提供帮助:

使用:.NET 4.0、Windows Azure SDK 1.6

using System;
using System.Net;
using System.Net.Cache;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.StorageClient;

namespace AzureStorageProb
{
class Program
{
static void Main(string[] args)
{
const string accountKey = "<azure storage account key>";
const string account = "<azure storage account name>";
const string testBlob = "<blob path to test file>";
var cloudStorageAccount =
new CloudStorageAccount(
new StorageCredentialsAccountAndKey(account, accountKey),
useHttps: true);
var cloudBlobClient = cloudStorageAccount.CreateCloudBlobClient();
HttpWebRequest.DefaultCachePolicy =
new HttpRequestCachePolicy(HttpRequestCacheLevel.Default);

try
{
var blob = cloudBlobClient.GetBlobReference(testBlob);
blob.FetchAttributes();
blob.DownloadByteArray();
Console.WriteLine("First attempt worked!");
}
catch (StorageClientException ex)
{
Console.WriteLine(ex);
}

try
{
var blob = cloudBlobClient.GetBlobReference(testBlob);
blob.FetchAttributes();
blob.DownloadByteArray();
Console.WriteLine("Second attempt worked!");
}
catch (StorageClientException ex)
{
Console.WriteLine(ex);
}
Console.ReadKey();
}
}
}

最佳答案

原来罪魁祸首是 BlobRequest.SignRequest(request, creds); 快速浏览一下文档表明 If-None-MatchIf-Modified-Since 都用作调用添加的身份验证 header 的计算的一部分。因为这些 header 是在 WINInet 计算身份验证 header 之后添加的(假设)。无论哪种方式,最终结果都是身份验证 header 提供的校验和现在无效。从而导致 403 Forbidden

解决方法:

  • 在本地手动缓存项目
  • 修复调用代码(可能是最佳的长期解决方案)
  • 非常小心地使用其余接口(interface)(实验表明,出于同样的原因,这很危险,在某些情况下使用“Shared Key Lite”可以解决这个问题)
  • 使用常规 WebRequest 获取文件(这意味着您必须通过共享 key 或其他方式将它们公开到互联网)

我不会说 Azure Blob 存储已损坏...但我会说它不是真正的 RESTful,因为它无法正确遵守 HTTP 语义。

关于.net - System.Net.Caching.HttpRequestCachePolicy 和 CloudBlob.FetchAttributes 之间的冲突,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/13369660/

24 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com