Pencarian header HTTP

Pencarian header HTTP adalah alat gratis yang mengambil semua header respons HTTP yang dikembalikan oleh sebuah URL untuk permintaan GET biasa.

Apa itu header respons HTTP?

Header respons HTTP adalah metadata yang dikirim server web sebelum isi respons, misalnya halaman HTML, gambar, atau dokumen JSON. Header ini memberi tahu klien cara menafsirkan, menyimpan dalam cache, mengalihkan, atau mengamankan respons.

Respons HTTP/1.x biasanya diawali baris status HTTP, lalu diikuti header. Dalam HTTP/2 dan HTTP/3, status yang setara disampaikan melalui pseudo-header :status. Secara teknis, baris status HTTP/1.x terpisah dari header, tetapi biasanya ditampilkan bersamanya karena menunjukkan apakah permintaan berhasil. Status 200 berarti sumber daya berhasil dikembalikan, 301 atau 302 menunjukkan pengalihan, 404 berarti sumber daya tidak ditemukan, dan 500 menunjukkan kesalahan di sisi server.

Header dapat berasal dari server asal, proksi balik, atau jaringan penayangan konten seperti Cloudflare. Beberapa header ditambahkan atau dihapus saat respons melewati sistem tersebut. Karena itu, hasilnya mungkin menggambarkan lebih dari sekadar aplikasi yang membuat halaman.

Bagaimana cara memeriksa header HTTP?

Masukkan URL lengkap yang ingin diperiksa, termasuk skemanya, misalnya https://www.example.com/account. Alat ini mengirim permintaan GET biasa dari servernya, lalu menampilkan header HTTP yang diterima dari URL tersebut.

Agar perbandingan header respons akurat, gunakan persis setiap variasi URL yang ingin diperiksa. Header untuk http://example.com, https://example.com, dan https://www.example.com dapat berbeda karena setiap alamat mungkin memiliki pengalihan, aturan cache, dan konfigurasi server tersendiri.

Sintaks URL juga memengaruhi permintaan:

• Spasi tidak valid sebagai karakter mentah dalam URL dan biasanya perlu dikodekan dengan percent-encoding, umumnya sebagai %20 di dalam path.
• ? menandai awal komponen kueri, sedangkan & dan = umum digunakan dalam pengodean kueri bergaya formulir, tetapi tidak selalu memiliki fungsi tersebut di setiap string kueri.
• Nama domain beraksen dan non-Latin diproses menggunakan IDNA dan direpresentasikan sebagai A-label ASCII, yang biasanya diawali xn--. Sementara itu, karakter path umumnya dikodekan menjadi byte UTF-8, lalu diberi percent-encoding.
• Fragmen yang diawali # ditangani oleh browser dan tidak dikirim dalam permintaan HTTP.
• Tidak ada batas maksimum panjang URL yang berlaku secara universal. URL yang sangat panjang dapat ditolak oleh server, proksi, atau aplikasi.

Bagaimana cara membaca hasil header HTTP?

Periksa header yang berkaitan dengan masalah yang sedang ditelusuri. Nama header tidak membedakan huruf besar dan kecil, meskipun sintaks nilainya dapat membedakannya.

Header lain dapat bersifat khusus untuk aplikasi tertentu. Misalnya, Access-Control-Allow-Origin mengatur origin mana yang boleh membaca respons melalui permintaan lintas origin di browser. Header Server mungkin menyebutkan perangkat lunak atau proksi, tetapi tidak dapat dijadikan bukti pasti tentang platform yang mendasarinya karena administrator dapat mengubah atau menghapusnya.

Contoh pemecahan masalah

Masalah pengalihan adalah salah satu alasan umum untuk memeriksa header. Misalnya, https://example.com/old-page mengembalikan status 301 dengan Location: https://example.com/new-page. Artinya, server meminta klien mengakses alamat baru tersebut. Memeriksa setiap tujuan secara berulang dapat mengungkap perulangan pengalihan atau perpindahan tak terduga antara HTTP dan HTTPS.

Jika halaman lama masih muncul di balik Cloudflare atau CDN lain, periksa Cache-Control, Age, ETag, dan header cache khusus penyedia yang tersedia. Nilai Age yang besar menunjukkan usia terhitung dari respons dalam cache, yang mungkin mencakup waktu di cache hulu, bukan lamanya respons disimpan oleh perantara tertentu. Nilai ini tidak membuktikan bahwa setiap cache regional menyimpan versi yang sama.

Jika API berfungsi dalam skrip sisi server tetapi gagal di browser, periksa Content-Type dan header respons CORS, termasuk Access-Control-Allow-Origin. Endpoint JSON yang mengembalikan text/html mungkin sebenarnya menyajikan halaman kesalahan atau layar login. Tanpa izin lintas origin, browser dapat memblokir akses meskipun server mengembalikan status 200.

Header juga dapat membantu memeriksa situs yang tampak tidak tersedia. Respons 503 mengarah pada kemungkinan gangguan sementara di server atau layanan hulu, sedangkan 404 berarti path yang diminta tidak ditemukan. Namun, header tidak dapat mendiagnosis semua kegagalan. Jika resolusi DNS, koneksi TCP, atau negosiasi TLS gagal sebelum respons HTTP terbentuk, mungkin tidak ada header respons yang bisa diperiksa. Ping dapat digunakan untuk memeriksa konektivitas secara terpisah, sedangkan Pemeriksa HTTP/2 dapat memeriksa dukungan protokol.

Mengapa hasil header yang benar masih terlihat keliru?

Hasil yang benar dapat berbeda dari yang terlihat di browser karena cache, catatan DNS, dan konteks permintaan mungkin mengarahkan kedua permintaan ke respons yang berbeda. Pencarian ini dijalankan di server, sehingga permintaan dapat mencapai node CDN yang berbeda atau mendeteksi catatan DNS yang baru diubah lebih cepat maupun lebih lambat daripada jaringan lokalmu.

Browser juga mengirim cookie, jenis konten yang diterima, bahasa, dan validator cache miliknya sendiri. Karena itu, halaman WordPress saat pengguna sudah login mungkin mengembalikan aturan cache yang berbeda dibandingkan permintaan anonim dari server. Perutean geografis dan sistem pengelolaan bot juga dapat mengubah respons berdasarkan jaringan asal atau header permintaan.

Setelah DNS diubah, resolver yang menyimpan cache dapat terus menggunakan catatan lama hingga masa berlakunya berakhir. Setelah lalu lintas mencapai server baru, objek CDN lama atau cache browser mungkin masih menampilkan konten sebelumnya. Periksa host yang di-resolve secara terpisah, bersihkan cache jika perlu, dan bandingkan URL yang sama persis. Jangan berasumsi bahwa setiap nama host memakai konfigurasi yang sama.

Pertanyaan umum

Apakah alat ini menampilkan header permintaan?

Tidak. Alat ini mengambil header respons yang dikembalikan oleh URL untuk permintaan GET biasa. Header permintaan adalah metadata yang dikirim ke server. Untuk memeriksanya secara lengkap, gunakan alat pengembang browser, log server, atau klien baris perintah secara terpisah.

Apakah URL yang dimasukkan ke alat ini tetap privat?

Pencarian dilakukan di server. Inputmu dikirim ke server tersebut melalui HTTPS dan tidak disimpan. Hindari memasukkan URL yang berisi kata sandi, token akses, atau parameter kueri sensitif karena server tujuan juga akan menerima nilai tersebut saat permintaan dikirim.

Apakah header HTTP bisa menjelaskan peringatan sertifikat?

Biasanya tidak jika hanya diperiksa sendiri. Koneksi TLS dibuat sebelum respons HTTP dikirim. Karena itu, sertifikat kedaluwarsa, nama host yang tidak cocok, atau penerbit yang tidak dipercaya dapat menyebabkan tidak adanya header yang dikembalikan. Periksa sertifikat beserta rantai sertifikatnya secara terpisah jika peringatan browser muncul sebelum halaman dimuat.

Mengapa ada beberapa header Set-Cookie?

Satu respons dapat menetapkan lebih dari satu cookie, dan setiap cookie menggunakan kolom Set-Cookie sendiri. Jangan menggabungkannya seolah-olah merupakan daftar yang dipisahkan koma karena tanggal kedaluwarsa cookie juga dapat mengandung koma. Periksa domain, path, dan atribut keamanan setiap cookie secara terpisah.

Bisakah hasilnya dibandingkan dengan curl?

Bisa. Perintah seperti curl -D - https://example.com/ -o /dev/null mencetak header respons dan membuang isi respons. Versi curl, header permintaan, pengaturan pengalihan, dan lokasi jaringan dapat menghasilkan respons yang berbeda. Jadi, samakan kondisi tersebut sebelum menganggap perbedaannya sebagai gangguan server.