PROSAGA码农传奇-IDataAPI-自定义HTTP标头：命名约定

0# 镜乃Kagamino | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  
    2012年6月，对使用“X-”前缀的建议的弃用已成为正式的
    <a href="http://tools.ietf.org/html/rfc6648" rel="noreferrer">
      RFC 6648
    </A>
    。以下是相关的引用：
  
  <BLOCKQUOTE>
    <H3>
      3.对新参数的创建者的建议
    </H3>
    
      ...
    
    <ol start =“3”>
      <LI>
        不应该在参数名称前加上“X-”或类似名称
     结构体。
      </LI>
    </醇>
  </BLOCKQUOTE>
  <BLOCKQUOTE>
    <H3>
      4.对协议设计者的建议
    </H3>
    
      ...
    
    <ol start =“4”>
      <LI>
        
          不应该禁止带有“X-”前缀或类似参数的参数
     从注册构建。
        
      </LI>
      <LI>
        
          绝不能规定带有“X-”前缀的参数或
     类似的结构需要被理解为非标准化的。
        
      </LI>
      <LI>
        
          绝不能规定没有“X-”前缀的参数或
     类似的结构需要被理解为标准化的。
        
      </LI>
    </醇>
  </BLOCKQUOTE>
  
    请注意，“不应该”（“气馁”）与“绝不”（“禁止”）不同，另见
    <a href="http://tools.ietf.org/html/rfc2119" rel="noreferrer">
      RFC 2119
    </A>
     关于这些关键字的另一个规范。换句话说，您可以继续使用“X-”前缀标题，但不建议这样做，您也不能将它们记录为公共标准。
  
  <HR />
  
    2011年6月，第一次
    <a href="http://tools.ietf.org/html/draft-saintandre-xdash-00" rel="noreferrer">
      IETF草案
    </A>
     被张贴到
    的
      藐视
    </强>
     对非标准标题使用“X-”前缀的建议。原因是当前缀为“X-”的非标准头文件成为标准时，删除“X-”前缀会破坏向后兼容性，迫使应用程序协议支持这两个名称（例如，
     <code>
 x-gzip
 </code>
     ＆安培;
     <code>
 gzip
 </code>
     现在相当于）。因此，建议只是命名它们
    
      理智
    
     没有“X-”前缀。
  
  <HR />
  
    建议
    <击>
      是
    </击>
    的
      是
    </强>
     以“X-”开头他们的名字。例如。
    <a href="http://en.wikipedia.org/wiki/X-Forwarded-For" rel="noreferrer">
       <code>
 X-Forwarded-For
 </code>
    </A>
    ，
    <a href="http://en.wikipedia.org/wiki/X-Requested-With" rel="noreferrer">
       <code>
 X-Requested-With
 </code>
    </A>
    。这也在a.o中提到。第5节
    <a href="http://www.ietf.org/rfc/rfc2047.txt" rel="noreferrer">
      RFC 2047
    </A>
    。
  
</DIV>

1# 呵呵 | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  
    这个问题需要重新阅读。问题的实际问题与CSS属性中的供应商前缀不同，后者在未来的情况下考虑并考虑供应商支持和官方标准。问的实际问题更类似于选择URL查询参数名称。没有人应该关心它们是什么。但是，自定义名称间隔是完全有效的 - 并且是常见且正确的 - 要做的事情。
  
  
    的
      理由：
    </强>
     
    
它是关于
    
      开发人员之间的习惯，特定于应用程序的标头
    
      - “
    
      与其帐户相关的数据
    
    “ - 与第三方实施的供应商，标准组织或协议无关，除了有问题的开发人员只需要避免服务器，代理或客户端可能有其他用途的标题名称。原因，给出的“X-Gzip / Gzip”和“X-Forwarded-For / Forwarded-For”示例都没有实际意义。提出的问题是关于私有API上下文中的约定，类似于URL查询参数命名约定。它是优先级和名称间距的问题;没有“X”的任何代理或供应商支持“X-ClientDataFoo”的担忧显然是错误的。
  
  
    关于“X-”前缀没有什么特别或神奇之处，但它有助于明确它是一个自定义标题。实际上，RFC-6648等帮助支持使用“X-”前缀的情况，因为 - 当HTTP客户端和服务器的供应商放弃前缀 - 您的应用程序特定的私有API，个人数据 - 传递机制变得更加绝对 - 与少量官方保留标题名称的名称空间冲突隔离。也就是说，我个人的偏好和建议是更进一步，例如“X-ACME-ClientDataFoo”（如果您的小部件公司是“ACME”）。
  
  
    恕我直言，IETF规范不足以回答OP的问题，因为它无法区分完全不同的用例：（A）供应商一方面引入新的全球适用功能，如“Forwarded-For”，与（B） app开发人员将特定于应用程序的字符串传递给客户端和服务器。该规范仅涉及前者（A）。这里的问题是（B）是否有惯例。有。它们涉及按字母顺序将参数分组，并将它们与（A）类型的许多标准相关标题分开。使用“X-”或“X-ACME-”前缀对于（B）来说是方便和合法的，并且与（A）不冲突。对于（A），越多的供应商停止使用“X-”，（B）将变得越清晰。
  
  
    的
      例：
    </强>
     
    
谷歌（在各种标准机构中占有一定的份量）是 - 截至今日，20141102，在我的回答的这个轻微编辑中 - 目前正在使用“X-Mod-Pagespeed”来表示其所涉及的Apache模块的版本转换给定的响应。是否有人真的建议谷歌应该使用“Mod-Pagespeed”而不使用“X-”，和/或要求IETF保佑其使用？
  
  
    的
      摘要：
    </强>
     
    
如果您在应用程序中使用自定义HTTP标头（作为有时适合的cookie替代方案）来向服务器传送数据或从服务器传递数据，并且这些标头明确地不打算在应用程序的上下文之外使用，使用“X-”或“X-FOO-”前缀对它们进行名称间隔是一种合理且通用的约定。
  
</DIV>

2# 石茶 | 2019-08-31 10-32

3# IP地址 | 2019-08-31 10-32

4# 氷寒 | 2019-08-31 10-32

5# AsuRa | 2019-08-31 10-32

<div class =“post-text”itemprop =“text”>
  
    HTTP标头的格式在HTTP规范中定义。我将谈谈规范所针对的HTTP 1.1
    <a href="http://www.ietf.org/rfc/rfc2616.txt" rel="noreferrer">
      RFC 2616
    </A>
    。在第4.2节“消息头”中，定义了头的一般结构：
  
   <pre>
 <code>
 message-header = field-name ":" [ field-value ]
 field-name = token
 field-value = *( field-content | LWS )
 field-content = <the OCTETs making up the field-value
 and consisting of either *TEXT or combinations
 of token, separators, and quoted-string>

</code>
 </pre>
  
    该定义基于两个主要支柱：令牌和TEXT。两者都在第2.2节“基本规则”中定义。令牌是：
  
   <pre>
 <code>
 token = 1*<any CHAR except CTLs or separators>

</code>
 </pre>
  
    反过来依靠CHAR，CTL和分隔符：
  
   <pre>
 <code>
 CHAR = <any US-ASCII character (octets 0 - 127)>

CTL = <any US-ASCII control character
 (octets 0 - 31) and DEL (127)>

separators = "(" | ")" | "<" | ">" | "@"
 | "," | ";" | ":" | "\" | <">
 | "/" | "[" | "]" | "?" | "="
 | "{" | "}" | SP | HT

</code>
 </pre>
  
    文字是：
  
   <pre>
 <code>
 TEXT = <any OCTET except CTLs,
 but including LWS>

</code>
 </pre>
  
    LWS是线性空白区域，其定义我不会重现，而OCTET是：
  
   <pre>
 <code>
 OCTET = <any 8-bit sequence of data>

</code>
 </pre>
  
    该定义附有说明：
  
   <pre>
 <code>
 The TEXT rule is only used for descriptive field contents and values
that are not intended to be interpreted by the message parser. Words
of *TEXT MAY contain characters from character sets other than ISO-
8859-1 [22] only when encoded according to the rules of RFC 2047
[14].

</code>
 </pre>
  
    那么，有两个结论。首先，标题清楚
    
      名称
    
     必须由ASCII字符的子集组成 - 字母数字，一些标点符号，而不是其他许多字符。其次，标题的定义中没有任何内容
    
      值
    
     将其限制为ASCII或排除8位字符：它明确由八位字节组成，仅禁止控制字符（注意CR和LF被视为控件）。此外，对TEXT产生的评论暗示八位字节将被解释为在ISO-8859-1中，并且存在用于表示该编码之外的字符的编码机制（这是偶然的，可怕的）。
  
  
    因此，特别要回应@BalusC，很明显根据规范，标题值在ISO-8859-1中。我已经在Tomcat的标题中发送了高8859-1个字符（特别是法语中使用的一些重音元音），并且让它们被Firefox正确解释，所以在某种程度上，这在实践和理论上都有效。 （虽然这是一个包含URL的Location标头，这些字符在URL中不合法，所以这实际上是非法的，但是在不同的规则下！）。
  
  
    也就是说，我不会依赖ISO-8859-1在所有服务器，代理和客户端上工作，所以我会坚持使用ASCII作为防御性编程的问题。
  
</DIV>