規格で重複するHTTP応答ヘッダーが許可されるかどうかについての仕様は見つかりませんでしたが、互換性の問題が発生するかどうかを知る必要があります。

次のような応答ヘッダーがあるとします。

HTTP/1.1 302 Moved Temporarily
Server: Apache-Coyote/1.1
X-Powered-By: Servlet 2.4; JBoss-4.0.3SP1 (build: CVSTag=JBoss_4_0_3_SP1 date=200510231054)/Tomcat-5.5
Cache-Control: no-cache
Cache-Control: no-store
Location: http://localhost:9876/foo.bar
Content-Language: en-US
Content-Length: 0
Date: Mon, 06 Dec 2010 21:18:26 GMT

Cache-Control値が異なる2つのヘッダーがあることに注意してください。ブラウザは常にそれらを「Cache-Control：no-cache、no-store」のように書かれたものとして扱いますか？

はい

ここで利用可能なHTTP RFC2616 は言う：

同じフィールド名を持つ複数のメッセージヘッダーフィールドは、そのヘッダーフィールドのフィールド値全体がコンマ区切りのリストとして定義されている場合（つまり、＃（values））にのみ、メッセージに存在する可能性があります。メッセージのセマンティクスを変更せずに、複数のヘッダーフィールドを1つの「フィールド名：フィールド値」ペアに結合することが可能でなければなりません。後続の各フィールド値を最初のフィールド値にカンマで区切って追加します。したがって、同じフィールド名を持つヘッダーフィールドが受信される順序は、結合されたフィールド値の解釈にとって重要です。したがって、プロキシは、メッセージが転送されるときにこれらのフィールド値の順序を変更してはなりません（MUST NOT）。

そのため、フィールド値全体がコンマ区切りの値のリストとして定義されている場合、同じ名前の複数のヘッダーは問題ありません（www-authenticateがそのようなケースです）。

キャッシュ制御はここに文書化されています：http : //www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9このように：

Cache-Control   = "Cache-Control" ":" 1#cache-directive

#1cache-directive構文は（：#valuesの正式な定義についてはこちらをご覧少なくとも一つのキャッシュ・ディレクティブ要素のリストを定義する表記規則と一般的な文法）

あ、はい、

Cache-Control: no-cache, no-store

と同等（順序が重要）

Cache-Control: no-cache
Cache-Control: no-store

HSTS RFC6797は、STSヘッダーの複数のインスタンスの動作を定義することにより、RFC2616（「if and only if」言語に違反）と矛盾しますが、コンマ区切りの値が入力されていないことに注意してください。

  "If a UA receives more than one STS header field in an HTTP
  response message over secure transport, then the UA MUST process
  only the first such header field."