我找到了一个响应,其中具有相同值的应用程序使用重复的标头。任何人都可以告诉我,这是一个很好的编程实践还是用于安全角度或其他任何事情?
HTTP/1.1 200
Accept-Ranges: bytes
Cache-Control: no-cache, must-revalidate, private
Content-Type: text/html
Date: Mon, 20 Nov 2017 04:08:51 GMT
Expires: 0
Last-Modified: Thu, 16 Nov 2017 14:04:48 GMT
Pragma:
Public-Key-Pins: pin-sha256="5w0XrTCAbsVO7vTngDViNHPutlvB43qYionPbpV2ky0=";
max-age=5184000; includeSubDomains;
Server: Any
Set-Cookie: ********************* httponly; secure; path=/
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
Content-Length: 559
Connection: Close
此应用程序使用具有相同值的重复X-Content-Type-Options标头,Strict-Transport-Security,X-Frame-Options标头。 我在stackoverflow上发布了这个问题,但我没有找到任何回复。
答案 0 :(得分:4)
来自RFC2616
当且仅当该标题字段的整个字段值被定义为以逗号分隔的列表[即#(值)]时,具有相同字段名称的多个消息标题字段可以出现在消息中。必须可以将多个头字段组合成一个“字段名:字段 - 值”对,而不改变消息的语义,方法是将每个后续字段值附加到第一个字段值,每个字段值用逗号分隔。因此,接收具有相同字段名称的头字段的顺序对于组合字段值的解释是重要的,因此代理不得在转发消息时改变这些字段值的顺序
所以
Cache-Control: no-cache
Cache-Control: must-revalidate
Cache-Control: private
没关系。我不相信这适用于此。如果有重复的标头条目有效,则将依赖于每个标头是否允许重复值。
从安全角度来看,如果这些行中的任何一行不合法,则不会定义客户端将对它们执行的操作 - 因此忽略它们可能是一个有效的选项。因此,我认为不好的做法在技术上也是一种风险。
从实际角度来看,我可以通过几种方式想象客户处理这个问题。
答案 1 :(得分:2)
如果重复标题很好,它的解释方式取决于标题的确切语义。
像Content-Encoding
这样的标题是累积的,即所有值都将被放在一起(至少在理论上,practice might differ)。在这种情况下,具有相同值的多个标题当然与具有单个标题不同。
其他标题是单例,最多应出现一次。通常,如果为单例发送多次相同的标头和值,则会被接受。但我不会依赖它,因为它仍然无效。如果使用不同的值多次发送相同的标头,则客户端的行为会发生变化(可能还取决于标头):有些标头选择特定标头(即第一个或最后一个),而其他标头则将响应视为损坏,因为多个解释可能是which can result in security problems。
答案 2 :(得分:0)
正确的行为(按照RFC)是,如果标头是列表(如[ 12 seconds wait. 12 ]promiseValue then: [ :a| Transcript crShow: a/2 ]
)或产生错误,则追加。
在实践中,正如斯特芬·乌尔里希(Steffen Ulrich)所说,互联网是雁儿,结果会因客户而异。我认为大多数客户不会产生错误。错误概念的一个问题是,您不知道的标头可能是一个值的标头(与列表相对),因此您无法知道是否允许重复该标头。因此RFC很好,但对于此类标头却不能正确遵循。
在大多数情况下,我会说重复标头(尤其是使用相同的值)是一种不好的做法,并调查是否有可能避免重复。由于在您的情况下,两者的价值完全相同,因此对于大多数可用的客户来说都可以。