【问题标题】:Get request: multiple header options with same key?获取请求:具有相同键的多个标头选项?
【发布时间】:2012-11-05 11:10:54
【问题描述】:

我正在使用 API,它需要这样的标头:

授权:ClientKey keyhere
授权:UserKey key2here

当我像这样将这个参数添加到 RestSharp 的请求时:

request.AddHeader("Authorization", "ClientKey 111111");
request.AddHeader("Authorization", "UserKey 222222");

我明白了,只写了最后一个。 这是因为他们有相同的密钥。 但是如何避免呢?

我了解,这是服务器端的错误行为,但此代码已在其他平台的生产环境中使用。

更新

我找到了解决方案:

request.AddHeader("Authorization", "ClientKey 111111, UserKey 222222");

【问题讨论】:

  • 您确定不应该将keyhere 替换为您的密钥吗?
  • 你是对的!但它并没有解决我的问题
  • 两个标题同名是没有意义的。它们作为键/值对工作,因此不存在重复项。您正在使用什么 API?
  • nda。正如我所写,此 api 通过具有多行授权的 Chrome 的 Rest Client / Postman 扩展工作正常。这就是为什么我试图在 .net 中获得相同的可能性。
  • @OlegKalyta 你的解决方案是修复客户端,对吧?

标签: .net api rest authorization restsharp


【解决方案1】:

请参阅 HTTP RFC 的 14.8 Authorization 部分:

希望通过服务器验证自己的用户代理—— 通常,但不一定,在收到 401 响应后——确实 所以通过包含一个授权请求头字段 要求。

另见 RFC 2617 的 3.2.2 The Authorization Request Header 部分:

客户端应该重试请求,通过一个授权 标题行,根据上面的框架定义, 如下使用。

这两个引用都谈到了 anthe 标题。根据 RFC,可能可以多次设置 Authentication 标头。但是服务器将无法根据 RFC 选择包含凭据的 one 标头。

服务器 仅使用一个(最后一个这样的标头)即可正常工作。你的客户坏了。

【讨论】:

  • 我决定检查一下,Rest Client 究竟向服务器发送了什么:身份验证:key1 value1,key2 value2 我做了同样的事情,它对我有用
猜你喜欢
  • 2021-11-24
  • 2022-01-04
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2022-01-22
相关资源
最近更新 更多