我可以在 HTTP 标头中传递自定义数据吗？
我有一大堆 Web 服务，每个服务都有几个 Web 方法。 这些服务的消费者多种多样且众多。 我想用额外的可选参数（Int64 或 Int32）来增强每个 Web 方法，但是使用这个额外的（可选参数）添加新方法需要大量工作，并且让客户端使用新方法将更加耗时。
所以我想知道是否可以允许想要利用此参数提供的新功能的客户端可以在 HTTP 标头或其他方式中传递此 Int。
所以第一个问题是我可以在 HTTP header 中传递一个 int 吗？ 如果是这样，如何在 C#/ASP.NET 中做到这一点？
否则，您对解决这个问题还有什么其他建议？
I have a whole bunch of web services each with several web methods. The consumers of these services are varied and many. I want to augment each of these web methods with an extra optional parameter (Int64 or Int32) but adding new methods with this extra (optional parameter) is a lot of work and getting the clients to use the new methods will be even more time consuming.
So I was wondering if I could allow the clients that wanted to take advantage of the new feature that this param provides could pass this Int in the HTTP header or some other way.
So the first question is can I pass an int in the HTTP header? If so, how would one do that in C#/ASP.NET?
Otherwise, what other suggestions do you have for tackling this problem?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
它有点不正统，我确信一些纯粹主义者会对这个想法感到不安（标头应该只用于消息的传输，而不应该包含消息的语义）。
实际上它是可行的，但您希望确保所有客户都可以添加这些标头。 如果您的客户端使用工具来调用 Web 方法而不是自己生成 HTTP 请求（我希望是这样），那么这很可能是一个问题。
为什么添加这些额外的方法重载如此困难？
Its a bit unorthodox and I'm sure some purists would be upset at the idea (the headers should only be used for the transport of the message, and should not contain the semantics of the message).
Practically its doable, but you want to be sure all your clients can add these headers. If your clients are using tools to call the web methods rather than generating the HTTP requests themselves (which I'd hope is the case) then there's a real chance this is a problem.
Why is it so hard to add these additional overloads of the methods?
是的，这是允许的 - 但请注意，它可能会切断使用代理的能力，有时还会切断使用 http 感知防火墙的能力（它们倾向于检查和重写标头）。
Yes it is allowed - but note that it may cut off the ability to use proxies and sometimes http aware firewalls (they tend to inspect and rewrite headers).
来自 RFC！
你真的可以，现在新的 RFC 标准支持它，
当您想要从 API 获取但仍然想要 GET 纯粹的本性（GET 中没有正文）时确实很有帮助。
为了简化阅读，请查看 Mozilla 说明
FROM RFC!
You really can, now it is supported by the new RFC Standards,
Really helps when you want to GET from your API but still want GET pure nativity(no body in GET)
For a simplified read, check out Mozilla Explanation
我曾经使用过这个概念来处理 Intranet Web 应用程序中 ajax 调用的注销重定向（与 Web 服务无关）。
这是我手头最好的解决方案，但正如其他人所说，这取决于您是否可以将约束施加给客户端以根据您的目的处理这些标头。
默认情况下绝对不是您想要做的事情。
I've used this concept once to handle logout redirect for ajax calls in an intranet web application (nothing related to webservice).
it was my best solution at hand, but as some other have said it depends if you can push the constraint to clients to treat theses headers for your purpose.
Definitely not a thing you would want to do by default.
可以，但您必须定义一个标头，然后设置其值。 就像在 HttpWebRequest 中一样，您可以添加任何标头，只要它不是保留标头之一。
You can, but you have to define a Header, then set its value. Like in the HttpWebRequest you can add any header, as long as its not one of the reserved ones.
请注意，虽然可以在 ASP.NET 中使用自定义标头，但并不总是可以在 ASP.NET 中生成自定义标头。 仅当您运行 ASP.NET 集成模式（即 IIS 7.0）时才能执行此操作。
Note that while it's fine to consume custom headers in ASP.NET it's not always possible to produce custom headers in ASP.NET. You can only do this if you're running ASP.NET integrated mode (i.e. IIS 7.0).
可以，但这从一开始就违背了使用 Web 服务的全部目的。 就像科普书中的每一个公式都会让读者减少一半一样，每次增加界面复杂性的快速破解都意味着未来会带来很多麻烦。
You can, but this defeats the whole purpose of using webservices in the first place. Similar to the saying that each formula in a popular science books reduces the audience to a half, each quick hack increasing the complexity of the interface will mean a lot of trouble in the future.