Header HTTP khusus: konvensi penamaan


1115

Beberapa pengguna kami telah meminta kami untuk memasukkan data relatif ke akun mereka di header HTTP permintaan yang kami kirimkan, atau bahkan tanggapan yang mereka dapatkan dari API kami. Apa konvensi umum untuk menambahkan header HTTP khusus, dalam hal penamaan , format ... dll.

Juga, jangan ragu untuk memposting segala penggunaan pintar ini yang Anda temukan di web; Kami mencoba menerapkan ini menggunakan apa yang terbaik di luar sana sebagai target :)


25
Ketahuilah bahwa firewall dapat menghapus bidang tajuk respons. Beberapa menghapus semua yang tidak disebutkan dalam RFC 2616 (Juni 1999, HTTP 1.1). Sisi klien harus tetap dapat digunakan tanpa bidang baru.
stesch

5
Perhatikan bahwa komentar oleh @stesch tidak berlaku ketika menggunakan HTTP S .
code_dredd

1
Perhatikan bahwa komentar oleh @code_dredd adalah legenda urban. Firewall dapat memfilter konten HTTPS. Lihat howtoforge.com/filtering-https-traffic-with-squid dan watchguard.com/help/docs/wsm/xtm_11/en-us/content/en-us/...
stesch

@stesch Mengingat bahwa artikel Anda pada dasarnya mengubah proxy menjadi sesuatu yang mirip dengan MiTM (dibutuhkan koneksi klien terenkripsi dan kemudian membuat yang baru) maka tentu saja, Anda dapat melakukan hampir semua hal, tetapi fakta itu meniadakan enkripsi dari PoV proxy b / c itu mendekripsi konten klien itu sendiri. Dalam hal ini, dari PoV proxy, pada dasarnya seolah-olah Anda tidak menggunakan HTTPS di tempat pertama ...
code_dredd

Jawaban:


1172

Rekomendasi ini adalah untuk memulai nama mereka dengan "X". Misalnya X-Forwarded-For, X-Requested-With. Ini juga disebutkan dalam bagian 5 RFC 2047 .


Pembaruan 1 : Pada Juni 2011, draft IETF pertama diposting untuk mencabut rekomendasi penggunaan awalan "X-" untuk header yang tidak standar. Alasannya adalah bahwa ketika tajuk non-standar diawali dengan "X-" menjadi standar, menghapus awalan "X-" merusak kompatibilitas, memaksa protokol aplikasi untuk mendukung kedua nama (Misalnya, x-gzip& gzipsekarang setara). Jadi, rekomendasi resmi adalah untuk memberi nama mereka dengan masuk akal tanpa awalan "X-".


Pembaruan 2 : Pada Juni 2012, penghentian rekomendasi untuk menggunakan awalan "X-" telah resmi sebagai RFC 6648 . Di bawah ini adalah kutipan relevansi:

3. Rekomendasi untuk Pembuat Parameter Baru

...

  1. HARUS TIDAK mengawali nama parameter mereka dengan "X-" atau konstruksi serupa.

4. Rekomendasi untuk Desainer Protokol

...

  1. HARUS TIDAK melarang parameter dengan awalan "X-" atau konstruksi serupa dari yang terdaftar.

  2. HARUS TIDAK menetapkan bahwa parameter dengan awalan "X-" atau konstruksi serupa perlu dipahami sebagai tidak standar.

  3. HARUS TIDAK menetapkan bahwa parameter tanpa awalan "X-" atau konstruksi serupa perlu dipahami sebagai standar.

Perhatikan bahwa "HARUS TIDAK" ("tidak disarankan") tidak sama dengan "HARUS TIDAK" ("dilarang"), lihat juga RFC 2119 untuk spesifikasi lain tentang kata kunci tersebut. Dengan kata lain, Anda dapat tetap menggunakan header awalan "X-", tetapi tidak direkomendasikan secara resmi lagi dan Anda mungkin tidak mendokumentasikannya seolah-olah standar publik.


Ringkasan :

  • rekomendasi resmi adalah untuk memberi nama mereka secara masuk akal tanpa awalan "X-"
  • Anda dapat terus menggunakan header awalan "X-", tetapi tidak secara resmi direkomendasikan lagi dan Anda mungkin tidak mendokumentasikannya seolah-olah itu adalah standar publik

306
Seperti halnya ada banyak anak yang tidak akan pernah berakhir sebagai atlet profesional, banyak header kustom tidak akan pernah berakhir sebagai standar. Saya cenderung mempertahankan "X-" pada itu.
G-Mac

19
@ G-Mac Setuju. Ada begitu banyak header khusus yang tidak akan pernah berakhir terstandarisasi. Beberapa yang melakukannya, mudah untuk mengedit kode Anda dari if (header == "x-gzip")ke if (header == "x-gzip" || header == "gzip"). Adapun analogi Anda, ini yang lain: itu seperti militer yang mengatakan, "Oh, sulit untuk mengubah seseorang dari Privat menjadi Jenderal. Jadi, mulai sekarang, kalian semua Jenderal. Sekarang kita tidak perlu melakukan begitu banyak pekerjaan."
Cole Johnson

24
@ColeJohnson Tidak yakin apakah analogi itu bekerja. Masalahnya di sini adalah tidak ada titik pusat Anda dapat mengubah nama. Setiap cuplikan kode yang mengharapkan x-gzip sekarang harus diubah, atau tajuk yang lama perlu terus digunakan selain yang baru. Lebih baik menggunakan RFC 6648.
vinod

4
@Vinod ya. Masuk akal, tetapi ada begitu banyak standar yang diusulkan yang tidak akan pernah melihat cahaya hari. Untuk jenis file, tentu saja; letakkan X-awalan. Saya menentangnya, tetapi teruskan dan lakukan itu. Untuk tajuk OTOH, jangan jatuhkan. Itu membuatnya mudah untuk melihat dan pergi, "oh, itu tidak standar; saya bisa mengabaikannya" vs "ada X-header yang tidak standar , dan kemudian ada yang tidak saya kenal; bisakah saya mengabaikannya dengan aman?"
Cole Johnson

21
Meskipun nada jawaban cweekly tidak perlu defensif, saya percaya dia benar, dan maksudnya memecahkan masalah yang diilustrasikan dalam utas komentar ini. Singkatnya, jangan mencoba mengidentifikasi apakah header akan "lulus" atau tidak; alih-alih tentukan apakah itu header pribadi atau publik (khusus aplikasi atau "generik" / "global"). Untuk tajuk pribadi, gunakan opsionalX- untuk memastikan tidak ada bentrok dengan tajuk publik (terima kasih kepada RFC6648, yang berkaitan dengan tajuk publik), dan selain itu pasti menggunakan awalan pribadi yang sewenang-wenang. Untuk tajuk publik, jangan gunakan X-dalam situasi apa pun.
mentega

535

Pertanyaannya harus dibaca ulang. Pertanyaan aktual yang diajukan tidak mirip dengan awalan vendor di properti CSS, di mana pemeriksaan di masa depan dan pemikiran tentang dukungan vendor dan standar resmi sesuai. Pertanyaan aktual yang diajukan lebih mirip dengan memilih nama parameter kueri URL. Tak seorang pun harus peduli apa mereka. Namun penamaan spasi untuk custom adalah hal yang benar-benar valid - dan umum, dan benar - untuk dilakukan.

Dasar Pemikiran:
Ini tentang konvensi di antara pengembang untuk tajuk khusus, tajuk khusus aplikasi - " data yang relevan dengan akun mereka " - yang tidak ada hubungannya dengan vendor, badan standar, atau protokol yang akan dilaksanakan oleh pihak ketiga, kecuali bahwa pengembang yang dimaksud hanya perlu menghindari nama-nama tajuk yang mungkin memiliki tujuan penggunaan lain oleh server, proksi atau klien. Karena alasan ini, contoh "X-Gzip / Gzip" dan "X-Forwarded-For / Forwarded-For" yang diberikan sedang diperdebatkan. Pertanyaan yang diajukan adalah tentang konvensi dalam konteks API pribadi, mirip dengan konvensi penamaan parameter kueri URL. Ini masalah preferensi dan jarak nama; kekhawatiran tentang "X-ClientDataFoo" yang didukung oleh proxy atau vendor apa pun tanpa "X"

Tidak ada yang istimewa atau ajaib tentang awalan "X-", tetapi membantu menjelaskan bahwa itu adalah tajuk khusus. Faktanya, RFC-6648 dkk membantu memperkuat kasus untuk penggunaan awalan "X-", karena - karena vendor klien HTTP dan server mengabaikan awalan - khusus aplikasi Anda, API pribadi, data pribadi- mekanisme passing menjadi lebih baik-terisolasi terhadap tabrakan ruang-nama dengan sejumlah kecil nama header resmi yang dipesan. Yang mengatakan, preferensi dan rekomendasi pribadi saya adalah melangkah lebih jauh dan melakukan mis. "X-ACME-ClientDataFoo" (jika perusahaan widget Anda adalah "ACME").

IMHO, spesifikasi IETF tidak cukup spesifik untuk menjawab pertanyaan OP, karena gagal membedakan antara kasus penggunaan yang sangat berbeda: (A) vendor memperkenalkan fitur-fitur baru yang berlaku secara global seperti "Forwarded-For" di satu sisi, vs. (B) pengembang aplikasi yang meneruskan string khusus aplikasi ke / dari klien dan server. Spesifikasi hanya menyangkut dirinya dengan yang pertama, (A). Pertanyaannya di sini adalah apakah ada konvensi untuk (B). Ada. Mereka melibatkan pengelompokan parameter bersama-sama berdasarkan abjad, dan memisahkannya dari banyak header tipe standar yang relevan (A). Menggunakan awalan "X-" atau "X-ACME-" nyaman dan sah untuk (B), dan tidak bertentangan dengan (A). Semakin banyak vendor berhenti menggunakan "X-" untuk (A), akan semakin jelas perbedaan (B) yang akan terjadi.

Contoh:
Google (yang membawa sedikit bobot di berbagai badan standar) adalah - mulai hari ini, 20141102 dalam sedikit pengeditan jawaban saya - saat ini menggunakan "X-Mod-Pagespeed" untuk menunjukkan versi modul Apache mereka terlibat dalam mengubah respons yang diberikan. Adakah yang benar-benar menyarankan agar Google menggunakan "Mod-Pagespeed", tanpa "X-", dan / atau meminta IETF untuk memberkati penggunaannya?

Ringkasan:
Jika Anda menggunakan Header HTTP khusus (sebagai alternatif cookie yang kadang-kadang sesuai) dalam aplikasi Anda untuk meneruskan data ke / dari server Anda, dan header ini, secara eksplisit, TIDAK dimaksudkan untuk digunakan di luar konteks Anda aplikasi, beri nama spasi dengan awalan "X-" atau "X-FOO-" adalah konvensi yang wajar dan umum.


52
Saya akan menghargai jika ada downvoters komentar saya dapat menjelaskan bagian mana dari jawaban saya yang mereka anggap tidak menyenangkan. Saya tidak terlalu peduli dengan skor reputasi saya, tetapi saya benar-benar ingin tahu. Di mana letak perbedaan pendapat? Terima kasih.
minggu

56
Saya sepenuhnya setuju dengan jawaban Anda dan satu-satunya jawaban di sini yang menjawab pertanyaan aktual yang diajukan. Kami berbicara tentang custom, header khusus aplikasi di sini, tidak pernah distandarisasi dalam standar HTTP. Apakah ada konvensi umum untuk ini yang cenderung digunakan orang? (seperti mengawali mereka dengan "_" mungkin? yaitu: ("_ClientDataFoo")
Marchy

14
Terima kasih Marchy, ya, jawaban yang diterima tidak menjawab pertanyaan yang diajukan. Penghentian IETF dari awalan "X-" untuk tajuk non-standar (tapi generik) tidak relevan dengan tajuk khusus aplikasi khusus yang tidak akan pernah distandarisasi. Untuk menjawab pertanyaan Anda, menurut pendapat dan pengalaman saya (16 tahun webdev), konvensi terbaik adalah dengan menggunakan "X-ACME-ClientData" tersebut di atas. "X-" bc itu bukan standar (juga tidak akan pernah ada, itulah sebabnya penghentian IETF diperdebatkan di sini), "ACME-" untuk namespace ke perusahaan "ACME" Anda atau aplikasi tertentu, dan "ClientData" dapat menjadi apa pun nama semantik yang kamu suka. :)
minggu

5
@DarrelMiller ... maka rekomendasi untuk menggunakan X-ACMECO-WIDGET-FOO. Saya bersikeras bahwa, untuk pertanyaan OP seperti yang ditanyakan, penggunaan X- sama sekali tidak bertentangan dengan yang ditunjukkan oleh RFC-6648 dan sejenisnya. Jika Anda seorang vendor yang menyediakan kerangka kerja, pustaka, atau modul untuk digunakan dalam proyek orang lain, itu cerita yang berbeda, dan tentu saja mengikuti RFC menjadi huruf T. Tapi itu hanya diperdebatkan untuk aplikasi satu kali saja, di mana custom Konvensi penamaan header khusus aplikasi secara efektif sepenuhnya merupakan API pribadi. Bagaimana mereka akan berbenturan dengan nama "orang lain"? Siapa itu?
minggu

11
Sejujurnya saya mengalami sedikit kesulitan memahami alasan RFC. Memang, jika dan ketika parameter distandarisasi, akan ada versi x dan non-x. Itu hanya masalah jika perilaku versi x dan non-x identik. Saya tersandung di sini karena saya ingin menambahkan tajuk "atas nama" ke API saya. Ini bisa menjadi publik suatu hari nanti (karena ini adalah kasus penggunaan umum). Jika saya menggunakan "On-Behalf-Of" dan suatu hari mereka menambahkan itu sebagai header standar, apa kemungkinan semantik saya akan identik dengan yang standar?
fool4jesus

62

Format untuk header HTTP didefinisikan dalam spesifikasi HTTP. Saya akan berbicara tentang HTTP 1.1, yang spesifikasinya adalah RFC 2616 . Di bagian 4.2, 'Header Pesan', struktur umum header didefinisikan:

   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>

Definisi ini bersandar pada dua pilar utama, token dan TEXT. Keduanya didefinisikan di bagian 2.2, 'Aturan Dasar'. Token adalah:

   token          = 1*<any CHAR except CTLs or separators>

Pada gilirannya bertumpu pada CHAR, CTL dan pemisah:

   CHAR           = <any US-ASCII character (octets 0 - 127)>

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

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

TEXT adalah:

   TEXT           = <any OCTET except CTLs,
                    but including LWS>

Di mana LWS adalah ruang putih linier, yang definisinya tidak akan saya buat, dan OCTET adalah:

   OCTET          = <any 8-bit sequence of data>

Ada catatan yang menyertai definisi:

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

Jadi, dua kesimpulan. Pertama, jelas bahwa nama header harus terdiri dari subset karakter ASCII - alfanumerik, beberapa tanda baca, tidak banyak lagi. Kedua, tidak ada dalam definisi nilai header yang membatasi ke ASCII atau mengecualikan karakter 8-bit: itu secara eksplisit terdiri dari oktet, dengan hanya karakter kontrol yang dilarang (perhatikan bahwa CR dan LF dianggap sebagai kontrol). Selanjutnya, komentar pada produksi TEXT menyiratkan bahwa oktet harus ditafsirkan sebagai ISO-8859-1, dan bahwa ada mekanisme pengkodean (yang mengerikan, kebetulan) untuk mewakili karakter di luar pengkodean itu.

Jadi, untuk menanggapi @BalusC secara khusus, cukup jelas bahwa menurut spesifikasi, nilai header ada di ISO-8859-1. Saya telah mengirim karakter high-8859-1 (khususnya, beberapa vokal beraksen seperti yang digunakan dalam bahasa Prancis) dalam tajuk dari Tomcat, dan meminta mereka diinterpretasikan dengan benar oleh Firefox, jadi sampai batas tertentu, ini berfungsi dalam praktiknya maupun dalam teori (walaupun ini adalah tajuk Lokasi, yang berisi URL, dan karakter ini tidak sah di URL, jadi ini sebenarnya ilegal, tetapi di bawah aturan yang berbeda!).

Yang mengatakan, saya tidak akan bergantung pada ISO-8859-1 yang bekerja di semua server, proksi, dan klien, jadi saya akan tetap berpegang pada ASCII sebagai masalah pemrograman defensif.


3
Spesifikasi HTTP yang lebih baru, RFC7230 mengatakan, "Bidang header yang baru didefinisikan harus membatasi nilai bidangnya menjadi oktet US-ASCII."
Robert Tupelo-Schneck

23

RFC6648 merekomendasikan agar Anda menganggap bahwa tajuk khusus Anda "mungkin menjadi terstandarisasi, umum, yang digunakan secara umum, atau dapat digunakan di berbagai implementasi." Oleh karena itu, disarankan untuk tidak awalan dengan "X-" atau konstruksi serupa.

Namun, ada pengecualian "ketika sangat tidak mungkin [tajuk Anda] akan distandarisasi." Untuk tajuk "implementasi khusus dan penggunaan pribadi" seperti itu, RFC mengatakan ruang nama seperti awalan vendor dibenarkan.


6
"RFC6648 merekomendasikan agar Anda menganggap bahwa tajuk khusus Anda" mungkin menjadi terstandarisasi, umum, digunakan secara umum, atau dapat digunakan di berbagai implementasi. "Saya pikir ini memberikan alasan untuk menggunakan X-awalan karena kemungkinan besar sesuatu tanpa awalan apa pun akan menjadi standar.
Konrad

@ Konrad Jika Anda menganggap tajuk orang lain yang serupa (bukan tajuk Anda) mungkin menjadi standar, Anda dapat menghindari konflik dengan X-, tetapi itu asumsi yang berbeda dari yang diambil RFC6648. Pengecualian RFC memperhitungkan potensi konflik antara header standar di masa depan dan header dari vendor lain yang teknologinya dapat diintegrasikan dengan Anda melalui merger perusahaan, dll. Itulah sebabnya pengecualian tersebut meminta awalan vendor.
Edward Brey

17

Memodifikasi, atau lebih tepatnya, menambahkan header HTTP tambahan adalah alat debugging kode yang hebat jika tidak ada yang lain.

Ketika permintaan URL mengembalikan pengalihan atau gambar, tidak ada "halaman" html untuk menulis sementara hasil kode debug ke - setidaknya tidak satu yang terlihat di browser.

Salah satu pendekatan adalah menulis data ke file log lokal dan melihat file itu nanti. Cara lain adalah menambahkan sementara HTTP header yang mencerminkan data dan variabel yang sedang di-debug.

Saya secara teratur menambahkan header HTTP tambahan seperti X-fubar-somevar: atau X-testing-someresult: untuk menguji berbagai hal - dan telah menemukan banyak bug yang seharusnya sangat sulit dilacak.


2
Kenapa dia harus menggunakan "standar" ini? Header bekerja sama. Bahkan dengan awalan "WHO_EVER_READS_THIS_IS_DUMB_" ...
Jan

16

Registri nama bidang header didefinisikan dalam RFC3864 , dan tidak ada yang istimewa dengan "X-".

Sejauh yang saya tahu, tidak ada pedoman untuk header pribadi; ragu, hindari mereka. Atau lihat Kerangka Ekstensi HTTP ( RFC 2774 ).

Akan menarik untuk memahami lebih banyak tentang use case; mengapa informasi tidak dapat ditambahkan ke badan pesan?


13
Alasan utama saya mempertimbangkan beberapa tajuk ubahsuaian adalah agar saya dapat membuat keputusan perutean tanpa harus menguraikan badan ...
Rozwel
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.