Web services 内部web应用程序的自定义HTTP头

内部web应用程序中的自定义http头是否有任何公认的命名约定

严格意义上的内部意味着带有此标头的请求永远不会通过公共互联网传输。自由意义上的内部意味着，虽然请求可以通过公共互联网传输，但服务器端点始终是一台由特定供应商控制的机器

我意识到这一点

然而，后一个参考文献中提出的理由并不能完全说服我，因为它说：

2.  SHOULD employ meaningful parameter names that they have reason to
    believe are currently unused.

3.  SHOULD NOT prefix their parameter names with "X-" or similar
    constructs.

嗯，

X-

传达了

+所建议的语义，即该标题既没有被官方标准维护机构分配，也没有在官方标准维护机构注册，因此第2、3项。看起来有点矛盾

当然，我可以使用其他名字，比如

Vnd-

，或者公司/产品名称前缀，甚至是习惯用语，比如

Foo-

。但是，反对

X-

前缀的参数仍然适用

另一方面，仅仅使用一个“有意义的名称”会引起将来的冲突，同一术语会得到官方标准或其他公司的认可，这些公司的产品将成为加工管道的一部分

附言：

---

如果这个问题被认为过于不具体，请道歉。我很乐意把它搬到其他更合适的地方

是的，有一个公认的命名约定

VND.{domain}.{key}

示例：VND.craskingballmedia.com.runtime=102ms

您可以在此处阅读官方建议：

---

它基本上说每个人都认为“X-MyNonStandardHeader=Value”是个好主意，但仍然存在命名冲突。它说你可能不需要UUID或其他东西，但是，他们建议使用

VND.domain.key

格式。

你觉得我的答案可以接受吗？如果是的话，你能接受它作为答案吗？谢谢。非常抱歉，我想我没有。

VND

前缀解决方案相当于rfc反对的

X-

前缀。另一方面，您必须拥有域部件的名称权，以确保不会干扰其他人（因此没有非营利工作），并且总承包商可以在交付物中选择不使用您的公司名称（当然，后一种担心不适用于

VND.example.com.

，但它仍然是

X-

的变体）。UUID作为密钥对维护人员和调试人员来说是一场噩梦。最后，我很清楚您链接的rfc，请参阅上面的链接和报价…也许您可以用您的解决方案回答？SO社区中似乎没有其他人参与这项活动。谢谢