Header HTTP khusus: konvensi penamaan

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 :)

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

...

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

4. Rekomendasi untuk Desainer Protokol

...

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

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

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

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.

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.

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.

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.

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?