Header HTTP yang tidak perlu

Header HTTP penting untuk mengontrol bagaimana cache dan browser memproses konten Anda. Tetapi banyak dari mereka yang digunakan secara salah atau tidak berarti, menghabiskan sumber daya tambahan pada saat kritis pemuatan halaman, dan mereka mungkin tidak berfungsi seperti yang Anda pikirkan. Dalam serangkaian artikel tentang praktik terbaik, pertama-tama kita akan melihat judul yang tidak perlu.

Sebagian besar pengembang menyadari header HTTP yang penting dan bermanfaat. Yang paling terkenal adalah Content-Type dan Content-Length , ini adalah header yang hampir universal. Namun baru-baru ini, header seperti Content-Security-Policy dan Strict-Transport-Security telah digunakan untuk meningkatkan Strict-Transport-Security , dan Link rel=preload untuk meningkatkan kinerja. Meskipun ada dukungan luas di peramban, hanya sedikit yang menggunakannya.

Pada saat yang sama, ada banyak tajuk berita yang sangat populer yang umumnya tidak baru dan tidak terlalu berguna. Kami dapat membuktikannya dengan bantuan HTTP Archive , sebuah proyek yang dijalankan oleh Google dan disponsori oleh Fastly, yang mengunduh 500.000 situs setiap bulan menggunakan WebPageTest dan mengunggah hasilnya ke BigQuery .

Berikut adalah 30 tajuk respons paling populer menurut Arsip HTTP (berdasarkan jumlah domain dalam arsip yang ditampilkan setiap tajuk), dan perkiraan kasar kegunaan masing-masing:

Berita utama	Pertanyaan	Domain	Status
tanggal	48779277	535621	Diperlukan protokol
tipe konten	47185627	533636	Biasanya dibutuhkan oleh browser
server	43057807	519663	Opsional
panjang konten	42388435	519118	Berguna
terakhir dimodifikasi	34424562	480294	Berguna
kontrol cache	36490878	412943	Berguna
etag	23620444	412370	Berguna
pengkodean konten	16194121	409159	Diperlukan untuk Konten Terkompresi
kedaluwarsa	29869228	360311	Opsional
x didukung oleh	4883204	211409	Opsional
pragma	7641647	188784	Opsional
opsi-bingkai-x	3670032	105846	Opsional
akses-kontrol-izinkan-asal	11335681	103596	Berguna
x-content-type-options	11071560	94590	Berguna
tautan	1212329	87475	Berguna
umur	7401415	59242	Berguna
x-cache	5275343	56889	Opsional
perlindungan x-xss	9773906	51810	Berguna
ketat-transportasi-keamanan	4259121	51283	Berguna
via	4020117	47102	Opsional
p3p	8282840	44308	Opsional
harapkan-ct	2685280	40465	Berguna
konten-bahasa	334081	37927	Kontroversial
versi x-aspnet	676128	33473	Opsional
akses-kontrol-izinkan-kredensial	2804382	30346	Berguna
tag-x-robot	179177	24911	Tidak masalah untuk browser
kompatibel dengan x-ua	489056	24811	Opsional
akses-kontrol-izinkan-metode	1626129	20791	Berguna
akses-kontrol-izinkan-tajuk	1205735	19120	Berguna

Mari kita lihat header opsional, mengapa kita tidak membutuhkannya, dan apa yang harus dilakukan.

Kesombongan (server, x-powered-by, via)

Anda bisa sangat bangga dengan pilihan perangkat lunak server Anda, tetapi kebanyakan orang tidak peduli. Dalam kasus terburuk, tajuk ini dapat mengungkapkan data sensitif, sehingga lebih mudah untuk menyerang situs Anda.

Server: apache
X-Powered-By: PHP/5.1.1
Via: 1.1 varnish, 1.1 squid

RFC7231 memungkinkan Anda untuk memasukkan header Server dalam respons server, yang menunjukkan perangkat lunak tertentu pada server yang digunakan untuk mengirimkan konten. Paling sering ini adalah string seperti "apache" atau "nginx". Meskipun judul diizinkan, itu opsional dan tidak terlalu berharga bagi pengembang atau pengguna akhir. Namun, hari ini ini adalah header server HTTP paling populer ketiga di Internet.

X-Powered-By adalah judul paling populer yang tidak ditentukan oleh standar apa pun dan memiliki tujuan yang serupa: biasanya menunjukkan platform aplikasi tempat server berjalan. Jawaban paling populer termasuk "ASP.net", "PHP" dan "Express". Sekali lagi, ini tidak membawa manfaat nyata dan hanya terjadi.

Mungkin lebih kontroversial dapat dianggap Via . Diperlukan ( menurut RFC7230 ) untuk menambahkan ke setiap proxy yang dilewati oleh permintaan - untuk mengidentifikasi proxy tersebut. Ini mungkin nama host proxy, tetapi lebih sering pengidentifikasi generik seperti "vegur", "varnish" atau "squid". Menghapus (atau tidak menambahkan) header seperti itu dapat menyebabkan siklus penerusan proxy . Tetapi menarik bahwa itu juga ditambahkan sebagai tanggapan terhadap jalur kembali ke browser - dan di sini ia hanya menjalankan fungsi informasi: tidak ada browser yang melakukan apa pun dengannya, jadi cukup aman untuk menyingkirkannya jika Anda mau.

Standar yang Sudah Tidak Berlaku (P3P, Kedaluwarsa, Opsi X-Frame, Kompatibel X-UA)

Header kategori lain adalah yang benar-benar menyebabkan efek pada browser, tetapi (sudah) bukan cara terbaik untuk mencapai efek ini.

P3P: cp="this is not a p3p policy"
Expires: Thu, 01 Dec 1994 16:00:00 GMT
X-Frame-Options: SAMEORIGIN
X-UA-Compatible: IE=edge

P3P adalah hal kecil yang menyenangkan. Saya tidak tahu apa itu. Bahkan lebih lucu, salah satu konten paling umum dari header P3P adalah "Ini bukan aturan P3P." Ya atau tidak?

Di sini, ceritanya kembali ke upaya untuk membakukan aturan privasi yang dapat dibaca mesin . Ada perbedaan pendapat tentang cara menampilkan data di browser, dan hanya satu browser yang menerapkan dukungan untuk tajuk ini - Internet Explorer. Tetapi bahkan di dalamnya, P3P tidak memiliki efek visual bagi pengguna; dia hanya harus hadir untuk memungkinkan akses ke cookie pihak ketiga dalam bingkai. Beberapa situs bahkan menetapkan aturan ketidakpatuhan P3P, seperti pada contoh di atas, meskipun melakukannya sangat dipertanyakan .

Tidak perlu dikatakan, membaca cookie pihak ketiga umumnya adalah ide yang buruk, jadi jika Anda tidak melakukannya, maka Anda tidak perlu mengatur header P3P !

Expires sangat populer mengingat Cache-Control telah lebih unggul daripada Expires selama lebih dari 20 tahun. Jika tajuk Cache-Control berisi arahan max-age , maka tajuk Expires apa pun dalam respons yang sama diabaikan. Tetapi sejumlah besar situs menetapkan kedua tajuk ini, dan Expires paling sering menetapkan tanggal Thu, 01 Dec 1994 16: 00: 00 GMT , sehingga kontennya tidak di-cache. Tentu saja, paling mudah untuk menyalin tanggal dari spesifikasi .



Tetapi tidak perlu melakukan ini. Jika Anda memiliki tajuk Expires dengan tanggal dari masa lalu, cukup gantilah dengan:

Cache-Control: no-store, private

( no-store adalah arahan yang terlalu ketat untuk tidak menulis konten ke penyimpanan persisten, jadi Anda mungkin lebih suka no-cache untuk kinerja yang lebih baik, misalnya, untuk menavigasi kembali / maju atau melanjutkan tab tidur di browser)

Beberapa alat validasi situs akan menyarankan Anda untuk menambahkan header X-Frame-Options dengan nilai 'SAMAORIGIN'. Ini memberi tahu browser bahwa Anda menolak untuk mengirim konten ke bingkai di situs lain: sebagai aturan, ini adalah pertahanan yang baik terhadap clickjacking . Tetapi efek yang sama dapat dicapai dengan tajuk lain dengan dukungan yang lebih konsisten dan perilaku yang lebih andal:

Content-Security-Policy: frame-ancestors 'self'

Ada manfaat tambahan di sini, karena Anda masih harus memberikan tajuk CSP karena alasan lain (selengkapnya tentang mereka nanti). Mungkin, di zaman kita, Anda dapat melakukannya tanpa X-Frame-Options .

Akhirnya, kembali ke IE9, Microsoft memperkenalkan "mode kompatibilitas" yang membuat halaman menggunakan mesin IE8 atau IE7. Bahkan dalam mode normal, browser berpikir bahwa versi mesin yang lebih lama mungkin diperlukan untuk rendering yang tepat. Heuristik ini tidak selalu berfungsi dengan benar, dan pengembang dapat menimpanya menggunakan header atau meta tag yang X-UA-Compatible dengan X-UA-Compatible . Bahkan, ini telah menjadi bagian standar dari banyak kerangka kerja seperti Bootstrap. Sekarang tajuk ini praktis tidak berguna: proporsi browser yang memahaminya sangat kecil. Dan jika Anda secara aktif mendukung situs, maka sangat tidak mungkin menggunakan teknologi yang akan meluncurkan mode kompatibilitas.

Data Debugging (Versi X-ASPNet, X-Cache)

Dalam beberapa hal, mengejutkan bahwa beberapa judul yang paling populer tidak disebutkan sama sekali dalam standar apa pun. Pada dasarnya, ini berarti bahwa ribuan situs web entah bagaimana setuju untuk menggunakan tajuk tertentu dengan cara tertentu.

X-Cache: HIT
X-Request-ID: 45a336c7-1bd5-4a06-9647-c5aab6d5facf
X-ASPNet-Version: 3.2.32
X-AMZN-RequestID: 0d6e39e2-4ecb-11e8-9c2d-fa7ae01bbebc

Bahkan, judul "tidak dikenal" ini tidak ditemukan oleh pengembang. Biasanya, ini adalah artefak dari penggunaan kerangka kerja server tertentu, perangkat lunak atau layanan dari pemasok tertentu (misalnya, header terakhir adalah khas untuk AWS).

Header X-Cache menambahkan Fastly (dan CDNs lainnya), bersama dengan header spesifik lainnya seperti X-Cache-Hits dan X-Served-By . Ketika debugging diaktifkan, lebih banyak ditambahkan, misalnya, Fastly-Debug-Path dan Fastly-Debug-TTL .

Header ini tidak dikenali oleh browser apa pun, dan penghapusannya tidak akan memengaruhi tampilan halaman sama sekali. Tetapi karena mereka dapat memberi Anda, pengembang, informasi yang berguna, Anda dapat menyimpannya.

Kesalahpahaman (Pragma)

Saya tidak berharap bahwa pada tahun 2018 saya harus menyebutkan header Pragma , tetapi menurut Arsip HTTP, masih di atas (tempat ke-11). Itu tidak hanya dinyatakan usang pada tahun 1997, tetapi tidak pernah dianggap sebagai header tanggapan, tetapi hanya sebagai bagian dari permintaan.

Pragma: no-cache

Namun demikian, ini sangat banyak digunakan sebagai header respons sehingga beberapa browser bahkan mengenalinya dalam konteks ini. Tetapi hari ini hampir tidak ada peluang bagi seseorang untuk memahami Pragma dalam konteks jawaban, tetapi tidak memahami Cache-Control . Jika Anda ingin menonaktifkan caching, yang Anda butuhkan adalah Cache-Control: no-store, private .

Non-Browser (X-Robots-Tag)

Satu tajuk dalam 30 teratas kami bukan tajuk untuk peramban. X-Robots-Tag dirancang untuk perayap seperti Google bot atau Bing. Karena tidak berguna untuk browser, Anda dapat mengatur jawaban seperti itu hanya untuk permintaan dari crawler. Atau Anda memutuskan bahwa ini membuat pengujian sulit atau melanggar ketentuan penggunaan mesin pencari.

Bug

Akhirnya, layak untuk diakhiri dengan menyebutkan kesalahan sederhana yang terhormat. Header Host masuk akal dalam permintaan , tetapi jika muncul dalam respons, maka server Anda mungkin tidak dikonfigurasi dengan benar (dan saya ingin tahu caranya). Namun, 68 domain di Arsip HTTP mengembalikan header Host dalam responsnya.

Menghapus header di server CDN tepi

Untungnya, jika situs Anda berjalan cepat bersama kami, maka menghapus header cukup sederhana menggunakan VCL . Jika Anda ingin membuat tim pengembangan benar-benar berguna untuk debugging, tetapi sembunyikan dari masyarakat umum, maka ini dapat dengan mudah dilakukan menggunakan cookie atau header HTTP yang masuk:

unset resp.http.Server;
unset resp.http.X-Powered-By;
unset resp.http.X-Generator;

if (!req.http.Cookie:debug && !req.http.Debug) {
unset resp.http.X-Amzn-RequestID;
unset resp.http.X-Cache;
}

Pada artikel selanjutnya saya akan berbicara tentang praktik terbaik untuk judul yang benar-benar dibutuhkan dan cara mengaktifkannya di server tepi CDN.