Pertanyaan Tajuk HTTP khusus: konvensi penamaan


Beberapa pengguna kami meminta kami untuk menyertakan data relatif ke akun mereka di Header HTTP permintaan yang kami kirimkan kepada mereka, 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 penggunaan pintar apa pun yang Anda temukan di web; Kami mencoba menerapkan ini menggunakan apa yang terbaik di luar sana sebagai target :)


866
2017-08-24 21:59


asal


Jawaban:


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

3. Rekomendasi untuk Kreator Parameter Baru

...

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

4. Rekomendasi untuk Desainer Protokol

...

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

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

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

Perhatikan bahwa "SEHARUSNYA TIDAK" ("putus asa") tidak sama dengan "TIDAK HARUS" ("terlarang"), lihat juga RFC 2119 untuk spesifikasi lain pada kata kunci tersebut. Dengan kata lain, Anda dapat tetap menggunakan header "X-", tetapi tidak disarankan dan Anda tidak boleh mendokumentasikannya sebagai standar publik.


Pada Juni 2011, yang pertama Draft IETF telah diposkan ke mencela rekomendasi untuk menggunakan awalan "X-" untuk header non-standar. Alasannya adalah bahwa ketika header non-standar diawali dengan "X-" menjadi standar, menghapus awalan "X-" memecah kompatibilitas mundur, memaksa protokol aplikasi untuk mendukung kedua nama (misalnya, x-gzip & gzip sekarang setara). Jadi, rekomendasinya adalah hanya memberi nama mereka secara pantas tanpa awalan "X-".


Rekomendasi itu aku s  adalah untuk memulai nama mereka dengan "X-". Misalnya. X-Forwarded-For, X-Requested-With. Ini juga disebutkan dalam a.o. bagian 5 dari RFC 2047.


956
2017-08-24 22:02



Pertanyaan itu mengandung pembacaan ulang. Pertanyaan sebenarnya yang diajukan tidak serupa dengan awalan vendor dalam properti CSS, di mana pemeriksaan dan pemikiran di masa mendatang tentang dukungan vendor dan standar resmi adalah tepat. Pertanyaan sebenarnya yang ditanyakan lebih mirip dengan memilih nama parameter kueri URL. Tidak ada yang harus peduli apa mereka. Tetapi penamaan nama yang kustom adalah hal yang sangat valid - dan umum, dan benar - benar dilakukan.

Alasan:
Ini adalah tentang konvensi antara pengembang untuk custom, header khusus aplikasi - "data yang relevan dengan akun mereka"- yang tidak ada hubungannya dengan vendor, badan standar, atau protokol yang akan diterapkan oleh pihak ketiga, kecuali bahwa pengembang tersebut hanya perlu menghindari nama-nama header yang mungkin memiliki maksud lain yang digunakan oleh server, proksi atau klien. Untuk ini alasan, "X-Gzip / Gzip" dan "X-Forwarded-For / Forwarded-For" contoh yang diberikan adalah diperdebatkan. Pertanyaan yang diajukan adalah tentang konvensi dalam konteks API pribadi, serupa dengan konvensi penamaan parameter URL kueri. masalah preferensi dan pengaturan nama, kekhawatiran tentang "X-ClientDataFoo" didukung oleh proxy atau vendor tanpa "X" jelas salah tempat.

Tidak ada yang istimewa atau ajaib tentang awalan "X-", tetapi membantu untuk memperjelas bahwa ini adalah tajuk khusus. Faktanya, RFC-6648 dkk membantu mendukung kasus untuk penggunaan awalan "X-", karena - karena vendor dari klien HTTP dan server mengabaikan awalan - aplikasi khusus Anda, private-API, personal-data- mekanisme passing menjadi lebih baik-terisolasi terhadap tabrakan nama-ruang dengan sejumlah kecil nama-nama header yang dilindungi resmi. Yang mengatakan, preferensi dan rekomendasi pribadi saya adalah untuk melangkah lebih jauh dan lakukan misalnya "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 benar-benar berbeda: (A) vendor yang memperkenalkan fitur baru yang berlaku secara global seperti "Teruskan-untuk" di satu sisi, vs. (B) pengembang aplikasi yang meneruskan string khusus aplikasi ke / dari klien dan server. Spesifikasinya hanya berkaitan dengan yang pertama, (A). Pertanyaannya di sini adalah apakah ada konvensi untuk (B). Ada. Mereka melibatkan pengelompokan parameter bersama-sama menurut abjad, dan memisahkan mereka dari banyak header yang relevan dengan standar (A). Menggunakan awalan "X-" atau "X-ACME-" adalah nyaman dan sah untuk (B), dan tidak bertentangan dengan (A). Semakin banyak vendor berhenti menggunakan "X-" untuk (A), yang lebih bersih-berbeda (B) yang akan menjadi.

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

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


413
2017-10-28 16:39



Format untuk header HTTP didefinisikan dalam spesifikasi HTTP. Saya akan berbicara tentang HTTP 1.1, yang spesifikasinya 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 bertumpu 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>

Beristirahat 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 saya tidak akan mereproduksi, 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, sudah jelas bahwa header nama harus terdiri dari subset karakter ASCII - alfanumerik, beberapa tanda baca, tidak banyak yang lain. Kedua, tidak ada definisi dari sebuah header nilaiyang membatasi ke ASCII atau mengecualikan karakter 8-bit: ini secara eksplisit terdiri dari oktet, dengan hanya karakter kontrol yang dibatasi (perhatikan bahwa CR dan LF dianggap sebagai kontrol). Lebih jauh lagi, komentar pada produksi TEXT menyiratkan bahwa oktet harus ditafsirkan sebagai dalam 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 dalam ISO-8859-1. Saya telah mengirim tinggi 8859-1 karakter (khususnya, beberapa vokal beraksen seperti yang digunakan dalam bahasa Prancis) di header dari Tomcat, dan telah mereka menafsirkan dengan benar oleh Firefox, sehingga sampai batas tertentu, ini bekerja dalam praktek maupun dalam teori (meskipun ini adalah header 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 bekerja di semua server, proksi, dan klien, jadi saya akan tetap berpegang pada ASCII sebagai masalah pemrograman defensif.


56
2017-08-25 19:49



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 pada Kerangka Ekstensi HTTP (RFC 2774).

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


15
2017-08-25 06:44



Memodifikasi, atau lebih tepatnya, menambahkan header HTTP tambahan adalah alat debug kode bagus 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 pun yang terlihat di browser.

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

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


14
2017-07-04 09:29



RFC6648 menyarankan agar Anda berasumsi bahwa header khusus Anda "mungkin menjadi standar, publik, biasanya digunakan, atau dapat digunakan di berbagai penerapan." Oleh karena itu, disarankan untuk tidak memberi awalan dengan "X-" atau konstruksi serupa.

Namun, ada pengecualian "ketika sangat tidak mungkin bahwa [header Anda] akan distandardisasi." Untuk header "implementasi-spesifik dan penggunaan pribadi" seperti itu, RFC mengatakan ruang nama seperti awalan vendor dibenarkan.


1
2017-07-24 13:50