Perintah curl Linux: periksa respons dan status HTTP

Perintah curl mentransfer data dari atau ke URL dan dapat memeriksa header, mengunduh berkas, serta mengakses API. Untuk HTTP, bedakan status respons server dari kode keluar curl: respons 404 atau 500 dapat diterima dengan baik sehingga kode keluar bawaan tetap 0.

Secara bawaan, isi respons ditulis ke keluaran standar. -o menyimpannya ke berkas, -L mengikuti pengalihan, dan -f meminta curl memperlakukan status HTTP 400 ke atas sebagai kesalahan. Pilih bentuk sesuai tujuan pemeriksaan, lalu periksa isi yang diterima bila keberhasilan aplikasi bergantung pada isinya.

Sintaks dan lingkungan

curl [OPSI] URL

OPSI adalah penanda. Jalankan curl --version untuk memeriksa versi, protokol, dan fitur build yang tersedia, lalu baca man curl untuk sistem Anda. Manual daring dapat menjelaskan opsi yang belum tersedia pada versi lokal.

Contoh berikut menggunakan sintaks shell Linux. Tulis URL yang mengandung karakter khusus seperti & atau ? di dalam tanda kutip agar shell tidak menafsirkannya sebagai operator. Mulailah dengan URL HTTPS yang Anda kenal dan gunakan direktori kerja yang sesuai sebelum menyimpan hasil.

Periksa header dengan HEAD

curl -I https://example.com/

-I mengirim permintaan HEAD pada HTTP, sehingga menampilkan header tanpa mengambil isi halaman. Baca baris status dan header yang relevan, misalnya Content-Type atau Location. Hasil ini bukan pemeriksaan isi halaman.

Sebagian server membatasi HEAD atau memperlakukannya berbeda dari GET. Jika HEAD ditolak, jangan langsung menyatakan URL tidak ada; ulangi dengan GET dan periksa status serta isinya. Mengganti HEAD menjadi GET tidak berarti perlu mematikan verifikasi sertifikat.

Ambil isi dan ikuti pengalihan

curl -fL https://example.com/

-L mengikuti respons pengalihan yang menunjuk ke lokasi baru, sedangkan -f menekan isi respons kesalahan HTTP dan biasanya menghasilkan kode keluar 22 untuk status 400 ke atas. Tanpa -L, curl tidak otomatis mengambil isi tujuan akhir pengalihan.

Perintah ini menampilkan isi respons, bukan otomatis baris statusnya. Untuk menampilkan header bersama isi, gunakan -i; untuk status yang mudah dibaca skrip, gunakan -w seperti contoh di bawah. Pada autentikasi, terutama 401 atau 407, manual memperingatkan bahwa -f bukan pemeriksaan yang sepenuhnya menjamin semua respons gagal tertangkap.

--fail-with-body merupakan alternatif saat isi kesalahan perlu disimpan sambil tetap mendapatkan kegagalan HTTP. Opsi itu tersedia sejak curl 7.76.0 dan tidak digabungkan dengan -f. Isi kesalahan tetap perlu diperiksa sebelum dimasukkan ke log karena dapat memuat informasi sensitif.

Simpan hasil ke berkas

curl -fL -o example.html https://example.com/

-o menulis isi respons ke example.html dalam direktori kerja saat ini. Periksa lokasi kerja dan pastikan tidak ada berkas penting dengan nama yang sama, karena keluaran dapat menimpa berkas yang sudah ada. Nama berkas tidak membuktikan isinya HTML yang diharapkan.

Setelah transfer, periksa kode keluar, isi berkas, serta tipe data yang semestinya. Berkas yang ada setelah proses gagal dapat berupa hasil lama atau hasil parsial; keberadaan berkas saja bukan bukti unduhan lengkap. Untuk artefak yang menyediakan checksum atau tanda tangan resmi, verifikasi dengan nilai dari penerbit tepercaya.

Cetak status HTTP tanpa isi

curl -sS -o /dev/null -w '%{http_code}\n' https://example.com

-s menyembunyikan meter kemajuan dan pesan kesalahan biasa, sementara -S mengaktifkan kembali pesan kesalahan ketika digunakan bersama -s. -o /dev/null membuang isi di lingkungan Linux, dan -w mencetak status HTTP ke keluaran standar setelah transfer.

Contoh status dari respons sukses:

200

200 adalah status HTTP sukses, tetapi belum membuktikan isi, autentikasi, atau hasil bisnis sesuai harapan. Bentuk contoh ini memakai GET, tidak mengikuti pengalihan karena tidak memakai -L, dan tidak mengubah 404 menjadi kegagalan curl karena tidak memakai -f.

Jika tidak ada status HTTP yang diterima, keluaran status dapat berupa 000. Itu bukan status yang dikirim server. Baca pula pesan kesalahan dan kode keluar curl untuk membedakan kegagalan DNS, koneksi, timeout, atau TLS. Dalam skrip shell, ambil $? segera setelah curl; perintah berikutnya akan mengganti nilai tersebut.

Dengan -L, status yang dicetak mengacu pada respons HTTP terakhir yang diterima dalam rantai. Tetap periksa kode keluar: menerima suatu status tidak menjamin seluruh transfer berakhir tanpa masalah.

Opsi utama

-O tidak otomatis mengikuti nama yang dikirim dalam Content-Disposition; itu memerlukan pengaturan lain. Untuk mengendalikan lokasi dan nama hasil, -o lebih eksplisit. Opsi tambahan seperti --connect-timeout dan --max-time dapat membatasi waktu koneksi atau transfer; pilih batas berdasarkan kebutuhan layanan dan tangani kegagalannya.

Rincian perilaku, versi penambahan opsi, dan kode keluar tersedia pada manual resmi curl.

Jaga kredensial dan verifikasi TLS

Hindari menuliskan token rahasia langsung pada baris perintah karena dapat masuk ke riwayat shell atau terlihat pada daftar proses. Jika menggunakan berkas konfigurasi atau masukan terlindungi yang didukung curl, batasi aksesnya. Redaksi token, cookie, serta data sensitif sebelum menyimpan atau membagikan keluaran rinci.

Periksa tujuan pengalihan saat memakai header sensitif. Jangan menganggap semua header khusus otomatis aman terhadap perpindahan host. Jangan menyalurkan skrip dari URL yang belum diperiksa langsung ke shell.

-k mematikan verifikasi sertifikat TLS. Untuk kesalahan sertifikat, periksa nama host, waktu sistem, rantai sertifikat, dan sumber sertifikat tepercaya yang benar. Mematikan pemeriksaan itu menghilangkan perlindungan identitas server dan bukan langkah bawaan untuk memperbaiki koneksi.

FAQ

Mengapa curl mengembalikan 0 setelah menerima 404?

curl dapat berhasil mentransfer respons kesalahan HTTP. Jika skrip perlu menolak kesalahan HTTP, pertimbangkan -f atau --fail-with-body serta periksa status dan isi yang dibutuhkan aplikasi.

Apakah -I yang ditolak berarti URL tidak ada?

Tidak selalu. Server dapat menolak HEAD sambil melayani GET. Ulangi dengan metode yang sesuai, lalu baca status dan respons tanpa menonaktifkan verifikasi TLS.