RFC 9110: Memahami Standar HTTP Modern yang Wajib Dipahami Developer

Hampir semua aktivitas di web setiap hari bertumpu pada satu protokol yang jarang kita pikirkan: HTTP. Saat Anda membuka aplikasi, memanggil API, atau mengonfigurasi reverse proxy, semuanya berjalan di atas semantik yang tertulis dalam dokumen standar IETF. Sejak Juni 2022, fondasi tersebut dimuat dalam satu dokumen resmi bernama RFC 9110 yang berjudul “HTTP Semantics”, dan kini menjadi rujukan tunggal untuk semua versi HTTP.

Dokumen ini penting karena menggantikan sejumlah spesifikasi lama yang selama ini tersebar, seperti RFC 7230 sampai 7235, sehingga tidak ada lagi kerancuan tentang mana rujukan yang benar. Sayangnya, banyak developer masih menulis kode berdasarkan kebiasaan turun-temurun dari spesifikasi lama, padahal konsep seperti method idempotent, status code, dan penanganan field header kini punya definisi yang jauh lebih presisi. Artikel ini merangkum poin-pokok standar HTTP modern beserta dampaknya pada pekerjaan sehari-hari.

Mengapa RFC 9110 Lahir

Sebelum 2022, spesifikasi HTTP/1.1 yang menjadi acuan adalah RFC 7230–7235. Seiring berjalannya waktu, banyak pasal di dalamnya bertele-tele, tumpang-tindih, atau sudah usang — misalnya aturan tentang connection management yang nyatanya hampir tidak relevan lagi di era TLS yang lazim. IETF kemudian memecah spesifikasi itu menjadi dua bagian yang lebih rapi:

• RFC 9110 (HTTP Semantics) — memuat elemen protokol yang sama untuk semua versi HTTP: URI, method, status code, field header, content negotiation, hingga mekanisme conditional request.
• RFC 9112 (HTTP/1.1) — khusus mengatur wire format HTTP/1.1 seperti framing pesan dan chunked transfer.

Pemisahan semacam ini membuat penambahan versi baru tidak lagi mengulang definisi dasar. HTTP/2 dan HTTP/3 cukup mendefinisikan cara enkapsulasi pesannya masing-masing, sementara makna method dan status code tetap merujuk pada satu sumber yang sama. Selain itu, RFC 9110 juga resmi menggabungkan sejumlah spesifikasi tambahan yang sebelumnya berdiri sendiri, seperti RFC 7538 tentang status code 308 dan RFC 7694 tentang encoding field header.

Isi utama dokumen semantik HTTP

Bagi yang belum pernah membaca RFC secara utuh, isi standar HTTP modern ini mencakup:

1. Arsitektur HTTP: peran client, server, intermediary, dan cache.
2. Sistem penomoran URI beserta skema `http` dan `https`.
3. Definisi method dan status code beserta propertinya.
4. Aturan field header: penulisan, penggabungan nilai, hingga batas ukuran.
5. Mekanisme content negotiation dan conditional request.

Method: Aman, Idempotent, dan Cacheable

Salah satu kontribusi paling praktis dari RFC 9110 adalah definisi yang ketat tentang tiga properti method.

Safe

Method disebut safe apabila semantiknya pada dasarnya read-only — client tidak mengharapkan perubahan state di server. GET, HEAD, OPTIONS, dan TRACE tergolong safe. Menariknya, standar ini mengakui bahwa server tetap boleh punya efek samping (misalnya mencatat log atau mencatat statistik), yang penting adalah client tidak meminta efek itu.

Konsekuensinya praktis: spider mesin pencari, pre-fetch cache, dan scanner keamanan bebas melakukan GET ke semua URL. Karena itu, URL seperti `page?do=delete` adalah desain yang salah menurut standar — aksi yang mengubah data wajib dilindungi sehingga tidak bisa dipicu lewat method safe.

Idempotent

Method idempotent adalah method yang efek yang dimaksudkan dari beberapa request identik yang berulang sama dengan efek satu request saja. Semua method safe otomatis idempotent, ditambah PUT dan DELETE. POST sengaja tidak idempotent.

Aturan ini bukan teori kosong. Ketika koneksi terputus sebelum response diterima, client boleh mengulang PUT atau DELETE secara otomatis tanpa risiko menduplikasi efek. Sebaliknya, mengulang POST yang gagal bisa berakibat data ganda — inilah alasan API pembayaran biasanya menerapkan idempotency key, dan alasan mengapa proxy dilarang mengulang request non-idempotent secara diam-diam.

Cacheable

Method juga menentukan apakah response-nya boleh disimpan cache. Semantik caching untuk GET, HEAD, dan POST didefinisikan di sini, meski pada praktiknya mayoritas implementasi cache hanya mendukung GET dan HEAD. Detail perilaku penyimpanan dan validasi kemudian diperinci di RFC 9111 (HTTP Caching) yang terbit serentak.

Status Code yang Lebih Tegas

RFC 9110 merapikan ratusan status code ke dalam lima kelas — dari 1xx informasional hingga 5xx server error. Beberapa klarifikasi penting yang sering luput:

• 303 (See Other) mengarahkan agar client melakukan GET ke URI lain, cocok untuk pola Post/Redirect/Get setelah pengiriman form.
• 308 (Permanent Redirect) dipromosikan menjadi status code standar penuh: seperti 301, tetapi metode request tidak boleh berubah.
• 405 (Method Not Allowed) wajib disertai header Allow yang memuat method yang didukung resource tersebut.
• 418 (I’m a teapot) bahkan tercatat resmi — bukan untuk dipakai serius, tetapi ditetapkan untuk mencegah kode status lain diambil alih demi lelucon.

Bagian conditional request juga menjadi lebih jelas: header If-Match, If-None-Match, dan If-Modified-Since memungkinkan client memverifikasi state sebelum aksi dilakukan, sehingga operasi seperti update konkuren terhindar dari kondisi lost update.

Field Header: Aturan yang Sering Dilanggar

Perubahan yang paling sering diabaikan developer justru di area field header. Satu hal yang menonjol adalah penggabungan field: beberapa nilai field dengan nama yang sama harus digabung menjadi satu dengan pemisah koma sebelum diolah. Contohnya, dua baris `Accept-Encoding: gzip` dan `Accept-Encoding: br` setara dengan `Accept-Encoding: gzip, br`.

Namun ada pengecualian, dan di sinilah banyak bug bersembunyi: field seperti Set-Cookie tidak boleh digabung begitu saja karena memakai tanda titik koma di dalam nilainya. Standar juga menetapkan bahwa field yang tidak dikenal harus tetap diteruskan oleh intermediary, aturan batas ukuran field untuk mencegah serangan resource exhaustion, serta deprecation cron user info pada URI `http://user:pass@host` yang lama dipakai untuk basic auth.

Dampak untuk Developer Sehari-hari

Meniadakan jarak antara spesifikasi dan praktik, berikut penerapan konkret dari standar ini:

• Desain API: jangan menaruh aksi berbahaya di query parameter yang diakses lewat GET; gunakan POST/DELETE dengan path resource yang jelas.
• Retry logic: aman mengulang GET, HEAD, PUT, dan DELETE; untuk POST, siapkan mekanisme idempotency key atau request ID sebelum memasang auto-retry.
• Gateway dan proxy: pahami bahwa middleware tidak boleh menggabungkan Set-Cookie, dan wajib meneruskan header yang tidak dikenal agar fitur baru tetap kompatibel.
• Redirect: gunakan 308 ketika client harus mempertahankan method (misalnya redirect endpoint API), bukan 301 yang berisiko mengubah POST menjadi GET di sebagian client.

Ketika tim Anda berdebat soal perilaku cache, retry, atau redirect, jawabannya kini cukup satu dokumen. Lengkapilah pemahaman Anda dengan membaca langsung dokumen HTTP Semantics di situs RFC Editor yang menjadi rujukan resmi bagi semua implementasi HTTP modern, dari browser hingga load balancer.

Kesimpulan

RFC 9110 menyatukan semantik HTTP yang sebelumnya terpecah di banyak dokumen menjadi satu standar yang ringkas dan presisi: aturan method beserta properti safe, idempotent, dan cacheable; kelas status code; serta ceruk penanganan field header yang kerap menjadi sumber bug. Memahami standar HTTP modern ini bukan sekadar formalitas — ia berpengaruh langsung pada keandalan API, keamanan aplikasi, dan perilaku caching di produksi. Jika pekerjaan Anda menyentuh HTTP dalam bentuk apa pun, menyisihkan waktu untuk membaca dokumen dasar ini adalah investasi kecil dengan dampak jangka panjang.

Foto sampul: Jordan Harrison di Unsplash.