Apakah Duplikat Judul Respons HTTP dapat diterima?

123

Saya belum menemukan spesifikasi apa pun tentang apakah header respons HTTP duplikat diizinkan oleh standar, tetapi saya perlu tahu apakah ini akan menyebabkan masalah kompatibilitas.

Katakanlah saya memiliki header respons seperti ini:

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

Perhatikan bahwa ada dua Cache-Controlheader dengan nilai berbeda. Apakah browser selalu memperlakukannya seolah-olah ditulis seperti "Cache-Control: no-cache, no-store"?

http-headers

— Su Zhang
sumber

Jawaban:

157

Iya

HTTP RFC2616 tersedia di sini mengatakan:

Beberapa bidang tajuk pesan dengan nama bidang yang sama DAPAT ada dalam pesan jika dan hanya jika seluruh nilai bidang untuk bidang tajuk itu ditentukan sebagai daftar yang dipisahkan koma [yaitu, # (nilai)]. Beberapa kolom header HARUS digabungkan menjadi satu pasangan "field-name: field-value", tanpa mengubah semantik pesan, dengan menambahkan setiap kolom-nilai berikutnya ke yang pertama, masing-masing dipisahkan dengan koma. Oleh karena itu, urutan penerimaan kolom header dengan nama kolom yang sama sangat penting untuk interpretasi nilai kolom gabungan, dan karenanya proxy TIDAK HARUS mengubah urutan nilai kolom ini saat pesan diteruskan

Jadi, beberapa tajuk dengan nama yang sama tidak apa-apa (kasus seperti itu adalah www-otentikasi) jika seluruh nilai bidang ditentukan sebagai daftar nilai yang dipisahkan koma.

Cache-control didokumentasikan di sini: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 seperti ini:

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

The #1cache-directivesintaks mendefinisikan daftar setidaknya satu cache-direktif elemen (lihat di sini untuk definisi formal #values: Konvensi Penulisan dan Generic Grammar )

Jadi iya,

Cache-Control: no-cache, no-store

setara dengan (urutan itu penting)

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

— Simon Mourier
sumber

Terima kasih atas tanggapan cepat Anda, Simon! Tapi bukankah paragraf yang dikutip dari RFC 2616 juga berlaku untuk Cache-Control? Apakah saya melewatkan sesuatu?

— Su Zhang

Hampir 100% benar. Cache Control memungkinkan untuk beberapa nilai: Cache-Control = "Cache-Control" ":" 1#cache-directive. Perhatikan #sebelumnya cache-directive. Itu menunjukkan beberapa nilai diterima (langsung dari definisi Anda di atas) ...

— ircmaxell

"jika dan hanya jika seluruh nilai bidang untuk bidang tajuk itu ditentukan sebagai daftar yang dipisahkan koma" - bagi saya sepertinya beberapa nilai harus ditentukan sebagai daftar yang dipisahkan koma, yaitu tidak boleh dibagi sebagai tajuk terpisah.

— mpen

@mark - "didefinisikan sebagai daftar yang dipisahkan koma" di sini berarti "ditentukan dalam tata bahasa BNF sebagai daftar yang dipisahkan koma". Bidang kontrol-cache memang ditentukan seperti itu (x # bla bla).

— Simon Mourier

Bagian di RFC 7230 yang lebih baru yang berbicara tentang menangani banyak tajuk adalah tools.ietf.org/html/rfc7230#section-3.2.2

— Matthew Buckett

Perhatikan bahwa HSTS RFC6797 bertentangan dengan RFC2616 (melanggar bahasa "jika dan hanya jika") dengan menentukan perilaku untuk beberapa contoh header STS, meskipun tidak diisi dengan nilai yang dipisahkan koma:

  "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."

— PosterBoy
sumber

Salah. RFC6797 TIDAK mendefinisikan header STS karena berisi daftar yang dipisahkan koma. Jadi aturan "jika dan hanya jika" dari RFC 2616 berlaku sama (artinya bahwa beberapa header STS TIDAK diizinkan karena header STS tidak didefinisikan sebagai mengambil daftar yang dipisahkan koma). RFC6797 hanya membuatnya non-deterministik apa konsekuensi dari melanggar aturan itu, sesuatu yang tampaknya dibiarkan terbuka oleh RFC2616.

— Frans