Dua Versi

Versi Indonesia

Satuan Tugas Rekayasa Internet (IETF) R. Fielding, Ed.

Permintaan Komentar: 9112 Adobe

STD: 99 M. Nottingham, Ed.

Usang: 7230 Cepat

Kategori: Jalur Standar J. Reschke, Ed.

ISSN: 2070-1721 hijaubyte

                                                               Juni 2022

                                HTTP/1.1

Abstrak

   Hypertext Transfer Protocol (HTTP) adalah aplikasi tanpa kewarganegaraan-

   protokol tingkat untuk informasi terdistribusi, kolaboratif, hiperteks

   sistem. Dokumen ini menentukan sintaks pesan HTTP/1.1,

   penguraian pesan, manajemen koneksi, dan keamanan terkait

   kekhawatiran.

   Dokumen ini menghapus sebagian RFC 7230.

Status Memo Ini

   Ini adalah dokumen Jalur Standar Internet.

   Dokumen ini merupakan produk dari Satuan Tugas Rekayasa Internet

   (IETF). Ini mewakili konsensus komunitas IETF. Memiliki

   menerima tinjauan publik dan telah disetujui untuk diterbitkan oleh

   Kelompok Pengarah Rekayasa Internet (IESG). Informasi lebih lanjut tentang

   Standar Internet tersedia di Bagian 2 RFC 7841.

   Informasi tentang status terkini dokumen ini, kesalahan apa pun,

   dan cara memberikan masukan mengenai hal tersebut dapat diperoleh di

   https://www.rfc-editor.org/info/rfc9112.

Pemberitahuan Hak Cipta

   Hak Cipta (c) 2022 IETF Trust dan orang-orang yang diidentifikasi sebagai

   penulis dokumen. Seluruh hak cipta.

   Dokumen ini tunduk pada BCP 78 dan Hukum IETF Trust

   Ketentuan Terkait Dokumen IETF

   (https://trustee.ietf.org/license-info) berlaku pada tanggal

   penerbitan dokumen ini. Harap tinjau dokumen-dokumen ini

   hati-hati, karena mereka menjelaskan hak dan batasan Anda dengan hormat

   ke dokumen ini. Komponen Kode yang diambil dari dokumen ini harus

   termasuk teks Lisensi BSD Revisi seperti yang dijelaskan dalam Bagian 4.e dari

   Percayai Ketentuan Hukum dan diberikan tanpa jaminan seperti yang dijelaskan

   di bawah Lisensi BSD Revisi.

   Dokumen ini mungkin berisi materi dari Dokumen IETF atau IETF

   Kontribusi diterbitkan atau tersedia untuk umum sebelum bulan November

   10, 2008. Orang yang mengendalikan hak cipta atas beberapa hal ini

   materi mungkin tidak memberikan hak kepada IETF Trust untuk mengizinkannya

   modifikasi materi tersebut di luar Proses Standar IETF.

   Tanpa memperoleh izin yang memadai dari orang yang mengendalikan

   hak cipta atas materi tersebut, dokumen ini tidak boleh diubah

   di luar Proses Standar IETF, dan karya turunannya boleh

   tidak boleh dibuat di luar Proses Standar IETF, kecuali untuk memformat

   untuk dipublikasikan sebagai RFC atau untuk diterjemahkan ke bahasa lain

   daripada bahasa Inggris.

Daftar isi

   1. Perkenalan

     1.1. Notasi Persyaratan

     1.2. Notasi Sintaks

   2. Pesan

     2.1. Format Pesan

     2.2. Penguraian Pesan

     2.3. Versi HTTP

   3. Jalur Permintaan

     3.1. metode

     3.2. Sasaran Permintaan

       3.2.1. bentuk asal

       3.2.2. bentuk absolut

       3.2.3. bentuk otoritas

       3.2.4. bentuk asterisk

     3.3. Merekonstruksi URI Target

   4. Baris Status

   5. Sintaks Bidang

     5.1. Penguraian Garis Lapangan

     5.2. Lipatan Garis Usang

   6. Isi Pesan

     6.1. Pengkodean Transfer

     6.2. Panjang Konten

     6.3. Panjang Badan Pesan

   7. Mentransfer Kode

     7.1. Pengkodean Transfer Terpotong

       7.1.1. Ekstensi Potongan

       7.1.2. Bagian Trailer Terpotong

       7.1.3. Penguraian kode Terpotong

     7.2. Transfer Kode untuk Kompresi

     7.3. Mentransfer Registri Pengkodean

     7.4. Menegosiasikan Kode Transfer

   8. Menangani Pesan yang Tidak Lengkap

   9. Manajemen Koneksi

     9.1. Pembentukan

     9.2. Mengaitkan Respon terhadap Permintaan

     9.3. Kegigihan

       9.3.1. Mencoba Ulang Permintaan

       9.3.2. perpipaan

     9.4. Konkurensi

     9.5. Kegagalan dan Batas Waktu

     9.6. Menangis

     9.7. Inisiasi Koneksi TLS

     9.8. Penutupan Koneksi TLS

   10. Melampirkan Pesan sebagai Data

     10.1. Jenis Media pesan/http

     10.2. Jenis Media aplikasi/http

   11. Pertimbangan Keamanan

     11.1. Pemisahan Respon

     11.2. Permintaan Penyelundupan

     11.3. Integritas Pesan

     11.4. Kerahasiaan Pesan

   12. Pertimbangan IANA

     12.1. Registrasi Nama Bidang

     12.2. Registrasi Jenis Media

     12.3. Registrasi Pengkodean Transfer

     12.4. Registrasi ID Protokol ALPN

   13. Referensi

     13.1. Referensi Peraturan

     13.2. Referensi Informasi

   Lampiran A. Kumpulan ABNF

   Lampiran B. Perbedaan antara HTTP dan MIME

     B.1. Versi MIME

     B.2. Konversi ke Bentuk Kanonik

     B.3. Konversi Format Tanggal

     B.4. Konversi Pengkodean Konten

     B.5. Konversi Pengkodean-Transfer-Konten

     B.6. MHTML dan Batasan Panjang Jalur

   Lampiran C. Perubahan dari RFC Sebelumnya

     C.1. Perubahan dari HTTP/0.9

     C.2. Perubahan dari HTTP/1.0

       C.2.1. Server Web Multihome

       C.2.2. Koneksi Tetap Hidup

       C.2.3. Pengenalan Transfer-Encoding

     C.3. Perubahan dari RFC 7230

   Ucapan Terima Kasih

   Indeks

   Alamat Penulis

1. Perkenalan

   Hypertext Transfer Protocol (HTTP) adalah aplikasi tanpa kewarganegaraan-

   protokol permintaan/respons tingkat yang menggunakan semantik yang dapat diperluas dan

   pesan deskriptif diri untuk interaksi fleksibel dengan berbasis jaringan

   sistem informasi hiperteks. HTTP/1.1 ditentukan oleh:

   * Dokumen ini

   * "Semantik HTTP" [HTTP]

   * "Caching HTTP" [CACHING]

   Dokumen ini menentukan bagaimana semantik HTTP disampaikan menggunakan

   Sintaks pesan HTTP/1.1, pembingkaian, dan manajemen koneksi

   mekanisme. Tujuannya adalah untuk menentukan keseluruhan persyaratan

   untuk pengurai pesan HTTP/1.1 dan perantara penerusan pesan.

   Dokumen ini menghapus bagian RFC 7230 yang terkait dengan HTTP/1.1

   perpesanan dan manajemen koneksi, dengan perubahannya

   dirangkum dalam Lampiran C.3. Bagian lain dari RFC 7230 adalah

   usang oleh "Semantik HTTP" [HTTP].

1.1. Notasi Persyaratan

   Kata kunci “HARUS”, “TIDAK BOLEH”, “WAJIB”, “HARUS”, “TIDAK”,

   “HARUS”, “TIDAK BOLEH”, “DIANJURKAN”, “TIDAK DIANJURKAN”, “BOLEH”, dan

   "OPSIONAL" dalam dokumen ini harus ditafsirkan sebagaimana dijelaskan dalam

   BCP 14 [RFC2119] [RFC8174] kapan, dan hanya jika, muncul di semua

   huruf kapital, seperti yang ditunjukkan di sini.

   Kriteria kesesuaian dan pertimbangan mengenai penanganan kesalahan adalah

   didefinisikan dalam Bagian 2 [HTTP].

1.2. Notasi Sintaks

   Spesifikasi ini menggunakan Augmented Backus-Naur Form (ABNF)

   notasi [RFC5234], diperpanjang dengan notasi untuk kasus-

   sensitivitas dalam string yang ditentukan dalam [RFC7405].

   Ini juga menggunakan ekstensi daftar, yang didefinisikan dalam Bagian 5.6.1 dari [HTTP],

   yang memungkinkan definisi ringkas dari daftar yang dipisahkan koma menggunakan a

   Operator "#" (mirip dengan operator "*" yang menunjukkan pengulangan).

   Lampiran A menunjukkan tata bahasa yang dikumpulkan dengan semua operator daftar

   diperluas ke notasi ABNF standar.

   Sebagai konvensi, nama aturan ABNF yang diawali dengan "obs-" menunjukkan usang

   aturan tata bahasa yang muncul karena alasan sejarah.

   Aturan inti berikut disertakan sebagai referensi, sebagaimana didefinisikan dalam

   [RFC5234], Lampiran B.1: ALPHA (huruf), CR (carriage return), CRLF

   (CR LF), CTL (kontrol), DIGIT (desimal 0-9), DQUOTE (kutipan ganda),

   HEXDIG (heksadesimal 0-9/AF/af), HTAB (tab horizontal), LF (garis

   feed), OCTET (urutan data 8-bit apa pun), SP (spasi), dan VCHAR (apa saja

   karakter [USASCII] yang terlihat).

   Aturan di bawah ini ditentukan di [HTTP]:

     BWS =

     OWS =

    

     RWS =

     

     jalur absolut =

      

     nama bidang =

       

     nilai bidang =

        

         obs-teks =

         

          kutipan-string =

          

           tanda =

           

            transfer-coding =

            

             Aturan di bawah ini didefinisikan dalam [URI]: absolute-URI =

             

              otoritas =

              

               host-uri =

               

                pelabuhan =

                

                 pertanyaan =

                 

                  2. Pesan Klien dan server HTTP/1.1 berkomunikasi dengan mengirimkan pesan. Lihat Bagian 3 [HTTP] untuk terminologi umum dan konsep inti HTTP. 2.1. Format Pesan Pesan HTTP/1.1 terdiri dari garis awal yang diikuti oleh CRLF dan urutan oktet dalam format yang mirip dengan Format Pesan Internet [RFC5322]: nol atau lebih baris bidang header (secara kolektif disebut sebagai "header" atau "bagian header"), baris kosong yang menunjukkan akhir bagian header, dan isi pesan opsional. HTTP-message = start-line CRLF *( field-line CRLF ) CRLF [ isi pesan ] Sebuah pesan dapat berupa permintaan dari klien ke server atau respons dari server ke klien. Secara sintaksis, kedua jenis pesan ini hanya berbeda pada baris awal, yaitu baris permintaan (untuk permintaan) atau baris status (untuk tanggapan), dan dalam algoritme untuk menentukan panjang isi pesan (Bagian 6). start-line = request-line / status-line Secara teori, klien dapat menerima permintaan dan server dapat menerima tanggapan, membedakannya berdasarkan format garis awal yang berbeda. Dalam praktiknya, server diimplementasikan hanya untuk mengharapkan permintaan (respon ditafsirkan sebagai metode permintaan yang tidak diketahui atau tidak valid), dan klien diimplementasikan hanya untuk mengharapkan respons. HTTP menggunakan beberapa elemen protokol yang mirip dengan Multiguna Internet Mail Extensions (MIME) [RFC2045]. Lihat Lampiran B untuk mengetahui perbedaan antara pesan HTTP dan MIME. 2.2. Penguraian Pesan Prosedur normal untuk mengurai pesan HTTP adalah membaca baris awal ke dalam struktur, membaca setiap baris bidang header ke dalam tabel hash berdasarkan nama bidang hingga baris kosong, dan kemudian menggunakan data yang diurai untuk menentukan apakah isi pesan diharapkan. Jika isi pesan telah ditentukan, maka pesan tersebut dibaca sebagai aliran hingga jumlah oktet yang sama dengan panjang isi pesan dibaca atau koneksi ditutup. Penerima HARUS mengurai pesan HTTP sebagai urutan oktet dalam pengkodean yang merupakan superset dari US-ASCII [USASCII]. Mengurai pesan HTTP sebagai aliran karakter Unicode, tanpa memperhatikan pengkodean spesifiknya, menciptakan kerentanan keamanan karena berbagai cara pustaka pemrosesan string menangani rangkaian karakter multibyte yang tidak valid yang berisi oktet LF (%x0A). Pengurai berbasis string hanya dapat digunakan dengan aman dalam elemen protokol setelah elemen diekstraksi dari pesan, seperti dalam nilai baris bidang header setelah penguraian pesan menggambarkan baris bidang individual. Meskipun terminator garis untuk garis awal dan bidang adalah urutan CRLF, penerima MUNGKIN mengenali satu LF sebagai terminator garis dan mengabaikan CR sebelumnya. Pengirim TIDAK HARUS menghasilkan CR kosong (karakter CR yang tidak langsung diikuti oleh LF) dalam elemen protokol apa pun selain konten. Penerima CR kosong tersebut HARUS menganggap elemen tersebut tidak valid atau mengganti setiap CR kosong dengan SP sebelum memproses elemen tersebut atau meneruskan pesan. Implementasi agen pengguna HTTP/1.0 yang lebih lama mungkin mengirimkan CRLF tambahan setelah permintaan POST sebagai solusi untuk beberapa aplikasi server awal yang gagal membaca konten isi pesan yang tidak diakhiri oleh akhir baris. Agen pengguna HTTP/1.1 TIDAK BOLEH mengawali atau mengikuti permintaan dengan CRLF tambahan. Jika diinginkan untuk mengakhiri isi pesan permintaan dengan akhiran baris, maka agen pengguna HARUS menghitung oktet CRLF yang diakhiri sebagai bagian dari panjang isi pesan. Demi ketahanan, server yang mengharapkan untuk menerima dan mengurai baris permintaan HARUS mengabaikan setidaknya satu baris kosong (CRLF) yang diterima sebelum baris permintaan. Pengirim TIDAK BOLEH mengirimkan spasi antara garis awal dan kolom header pertama. Penerima yang menerima spasi antara baris awal dan kolom header pertama HARUS menolak pesan tersebut karena tidak valid atau menggunakan setiap baris yang diawali dengan spasi tanpa memprosesnya lebih lanjut (yaitu, mengabaikan seluruh baris, bersama dengan baris berikutnya yang diawali dengan spasi , hingga kolom header yang dibentuk dengan benar diterima atau bagian header dihentikan). Penolakan atau penghapusan baris yang didahului spasi putih yang tidak valid diperlukan untuk mencegah salah tafsir oleh penerima hilir yang mungkin rentan terhadap serangan penyelundupan permintaan (Bagian 11.2) atau pemisahan respons (Bagian 11.1). Ketika server hanya mendengarkan pesan permintaan HTTP, atau memproses apa yang muncul dari baris awal sebagai pesan permintaan HTTP, menerima urutan oktet yang tidak cocok dengan tata bahasa pesan HTTP selain dari pengecualian ketahanan yang tercantum di atas, server HARUS merespons dengan respons 400 (Permintaan Buruk) dan menutup koneksi. 2.3. Versi HTTP HTTP menggunakan " sampai bidang header yang dibentuk dengan benar diterima atau bagian header dihentikan). Penolakan atau penghapusan baris yang didahului spasi putih yang tidak valid diperlukan untuk mencegah salah tafsir oleh penerima hilir yang mungkin rentan terhadap serangan penyelundupan permintaan (Bagian 11.2) atau pemisahan respons (Bagian 11.1). Ketika server hanya mendengarkan pesan permintaan HTTP, atau memproses apa yang muncul dari baris awal sebagai pesan permintaan HTTP, menerima urutan oktet yang tidak cocok dengan tata bahasa pesan HTTP selain dari pengecualian ketahanan yang tercantum di atas, server HARUS merespons dengan respons 400 (Permintaan Buruk) dan menutup koneksi. 2.3. Versi HTTP HTTP menggunakan " sampai bidang header yang dibentuk dengan benar diterima atau bagian header dihentikan). Penolakan atau penghapusan baris yang didahului spasi putih yang tidak valid diperlukan untuk mencegah salah tafsir oleh penerima hilir yang mungkin rentan terhadap serangan penyelundupan permintaan (Bagian 11.2) atau pemisahan respons (Bagian 11.1). Ketika server hanya mendengarkan pesan permintaan HTTP, atau memproses apa yang muncul dari baris awal sebagai pesan permintaan HTTP, menerima urutan oktet yang tidak cocok dengan tata bahasa pesan HTTP selain dari pengecualian ketahanan yang tercantum di atas, server HARUS merespons dengan respons 400 (Permintaan Buruk) dan menutup koneksi. 2.3. Versi HTTP HTTP menggunakan "

                  

                   .

                   

                    " skema penomoran untuk menunjukkan versi protokol. Spesifikasi ini mendefinisikan versi "1.1". Bagian 2.5 dari [HTTP] menentukan semantik nomor versi HTTP. Versi pesan HTTP/1.x ditunjukkan oleh bidang versi HTTP di baris awal. Versi HTTP peka huruf besar-kecil. Versi HTTP = Nama HTTP "/" DIGIT "." DIGIT Nama HTTP = %s"HTTP" Ketika pesan HTTP/1.1 dikirim ke HTTP/ 1.0 penerima [HTTP/1.0] atau penerima yang versinya tidak diketahui, pesan HTTP/1.1 dibuat sedemikian rupa sehingga dapat ditafsirkan sebagai pesan HTTP/1.0 yang valid jika semua fitur baru diabaikan. Spesifikasi ini menempatkan versi penerima persyaratan pada beberapa fitur baru sehingga pengirim yang sesuai hanya akan menggunakan fitur yang kompatibel hingga ditentukan, melalui konfigurasi atau penerimaan pesan, bahwa penerima mendukung HTTP/1.1. Perantara yang memproses pesan HTTP (yaitu, semua perantara selain yang tersebut bertindak sebagai terowongan) HARUS mengirimkan versi HTTP-nya sendiri dalam pesan yang diteruskan, kecuali jika versi tersebut sengaja diturunkan sebagai solusi untuk masalah upstream. Dengan kata lain, perantara tidak diperbolehkan meneruskan garis awal secara membabi buta tanpa memastikan bahwa versi protokol dalam pesan tersebut cocok dengan versi yang sesuai dengan perantara tersebut untuk menerima dan mengirim pesan. Meneruskan pesan HTTP tanpa menulis ulang versi HTTP mungkin mengakibatkan kesalahan komunikasi ketika penerima hilir menggunakan versi pengirim pesan untuk menentukan fitur apa yang aman digunakan untuk komunikasi selanjutnya dengan pengirim tersebut. Server MUNGKIN mengirimkan respons HTTP/1.0 ke permintaan HTTP/1.1 jika diketahui atau dicurigai bahwa klien salah mengimplementasikan spesifikasi HTTP dan tidak mampu memproses respons versi yang lebih baru dengan benar, misalnya saat klien gagal mengurai nomor versi dengan benar atau ketika perantara diketahui meneruskan versi HTTP secara membabi buta meskipun versi tersebut tidak sesuai dengan versi kecil protokol yang diberikan. Penurunan versi protokol tersebut TIDAK BOLEH dilakukan kecuali dipicu oleh atribut klien tertentu, seperti ketika satu atau lebih bidang header permintaan (misalnya, Agen-Pengguna) secara unik cocok dengan nilai yang dikirim oleh klien yang diketahui mengalami kesalahan. 3. Baris Permintaan Baris permintaan dimulai dengan token metode, diikuti oleh spasi tunggal (SP), target permintaan, dan spasi tunggal lainnya (SP), dan diakhiri dengan versi protokol. request-line = metode SP target permintaan SP Versi HTTP Meskipun aturan tata bahasa baris permintaan mengharuskan setiap elemen komponen dipisahkan oleh satu oktet SP, penerima MUNGKIN menguraikan batas kata yang dibatasi spasi dan, selain dari Terminator CRLF, perlakukan segala bentuk spasi sebagai pemisah SP sambil mengabaikan spasi sebelum atau sesudahnya; spasi tersebut mencakup satu atau lebih oktet berikut: SP, HTAB, VT (%x0B), FF (%x0C), atau bare CR. Namun, penguraian yang lunak dapat mengakibatkan kerentanan keamanan penyelundupan permintaan jika ada beberapa penerima pesan dan masing-masing memiliki interpretasi ketahanan yang unik (lihat Bagian 11.2). HTTP tidak memberikan batasan yang telah ditentukan sebelumnya pada panjang baris permintaan, seperti yang dijelaskan dalam Bagian 2.3 [HTTP]. Server yang menerima metode lebih lama dari metode apa pun yang diimplementasikannya HARUS merespons dengan kode status 501 (Tidak Diimplementasikan). Server yang menerima target permintaan lebih panjang dari URI mana pun yang ingin diurai HARUS merespons dengan kode status 414 (URI Terlalu Panjang) (lihat Bagian 15.5.15 dari [HTTP]). Berbagai batasan ad hoc pada panjang jalur permintaan ditemukan dalam praktiknya. DIANJURKAN agar semua pengirim dan penerima HTTP mendukung, minimal, panjang baris permintaan 8000 oktet. 3.1. Metode Token metode menunjukkan metode permintaan yang akan dilakukan pada sumber daya target. Metode permintaan peka huruf besar-kecil. metode = token Metode permintaan yang ditentukan oleh spesifikasi ini dapat ditemukan di Bagian 9 [HTTP], bersama dengan informasi mengenai registri metode HTTP dan pertimbangan untuk menentukan metode baru. 3.2. Target Permintaan Target-permintaan mengidentifikasi sumber daya target untuk menerapkan permintaan. Klien mendapatkan target permintaan dari URI target yang diinginkan. Ada empat format berbeda untuk target permintaan, bergantung pada metode yang diminta dan apakah permintaan ditujukan ke proxy. target-permintaan = formulir-asal / formulir-absolut / formulir-otoritas / formulir-asterisk Tidak boleh ada spasi di target-permintaan. Sayangnya, beberapa agen pengguna gagal mengkodekan atau mengecualikan spasi putih yang ditemukan dalam referensi hypertext dengan benar, sehingga karakter yang tidak diizinkan tersebut dikirim sebagai target permintaan dalam format baris permintaan yang salah. Penerima baris permintaan yang tidak valid HARUS merespons dengan kesalahan 400 (Permintaan Buruk) atau pengalihan 301 (Dipindahkan Secara Permanen) dengan target permintaan yang dikodekan dengan benar. Penerima TIDAK BOLEH mencoba melakukan koreksi otomatis dan kemudian memproses permintaan tanpa pengalihan, karena baris permintaan yang tidak valid mungkin sengaja dibuat untuk melewati filter keamanan di sepanjang rantai permintaan. Klien HARUS mengirimkan bidang header Host (Bagian 7.2 dari [HTTP]) di semua pesan permintaan HTTP/1.1. Jika URI target menyertakan komponen otoritas, maka klien HARUS mengirimkan nilai bidang untuk Host yang identik dengan komponen otoritas tersebut, tidak termasuk subkomponen info pengguna dan pembatas "@" (Bagian 4.2 dari [HTTP]). Jika komponen otoritas hilang atau tidak ditentukan untuk URI target, maka klien HARUS mengirimkan bidang header Host dengan nilai bidang kosong. Server HARUS merespons dengan kode status 400 (Permintaan Buruk) terhadap setiap pesan permintaan HTTP/1.1 yang tidak memiliki bidang header Host dan terhadap pesan permintaan apa pun yang berisi lebih dari satu baris bidang header Host atau bidang header Host dengan nilai bidang yang tidak valid . 3.2.1. bentuk-asal Bentuk target-permintaan yang paling umum adalah "bentuk-asal". bentuk asal = jalur absolut [ "?" query ] Saat membuat permintaan langsung ke server asal, selain permintaan CONNECT atau OPTIONS seluruh server (seperti yang dijelaskan di bawah), klien HARUS mengirim hanya jalur absolut dan komponen kueri dari URI target sebagai target permintaan. Jika komponen jalur URI target kosong, klien HARUS mengirimkan "/" sebagai jalur dalam bentuk asal target permintaan. Bidang header Host juga dikirim, sebagaimana didefinisikan dalam Bagian 7.2 [HTTP]. Misalnya, klien yang ingin mengambil representasi sumber daya yang diidentifikasi sebagai http://www.example.org/where?q=now langsung dari server asal akan membuka (atau menggunakan kembali) koneksi TCP ke port 80 host "www.example.org" dan kirimkan baris: GET /where?q=now HTTP/1.1 Host: www.example.org diikuti dengan sisa pesan permintaan. 3.2.2. bentuk absolut Saat membuat permintaan ke proxy, selain permintaan CONNECT atau OPTIONS seluruh server (seperti yang dijelaskan di bawah), klien HARUS mengirimkan URI target dalam "bentuk absolut" sebagai target permintaan. absolute-form = absolute-URI Proksi diminta ke layanan yang meminta dari cache yang valid, jika memungkinkan, atau membuat permintaan yang sama atas nama klien baik ke server proksi masuk berikutnya atau langsung ke server asal yang ditunjukkan oleh permintaan -target. Persyaratan untuk "penerusan" pesan tersebut dijelaskan dalam Bagian 7.6 [HTTP]. Contoh bentuk absolut dari baris permintaan adalah: GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1 Klien HARUS mengirimkan bidang header Host dalam permintaan HTTP/1.1 bahkan jika target-permintaan dalam bentuk absolut, karena ini memungkinkan informasi Host diteruskan melalui proxy HTTP/1.0 kuno yang mungkin tidak mengimplementasikan Host. Ketika proksi menerima permintaan dengan bentuk target permintaan absolut, proksi HARUS mengabaikan bidang header Host yang diterima (jika ada) dan menggantinya dengan informasi host target permintaan. Proksi yang meneruskan permintaan tersebut HARUS menghasilkan nilai bidang Host baru berdasarkan target permintaan yang diterima, bukan meneruskan nilai bidang Host yang diterima. Ketika server asal menerima permintaan dengan bentuk target permintaan absolut, server asal HARUS mengabaikan bidang header Host yang diterima (jika ada) dan sebagai gantinya menggunakan informasi host target permintaan. Perhatikan bahwa jika target permintaan tidak memiliki komponen otoritas, bidang header Host yang kosong akan dikirim dalam kasus ini. Server HARUS menerima bentuk absolut dalam permintaan meskipun sebagian besar klien HTTP/1.1 hanya akan mengirimkan bentuk absolut ke proxy. 3.2.3. bentuk otoritas "Bentuk otoritas" dari target permintaan hanya digunakan untuk permintaan CONNECT (Bagian 9.3.6 dari [HTTP]). Ini hanya terdiri dari uri-host dan nomor port terowongan tujuan, dipisahkan oleh titik dua (“:”). otoritas-form = uri-host ":" port Saat membuat permintaan CONNECT untuk membuat terowongan melalui satu atau lebih proxy, klien HARUS mengirim hanya host dan port tujuan terowongan sebagai target permintaan. Klien mendapatkan host dan port dari komponen otoritas URI target, kecuali klien mengirimkan port default skema jika URI target menghilangkan port tersebut. Misalnya, permintaan CONNECT ke "http://www.example.com" terlihat seperti berikut: CONNECT www.example.com:80 HTTP/1.1 Host: www.example.com 3.2.4. asterisk-form "Bentuk asterisk" dari target permintaan hanya digunakan untuk permintaan OPTIONS di seluruh server (Bagian 9.3.7 dari [HTTP]). asterisk-form = "*" Ketika klien ingin meminta OPSI untuk server secara keseluruhan, dibandingkan dengan sumber daya bernama spesifik dari server tersebut, klien HARUS mengirim hanya "*" (%x2A) sebagai target permintaan. Misalnya, OPTIONS * HTTP/1.1 Jika proxy menerima permintaan OPTIONS dengan bentuk target permintaan absolut di mana URI memiliki jalur kosong dan tidak ada komponen kueri, maka proxy terakhir pada rantai permintaan HARUS mengirimkan permintaan- target "*" ketika meneruskan permintaan ke server asal yang ditunjukkan. Misalnya, permintaan OPTIONS http://www.example.org:8001 HTTP/1.1 akan diteruskan oleh proxy akhir sebagai OPTIONS * HTTP/1.1 Host: www.example.org:8001 setelah terhubung ke port 8001 host " www.contoh.org". 3.3. Merekonstruksi URI Target URI target adalah target permintaan ketika target permintaan berada dalam bentuk absolut. Dalam hal ini, server akan menguraikan URI ke dalam komponen generiknya untuk evaluasi lebih lanjut. Jika tidak, server akan merekonstruksi URI target dari konteks koneksi dan berbagai bagian pesan permintaan untuk mengidentifikasi sumber daya target (Bagian 7.1 dari [HTTP]): * Jika konfigurasi server menyediakan skema URI tetap, atau skema disediakan oleh gateway keluar tepercaya, skema tersebut digunakan untuk URI target. Hal ini biasa terjadi dalam penerapan skala besar karena server gateway akan menerima konteks koneksi klien dan menggantinya dengan koneksi mereka sendiri ke server masuk. Sebaliknya, jika permintaan diterima melalui koneksi aman, skema URI targetnya adalah "https"; jika tidak, skemanya adalah "http". * Jika target permintaan dalam bentuk otoritas, komponen otoritas URI target adalah target permintaan. Jika tidak, komponen otoritas URI target adalah nilai bidang dari bidang header Host. Jika tidak ada bidang header Host atau jika nilai bidangnya kosong atau tidak valid, komponen otoritas URI target kosong. * Jika target permintaan dalam bentuk otoritas atau tanda bintang, jalur gabungan URI target dan komponen kueri kosong. Jika tidak, jalur gabungan dan komponen kueri URI target adalah target permintaan. * Komponen URI target yang direkonstruksi, setelah ditentukan seperti di atas, dapat digabungkan kembali menjadi bentuk URI absolut dengan menggabungkan skema, "://", otoritas, serta gabungan jalur dan komponen kueri. Contoh 1: Pesan berikut diterima melalui koneksi aman GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.example.org memiliki URI target https://www.example.org/pub/WWW/TheProject.html Contoh 2: Pesan berikut diterima melalui koneksi tidak aman OPSI * HTTP/1.1 Host: www.example.org:8080 memiliki URI target http://www.example.org:8080 Jika komponen otoritas URI target kosong dan Skema URI memerlukan otoritas yang tidak kosong (seperti halnya "http" dan "https"), server dapat menolak permintaan atau menentukan apakah konfigurasi default berlaku yang konsisten dengan konteks koneksi masuk. Konteks mungkin mencakup rincian koneksi seperti alamat dan port, keamanan apa yang telah diterapkan, dan informasi yang ditentukan secara lokal khusus untuk konfigurasi server tersebut. Otoritas kosong diganti dengan default yang dikonfigurasi sebelum permintaan diproses lebih lanjut. Memberikan nama default untuk otoritas dalam konteks koneksi aman pada dasarnya tidak aman jika ada kemungkinan otoritas yang dimaksudkan agen pengguna mungkin berbeda dari default. Server yang secara unik dapat mengidentifikasi otoritas dari konteks permintaan MUNGKIN menggunakan identitas tersebut sebagai default tanpa risiko ini. Alternatifnya, mungkin lebih baik mengalihkan permintaan ke sumber aman yang menjelaskan cara mendapatkan klien baru. Perhatikan bahwa merekonstruksi URI target klien hanyalah setengah dari proses untuk mengidentifikasi sumber daya target. Separuh bagian lainnya menentukan apakah URI target tersebut mengidentifikasi sumber daya yang ingin dan mampu dikirimi respons oleh server, sebagaimana didefinisikan dalam Bagian 7.4 [HTTP]. 4. Baris Status Baris pertama dari pesan respons adalah baris status, yang terdiri dari versi protokol, spasi (SP), kode status, dan spasi lainnya dan diakhiri dengan frasa teks OPSIONAL yang menjelaskan kode status. status-line = Versi HTTP SP kode status SP [ alasan-frasa ] Meskipun aturan tata bahasa baris status mengharuskan setiap elemen komponen dipisahkan oleh satu oktet SP, penerima MUNGKIN menguraikan batas kata yang dibatasi spasi dan , selain dari terminator garis, perlakukan segala bentuk spasi putih sebagai pemisah SP sambil mengabaikan spasi sebelum atau sesudahnya; spasi tersebut mencakup satu atau lebih oktet berikut: SP, HTAB, VT (%x0B), FF (%x0C), atau bare CR. Namun, penguraian yang lunak dapat mengakibatkan kerentanan keamanan yang memecah respons jika ada beberapa penerima pesan dan masing-masing penerima memiliki interpretasi ketahanan yang unik (lihat Bagian 11.1). Elemen kode status adalah kode bilangan bulat 3 digit yang menggambarkan hasil upaya server untuk memahami dan memenuhi permintaan klien yang sesuai. Penerima menguraikan dan menafsirkan sisa pesan respons berdasarkan semantik yang ditentukan untuk kode status tersebut, jika kode status dikenali oleh penerima tersebut, atau sesuai dengan kelas kode status tersebut ketika kode tertentu tidak dikenali. status-code = 3DIGIT Kode status inti HTTP didefinisikan dalam Bagian 15 [HTTP], bersama dengan kelas kode status, pertimbangan untuk definisi kode status baru, dan registri IANA untuk mengumpulkan definisi tersebut. Elemen alasan-frasa ada hanya untuk tujuan memberikan deskripsi tekstual yang terkait dengan kode status numerik, sebagian besar untuk menghormati protokol aplikasi Internet sebelumnya yang lebih sering digunakan dengan klien teks interaktif. alasan-frasa = 1*( HTAB / SP / VCHAR / obs-teks ) Klien HARUS mengabaikan konten frasa alasan karena ini bukan saluran informasi yang dapat diandalkan (mungkin diterjemahkan untuk lokal tertentu, ditimpa oleh perantara, atau dibuang ketika pesan diteruskan melalui versi HTTP lainnya). Server HARUS mengirimkan spasi yang memisahkan kode status dari frasa alasan meskipun frasa alasan tidak ada (yaitu, baris status akan diakhiri dengan spasi). 5. Sintaks Bidang Setiap baris bidang terdiri dari nama bidang yang tidak peka huruf besar-kecil diikuti dengan titik dua (“:”), spasi putih opsional di awal, nilai baris bidang, dan spasi tambahan opsional. field-line = field-name ":" OWS nilai bidang OWS Aturan untuk penguraian dalam nilai bidang ditentukan dalam Bagian 5.5 dari [HTTP]. Bagian ini mencakup sintaksis umum untuk penyertaan kolom header di dalam, dan ekstraksi dari, pesan HTTP/1.1. 5.1. Pesan Penguraian Garis Bidang diurai menggunakan algoritme umum, tidak bergantung pada nama bidang individual. Konten dalam nilai baris bidang tertentu tidak diuraikan hingga tahap interpretasi pesan selanjutnya (biasanya setelah seluruh bagian bidang pesan diproses). Tidak ada spasi putih yang diperbolehkan antara nama bidang dan titik dua. Di masa lalu, perbedaan dalam penanganan spasi putih tersebut telah menyebabkan kerentanan keamanan dalam perutean permintaan dan penanganan respons. Server HARUS menolak, dengan kode status respons 400 (Permintaan Buruk), setiap pesan permintaan yang diterima yang berisi spasi antara nama kolom header dan titik dua. Proksi HARUS menghapus spasi apa pun dari pesan respons sebelum meneruskan pesan ke hilir. Nilai baris bidang mungkin diawali dan/atau diikuti dengan spasi opsional (OWS); satu SP sebelum nilai garis bidang lebih disukai agar dapat dibaca secara konsisten oleh manusia. Nilai baris bidang tidak mencakup spasi putih di awal atau di akhir: OWS yang terjadi sebelum oktet non-spasi pertama dari nilai baris bidang, atau setelah oktet non-spasi terakhir dari nilai baris bidang, dikecualikan oleh parser saat mengekstraksi bidang nilai garis dari garis bidang. 5.2. Pelipatan Garis Usang Secara historis, nilai bidang HTTP/1.x dapat diperluas ke beberapa baris dengan mengawali setiap baris tambahan dengan setidaknya satu spasi atau tab horizontal (obs-fold). Spesifikasi ini tidak lagi menerapkan pelipatan baris tersebut kecuali dalam jenis media "pesan/http" (Bagian 10.1). obs-lipat = OWS CRLF RWS ; pelipatan baris usang Pengirim TIDAK HARUS membuat pesan yang menyertakan pelipatan baris (yaitu, yang memiliki nilai baris bidang apa pun yang cocok dengan aturan obs-fold) kecuali pesan tersebut dimaksudkan untuk dikemas dalam jenis media "pesan/http" . Server yang menerima obs-fold dalam pesan permintaan yang tidak berada dalam wadah "pesan/http" HARUS menolak pesan tersebut dengan mengirimkan 400 (Permintaan Buruk), sebaiknya dengan representasi yang menjelaskan bahwa pelipatan baris yang usang tidak dapat diterima, atau ganti setiap obs-fold yang diterima dengan satu atau lebih oktet SP sebelum menafsirkan nilai bidang atau meneruskan pesan ke hilir. Proksi atau gateway yang menerima obs-fold dalam pesan respons yang tidak berada dalam wadah "pesan/http" HARUS membuang pesan tersebut dan menggantinya dengan respons 502 (Bad Gateway), sebaiknya dengan representasi yang menjelaskan baris yang tidak dapat diterima tersebut pelipatan diterima, atau ganti setiap lipatan obs-fold yang diterima dengan satu atau lebih oktet SP sebelum menafsirkan nilai bidang atau meneruskan pesan ke hilir. Agen pengguna yang menerima obs-fold dalam pesan respons yang tidak berada dalam wadah "pesan/http" HARUS mengganti setiap obs-fold yang diterima dengan satu atau lebih oktet SP sebelum menafsirkan nilai bidang. 6. Isi Pesan Isi pesan (jika ada) dari pesan HTTP/1.1 digunakan untuk membawa konten (Bagian 6.4 dari [HTTP]) untuk permintaan atau respons. Badan pesan identik dengan konten kecuali kode transfer telah diterapkan, seperti dijelaskan dalam Bagian 6.1. message-body = *OCTET Aturan untuk menentukan kapan isi pesan ada dalam pesan HTTP/1.1 berbeda untuk permintaan dan respons. Kehadiran isi pesan dalam permintaan ditandai dengan bidang header Content-Length atau Transfer-Encoding. Pembingkaian pesan permintaan tidak bergantung pada semantik metode. Kehadiran isi pesan dalam suatu respons, sebagaimana dirinci dalam Bagian 6.3, bergantung pada metode permintaan yang ditanggapinya dan kode status responsnya. Hal ini berkaitan dengan kapan konten respons diizinkan oleh semantik HTTP (Bagian 6.4.1 dari [HTTP]). 6.1. Transfer-Encoding Bidang header Transfer-Encoding mencantumkan nama pengkodean transfer yang sesuai dengan urutan pengkodean transfer yang telah (atau akan) diterapkan pada konten untuk membentuk isi pesan. Pengkodean transfer dijelaskan di Bagian 7. Pengkodean Transfer = #transfer-coding ; didefinisikan dalam [HTTP], Bagian 10.1.4 Transfer-Encoding analog dengan bidang Content-Transfer-Encoding MIME, yang dirancang untuk memungkinkan pengangkutan data biner yang aman melalui layanan transportasi 7-bit ([RFC2045], Bagian 6 ). Namun, transportasi aman memiliki fokus berbeda untuk protokol transfer bersih 8bit. Dalam kasus HTTP, Transfer-Encoding terutama ditujukan untuk membatasi secara akurat konten yang dihasilkan secara dinamis. Hal ini juga berfungsi untuk membedakan pengkodean yang hanya diterapkan dalam transit dari pengkodean yang merupakan karakteristik dari representasi yang dipilih. Penerima HARUS dapat mengurai kode transfer yang terpotong (Bagian 7.1) karena ini memainkan peran penting dalam membingkai pesan ketika ukuran konten tidak diketahui sebelumnya. Pengirim TIDAK BOLEH menerapkan kode transfer yang terpotong lebih dari satu kali ke badan pesan (yaitu, tidak diperbolehkan memotong pesan yang sudah terpotong). Jika ada kode transfer selain potongan yang diterapkan pada konten permintaan, pengirim HARUS menerapkan potongan sebagai kode transfer akhir untuk memastikan bahwa pesan dibingkai dengan benar. Jika ada kode transfer selain potongan yang diterapkan pada konten respons, pengirim HARUS menerapkan potongan sebagai kode transfer akhir atau mengakhiri pesan dengan menutup koneksi. Misalnya, Transfer-Encoding: gzip, chunked menunjukkan bahwa konten telah dikompresi menggunakan kode gzip dan kemudian di-chunk menggunakan kode chunked sambil membentuk isi pesan. Berbeda dengan Content-Encoding (Bagian 8.4.1 dari [HTTP]), Transfer-Encoding adalah properti pesan, bukan representasi. Penerima mana pun di sepanjang rantai permintaan/respons MUNGKIN mendekode kode transfer yang diterima atau menerapkan kode transfer tambahan ke badan pesan, dengan asumsi bahwa perubahan terkait telah dilakukan pada nilai bidang Pengkodean Transfer. Informasi tambahan tentang parameter pengkodean dapat diberikan oleh bidang header lain yang tidak ditentukan oleh spesifikasi ini. Pengkodean Transfer MUNGKIN dikirim sebagai respons terhadap permintaan HEAD atau dalam respons 304 (Tidak Dimodifikasi) (Bagian 15.4.5 dari [HTTP]) terhadap permintaan GET, tidak satupun yang menyertakan badan pesan, untuk menunjukkan bahwa asal server akan menerapkan pengkodean transfer ke badan pesan jika permintaannya adalah GET tanpa syarat. Namun indikasi ini tidak diperlukan, karena penerima mana pun di rantai respons (termasuk server asal) dapat menghapus kode transfer saat tidak diperlukan. Server TIDAK HARUS mengirimkan kolom header Transfer-Encoding dalam respons apa pun dengan kode status 1xx (Informasional) atau 204 (Tanpa Konten). Server TIDAK HARUS mengirimkan bidang header Transfer-Encoding dalam respons 2xx (Berhasil) apa pun ke permintaan CONNECT (Bagian 9.3.6 dari [HTTP]). Server yang menerima pesan permintaan dengan kode transfer yang tidak dipahaminya HARUS merespons dengan 501 (Tidak Diimplementasikan). Transfer-Encoding telah ditambahkan di HTTP/1.1. Secara umum diasumsikan bahwa implementasi yang hanya mengiklankan dukungan HTTP/1.0 tidak akan memahami cara memproses konten yang dikodekan transfer, dan bahwa pesan HTTP/1.0 yang diterima dengan Transfer-Encoding kemungkinan besar diteruskan tanpa penanganan yang tepat terhadap kode transfer yang terpotong. sedang transit. Klien TIDAK BOLEH mengirim permintaan yang berisi Transfer-Encoding kecuali klien mengetahui server akan menangani HTTP/1. 1 permintaan (atau revisi kecil selanjutnya); pengetahuan tersebut mungkin dalam bentuk konfigurasi pengguna tertentu atau dengan mengingat versi respons yang diterima sebelumnya. Server TIDAK HARUS mengirimkan respons yang berisi Transfer-Encoding kecuali permintaan terkait menunjukkan HTTP/1.1 (atau revisi kecil yang lebih baru). Implementasi awal dari Transfer-Encoding kadang-kadang mengirimkan pengkodean transfer yang terpotong untuk pembingkaian pesan dan perkiraan bidang header Panjang Konten untuk digunakan oleh bilah kemajuan. Inilah sebabnya mengapa Transfer-Encoding didefinisikan sebagai mengesampingkan Panjang Konten, dan bukannya tidak kompatibel satu sama lain. Sayangnya, meneruskan pesan seperti itu dapat menyebabkan kerentanan terkait penyelundupan permintaan (Bagian 11.2) atau serangan pemisahan respons (Bagian 11.1) jika ada penerima di hilir yang gagal menguraikan pesan sesuai dengan spesifikasi ini, terutama ketika penerima di hilir hanya mengimplementasikan HTTP/1.0. Server MUNGKIN menolak permintaan yang berisi Content-Length dan Transfer-Encoding atau memproses permintaan tersebut sesuai dengan Transfer-Encoding saja. Apapun, server HARUS menutup koneksi setelah menanggapi permintaan tersebut untuk menghindari potensi serangan. Server atau klien yang menerima pesan HTTP/1.0 berisi bidang header Transfer-Encoding HARUS memperlakukan pesan seolah-olah framingnya salah, meskipun ada Content-Length, dan menutup koneksi setelah memproses pesan. Pengirim pesan mungkin menyimpan sebagian pesan, dalam buffer, yang dapat disalahartikan oleh penggunaan koneksi lebih lanjut. 6.2. Panjang Konten Ketika pesan tidak memiliki kolom header Transfer-Encoding, kolom header Panjang Konten (Bagian 8.6 dari [HTTP]) dapat memberikan ukuran yang diharapkan, sebagai angka desimal oktet, untuk konten potensial. Untuk pesan yang menyertakan konten, nilai bidang Content-Length menyediakan informasi pembingkaian yang diperlukan untuk menentukan di mana data (dan pesan) berakhir. Untuk pesan yang tidak menyertakan konten, Content-Length menunjukkan ukuran representasi yang dipilih (Bagian 8.6 dari [HTTP]). Pengirim TIDAK BOLEH mengirimkan kolom header Panjang Konten dalam pesan apa pun yang berisi kolom header Transfer-Encoding. | *Catatan:* Penggunaan Content-Length oleh HTTP untuk pembingkaian pesan | berbeda secara signifikan dari penggunaan bidang yang sama di MIME, dimana | ini adalah bidang opsional yang hanya digunakan dalam jenis media "message/external- | body". 6.3. Panjang Isi Pesan Panjang isi pesan ditentukan oleh salah satu hal berikut (dalam urutan prioritas): 1. Respons apa pun terhadap permintaan HEAD dan respons apa pun dengan 1xx (Informasional), 204 (Tanpa Konten), atau 304 ( Kode status Tidak Dimodifikasi) selalu diakhiri dengan baris kosong pertama setelah kolom header, terlepas dari kolom header yang ada dalam pesan, dan dengan demikian tidak dapat berisi isi pesan atau bagian cuplikan. 2. Setiap respons 2xx (Berhasil) terhadap permintaan CONNECT menyiratkan bahwa koneksi akan menjadi terowongan segera setelah baris kosong yang mengakhiri kolom header. Klien HARUS mengabaikan kolom header Content-Length atau Transfer-Encoding yang diterima dalam pesan tersebut. 3. Jika pesan diterima dengan bidang header Transfer-Encoding dan Content-Length, maka Transfer-Encoding akan menggantikan Content-Length. Pesan tersebut mungkin menunjukkan upaya untuk melakukan penyelundupan permintaan (Pasal 11.2) atau pemisahan respons (Pasal 11.1) dan harus ditangani sebagai kesalahan. Perantara yang memilih untuk meneruskan pesan HARUS terlebih dahulu menghapus bidang Panjang Konten yang diterima dan memproses Pengkodean Transfer (seperti dijelaskan di bawah) sebelum meneruskan pesan ke hilir. 4. Jika kolom header Transfer-Encoding ada dan pengkodean transfer yang terpotong (Bagian 7.1) adalah pengkodean akhir, panjang isi pesan ditentukan dengan membaca dan mendekode data yang terpotong hingga pengkodean transfer menunjukkan bahwa data sudah lengkap. Jika bidang header Transfer-Encoding hadir dalam respons dan pengkodean transfer yang terpotong bukan pengkodean akhir, panjang isi pesan ditentukan dengan membaca koneksi hingga ditutup oleh server. Jika bidang header Transfer-Encoding ada dalam permintaan dan pengkodean transfer yang terpotong bukan pengkodean akhir, panjang isi pesan tidak dapat ditentukan dengan pasti; server HARUS merespons dengan kode status 400 (Permintaan Buruk) dan kemudian menutup koneksi. 5. Jika pesan diterima tanpa Transfer-Encoding dan dengan field header Content-Length yang tidak valid, maka framing pesan tidak valid dan penerima HARUS memperlakukannya sebagai kesalahan yang tidak dapat dipulihkan, kecuali nilai field berhasil diurai sebagai koma. daftar terpisah (Bagian 5.6.1 dari [HTTP]), semua nilai dalam daftar adalah valid, dan semua nilai dalam daftar adalah sama (dalam hal ini, pesan diproses dengan nilai tunggal yang digunakan sebagai Nilai bidang Panjang Konten). Jika kesalahan yang tidak dapat dipulihkan ada dalam pesan permintaan, server HARUS merespons dengan kode status 400 (Permintaan Buruk) dan kemudian menutup koneksi. Jika berada dalam pesan respons yang diterima oleh proxy, proxy tersebut HARUS menutup koneksi ke server, membuang respons yang diterima, dan mengirimkan respons 502 (Bad Gateway) ke klien. Jika ada dalam pesan respons yang diterima oleh agen pengguna, agen pengguna HARUS menutup koneksi ke server dan membuang respons yang diterima. 6. Jika bidang header Panjang Konten yang valid ada tanpa Transfer-Encoding, nilai desimalnya menentukan panjang isi pesan yang diharapkan dalam oktet. Jika pengirim menutup sambungan atau waktu penerima habis sebelum jumlah oktet yang ditentukan diterima, penerima HARUS menganggap pesan tersebut tidak lengkap dan menutup sambungan. 7. Jika ini adalah pesan permintaan dan tidak ada satu pun di atas yang benar, maka panjang isi pesan adalah nol (tidak ada isi pesan). 8.Jika tidak, ini adalah pesan respons tanpa panjang isi pesan yang dinyatakan, sehingga panjang isi pesan ditentukan oleh jumlah oktet yang diterima sebelum server menutup koneksi. Karena tidak ada cara untuk membedakan pesan respons yang berhasil diselesaikan dan dibatasi jaraknya dari pesan yang diterima sebagian yang terganggu oleh kegagalan jaringan, server HARUS menghasilkan pesan pengkodean atau pesan dengan batas panjang bila memungkinkan. Fitur pembatas dekat ada terutama untuk kompatibilitas mundur dengan HTTP/1.0. | *Catatan:* Pesan permintaan tidak pernah dibatasi karena | selalu dibingkai secara eksplisit berdasarkan panjang atau kode transfer, dengan | tidak adanya keduanya menyiratkan permintaan berakhir segera setelah | bagian tajuk. Server MUNGKIN menolak permintaan yang berisi isi pesan tetapi bukan Panjang Konten dengan merespons dengan 411 (Diperlukan Panjang). Kecuali pengkodean transfer selain yang terpotong telah diterapkan, klien yang mengirimkan permintaan yang berisi badan pesan HARUS menggunakan bidang header Panjang Konten yang valid jika panjang badan pesan diketahui sebelumnya, bukan kode transfer yang terpotong, karena beberapa sudah ada layanan merespons potongan dengan kode status 411 (Diperlukan Panjang) meskipun mereka memahami kode transfer potongan. Hal ini biasanya terjadi karena layanan tersebut diimplementasikan melalui gateway yang memerlukan panjang konten sebelum dipanggil, dan server tidak dapat atau tidak mau melakukan buffering seluruh permintaan sebelum diproses. Agen pengguna yang mengirimkan permintaan yang berisi isi pesan HARUS mengirimkan bidang header Panjang Konten yang valid atau menggunakan kode transfer yang dipotong. Klien TIDAK HARUS menggunakan kode transfer terpotong kecuali ia mengetahui server akan menangani permintaan HTTP/1.1 (atau lebih baru); pengetahuan tersebut dapat berupa konfigurasi pengguna tertentu atau dengan mengingat versi respons yang diterima sebelumnya. Jika respons akhir terhadap permintaan terakhir pada koneksi telah diterima sepenuhnya dan masih ada data tambahan untuk dibaca, agen pengguna MUNGKIN membuang data yang tersisa atau mencoba menentukan apakah data tersebut termasuk dalam isi pesan sebelumnya, yang mungkin merupakan terjadi jika nilai Panjang Konten pesan sebelumnya salah. Klien TIDAK HARUS memproses, menyimpan cache, atau meneruskan data tambahan tersebut sebagai respons terpisah, karena perilaku tersebut akan rentan terhadap keracunan cache. 7. Pengkodean Transfer Nama pengkodean transfer digunakan untuk menunjukkan transformasi pengkodean yang telah, dapat, atau mungkin perlu diterapkan pada konten pesan untuk memastikan "transportasi yang aman" melalui jaringan. Hal ini berbeda dengan pengkodean konten dimana pengkodean transfer merupakan properti pesan dan bukan properti representasi yang sedang ditransfer. Semua nama pengkodean transfer tidak membedakan huruf besar dan kecil dan harus didaftarkan dalam registri HTTP Transfer Coding, sebagaimana didefinisikan dalam Bagian 7.3. Mereka digunakan dalam Transfer-Encoding (Bagian 6.1) dan TE (Bagian 10.1. 4 bidang header [HTTP]) (yang terakhir juga mendefinisikan tata bahasa "transfer-coding"). 7.1. Pengkodean Transfer Terpotong Pengkodean transfer terpotong membungkus konten untuk mentransfernya sebagai serangkaian potongan, masing-masing dengan indikator ukurannya sendiri, diikuti oleh bagian cuplikan OPSIONAL yang berisi bidang cuplikan. Chunked memungkinkan aliran konten dengan ukuran yang tidak diketahui untuk ditransfer sebagai urutan buffer yang panjangnya dibatasi, yang memungkinkan pengirim mempertahankan persistensi koneksi dan penerima mengetahui kapan ia telah menerima seluruh pesan. chunked-body = *potongan potongan terakhir trailer-bagian CRLF potongan = ukuran potongan [ chunk-ext ] CRLF data potongan CRLF ukuran potongan = 1*HEXDIG potongan terakhir = 1*("0") [ potongan-ext ] Data potongan CRLF = 1*OCTET ; urutan oktet ukuran bongkahan Bidang ukuran bongkahan adalah serangkaian digit hex yang menunjukkan ukuran data bongkahan dalam oktet. Pengkodean transfer potongan selesai ketika potongan dengan ukuran potongan nol diterima, mungkin diikuti oleh bagian cuplikan, dan akhirnya diakhiri dengan baris kosong. Penerima HARUS dapat mengurai dan memecahkan kode kode transfer yang dipotong. HTTP/1.1 tidak mendefinisikan cara apa pun untuk membatasi ukuran respons yang terpotong sehingga perantara dapat yakin akan melakukan buffering terhadap keseluruhan respons. Selain itu, ukuran potongan yang sangat besar dapat menyebabkan luapan atau hilangnya presisi jika nilainya tidak direpresentasikan secara akurat dalam implementasi penerimaan. Oleh karena itu, penerima HARUS mengantisipasi potensi angka heksadesimal yang besar dan mencegah kesalahan penguraian akibat luapan konversi bilangan bulat atau hilangnya presisi karena representasi bilangan bulat. Pengkodean yang dipotong tidak menentukan parameter apa pun. Kehadiran mereka HARUS dianggap sebagai sebuah kesalahan. 7.1.1. Ekstensi Potongan Pengkodean potongan memungkinkan setiap potongan untuk menyertakan nol atau lebih ekstensi potongan, segera setelah ukuran potongan, demi menyediakan metadata per potongan (seperti tanda tangan atau hash), informasi kontrol tengah pesan, atau pengacakan ukuran isi pesan. chunk-ext = *( BWS ";" BWS chunk-ext-name [ BWS "=" BWS chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token / kutipan-string Pengkodean yang dipotong bersifat spesifik untuk setiap koneksi dan kemungkinan besar akan dihapus atau dikodekan ulang oleh setiap penerima (termasuk perantara) sebelum aplikasi tingkat yang lebih tinggi memiliki kesempatan untuk memeriksa ekstensi. Oleh karena itu, penggunaan ekstensi chunk umumnya terbatas pada layanan HTTP khusus seperti "polling panjang" (di mana klien dan server dapat memiliki ekspektasi yang sama mengenai penggunaan ekstensi chunk) atau untuk padding dalam koneksi aman end-to-end. Penerima HARUS mengabaikan ekstensi potongan yang tidak dikenal. Server harus membatasi panjang total ekstensi potongan yang diterima dalam permintaan ke jumlah yang wajar untuk layanan yang diberikan, dengan cara yang sama seperti server menerapkan batasan panjang dan batas waktu untuk bagian lain dari pesan, dan menghasilkan respons 4xx (Kesalahan Klien) yang sesuai jika jumlah tersebut terlampaui. 7.1.2. Bagian Cuplikan Bagian Bagian cuplikan memungkinkan pengirim untuk menyertakan kolom tambahan di akhir pesan yang dipotong untuk menyediakan metadata yang mungkin dihasilkan secara dinamis saat konten dikirim, seperti pemeriksaan integritas pesan, tanda tangan digital, atau pasca-pemrosesan. status. Penggunaan yang tepat dan batasan bidang cuplikan ditentukan dalam Bagian 6.5 [HTTP]. trailer-section = *( field-line CRLF ) Penerima yang menghapus potongan kode dari pesan MUNGKIN secara selektif mempertahankan atau membuang bidang cuplikan yang diterima. Penerima yang menyimpan bidang cuplikan yang diterima HARUS menyimpan/meneruskan bidang cuplikan secara terpisah dari bidang header yang diterima atau menggabungkan bidang cuplikan yang diterima ke dalam bagian header. Penerima TIDAK BOLEH menggabungkan bidang cuplikan yang diterima ke dalam bagian header kecuali definisi bidang header yang terkait secara eksplisit mengizinkan dan menginstruksikan bagaimana nilai bidang cuplikan dapat digabungkan dengan aman. 7.1.3. Decoding Chunked Proses untuk decoding kode transfer chunked dapat direpresentasikan dalam pseudo-code sebagai: length := 0 read chunk-size, chunk-ext (jika ada), dan CRLF while (chunk-size > 0) { read chunk- data dan CRLF menambahkan data potongan ke panjang konten := panjang + ukuran potongan baca ukuran potongan, potongan-ext (jika ada), dan CRLF } baca bidang cuplikan sementara (bidang cuplikan tidak kosong) { if (bidang cuplikan tidak kosong) disimpan/diteruskan secara terpisah) { menambahkan bidang cuplikan ke bidang cuplikan yang ada } else if (bidang cuplikan dipahami dan didefinisikan sebagai dapat digabungkan) { menggabungkan bidang cuplikan dengan bidang header yang ada } else { membuang bidang cuplikan } membaca bidang cuplikan } Panjang Konten := length Hapus "dipotong" dari Transfer-Encoding 7.2. Pengkodean Transfer untuk Kompresi Nama pengkodean transfer untuk kompresi berikut ditentukan oleh algoritma yang sama dengan pengkodean konten terkait: kompres (dan x-kompres) Lihat Bagian 8.4.1.1 dari [HTTP]. mengempis Lihat Bagian 8.4.1.2 dari [HTTP]. gzip (dan x-gzip) Lihat Bagian 8.4.1.3 dari [HTTP]. Pengkodean kompresi tidak menentukan parameter apa pun. Kehadiran parameter dengan salah satu kode kompresi ini HARUS dianggap sebagai kesalahan. 7.3. Transfer Coding Registry "HTTP Transfer Coding Registry" mendefinisikan namespace untuk nama pengkodean transfer. Itu dipertahankan di Penerima yang menyimpan bidang cuplikan yang diterima HARUS menyimpan/meneruskan bidang cuplikan secara terpisah dari bidang header yang diterima atau menggabungkan bidang cuplikan yang diterima ke dalam bagian header. Penerima TIDAK BOLEH menggabungkan bidang cuplikan yang diterima ke dalam bagian header kecuali definisi bidang header yang terkait secara eksplisit mengizinkan dan menginstruksikan bagaimana nilai bidang cuplikan dapat digabungkan dengan aman. 7.1.3. Decoding Chunked Proses untuk decoding kode transfer chunked dapat direpresentasikan dalam pseudo-code sebagai: length := 0 read chunk-size, chunk-ext (jika ada), dan CRLF while (chunk-size > 0) { read chunk- data dan CRLF menambahkan data potongan ke panjang konten := panjang + ukuran potongan baca ukuran potongan, potongan-ext (jika ada), dan CRLF } baca bidang cuplikan sementara (bidang cuplikan tidak kosong) { if (bidang cuplikan tidak kosong) disimpan/diteruskan secara terpisah) { menambahkan bidang cuplikan ke bidang cuplikan yang ada } else if (bidang cuplikan dipahami dan didefinisikan sebagai dapat digabungkan) { menggabungkan bidang cuplikan dengan bidang header yang ada } else { membuang bidang cuplikan } membaca bidang cuplikan } Panjang Konten := length Hapus "dipotong" dari Transfer-Encoding 7.2. Pengkodean Transfer untuk Kompresi Nama pengkodean transfer untuk kompresi berikut ditentukan oleh algoritma yang sama dengan pengkodean konten terkait: kompres (dan x-kompres) Lihat Bagian 8.4.1.1 dari [HTTP]. mengempis Lihat Bagian 8.4.1.2 dari [HTTP]. gzip (dan x-gzip) Lihat Bagian 8.4.1.3 dari [HTTP]. Pengkodean kompresi tidak menentukan parameter apa pun. Kehadiran parameter dengan salah satu kode kompresi ini HARUS dianggap sebagai kesalahan. 7.3. Transfer Coding Registry "HTTP Transfer Coding Registry" mendefinisikan namespace untuk nama pengkodean transfer. Itu dipertahankan di Penerima yang menyimpan bidang cuplikan yang diterima HARUS menyimpan/meneruskan bidang cuplikan secara terpisah dari bidang header yang diterima atau menggabungkan bidang cuplikan yang diterima ke dalam bagian header. Penerima TIDAK BOLEH menggabungkan bidang cuplikan yang diterima ke dalam bagian header kecuali definisi bidang header yang terkait secara eksplisit mengizinkan dan menginstruksikan bagaimana nilai bidang cuplikan dapat digabungkan dengan aman. 7.1.3. Decoding Chunked Proses untuk decoding kode transfer chunked dapat direpresentasikan dalam pseudo-code sebagai: length := 0 read chunk-size, chunk-ext (jika ada), dan CRLF while (chunk-size > 0) { read chunk- data dan CRLF menambahkan data potongan ke panjang konten := panjang + ukuran potongan baca ukuran potongan, potongan-ext (jika ada), dan CRLF } baca bidang cuplikan sementara (bidang cuplikan tidak kosong) { if (bidang cuplikan tidak kosong) disimpan/diteruskan secara terpisah) { menambahkan bidang cuplikan ke bidang cuplikan yang ada } else if (bidang cuplikan dipahami dan didefinisikan sebagai dapat digabungkan) { menggabungkan bidang cuplikan dengan bidang header yang ada } else { membuang bidang cuplikan } membaca bidang cuplikan } Panjang Konten := length Hapus "dipotong" dari Transfer-Encoding 7.2. Pengkodean Transfer untuk Kompresi Nama pengkodean transfer untuk kompresi berikut ditentukan oleh algoritma yang sama dengan pengkodean konten terkait: kompres (dan x-kompres) Lihat Bagian 8.4.1.1 dari [HTTP]. mengempis Lihat Bagian 8.4.1.2 dari [HTTP]. gzip (dan x-gzip) Lihat Bagian 8.4.1.3 dari [HTTP]. Pengkodean kompresi tidak menentukan parameter apa pun. Kehadiran parameter dengan salah satu kode kompresi ini HARUS dianggap sebagai kesalahan. 7.3. Transfer Coding Registry "HTTP Transfer Coding Registry" mendefinisikan namespace untuk nama pengkodean transfer. Itu dipertahankan di kompres (dan x-kompres) Lihat Bagian 8.4.1.1 dari [HTTP]. mengempis Lihat Bagian 8.4.1.2 dari [HTTP]. gzip (dan x-gzip) Lihat Bagian 8.4.1.3 dari [HTTP]. Pengkodean kompresi tidak menentukan parameter apa pun. Kehadiran parameter dengan salah satu kode kompresi ini HARUS dianggap sebagai kesalahan. 7.3. Transfer Coding Registry "HTTP Transfer Coding Registry" mendefinisikan namespace untuk nama pengkodean transfer. Itu dipertahankan di kompres (dan x-kompres) Lihat Bagian 8.4.1.1 dari [HTTP]. mengempis Lihat Bagian 8.4.1.2 dari [HTTP]. gzip (dan x-gzip) Lihat Bagian 8.4.1.3 dari [HTTP]. Pengkodean kompresi tidak menentukan parameter apa pun. Kehadiran parameter dengan salah satu kode kompresi ini HARUS dianggap sebagai kesalahan. 7.3. Transfer Coding Registry "HTTP Transfer Coding Registry" mendefinisikan namespace untuk nama pengkodean transfer. Itu dipertahankan di

                    

                     . Pendaftaran HARUS menyertakan kolom berikut: * Nama * Deskripsi * Penunjuk untuk menentukan teks Nama kode transfer TIDAK BOLEH tumpang tindih dengan nama kode konten (Bagian 8.4.1 dari [HTTP]) kecuali transformasi pengkodeannya identik, seperti halnya untuk kode kompresi yang ditentukan dalam Bagian 7.2. Bidang header TE (Bagian 10.1.4 dari [HTTP]) menggunakan parameter semu bernama "q" sebagai nilai peringkat ketika beberapa kode transfer dapat diterima. Registrasi kode transfer di masa mendatang TIDAK BOLEH menentukan parameter yang disebut "q" (tidak peka huruf besar-kecil) untuk menghindari ambiguitas. Nilai yang akan ditambahkan ke namespace ini memerlukan Tinjauan IETF (lihat Bagian 4.8 dari [RFC8126]) dan HARUS sesuai dengan tujuan pengkodean transfer yang ditentukan dalam spesifikasi ini. Penggunaan nama program untuk identifikasi format pengkodean tidak diinginkan dan tidak disarankan untuk pengkodean di masa depan. 7.4. Menegosiasikan Kode Transfer Bidang TE (Bagian 10.1.4 dari [HTTP]) digunakan dalam HTTP/1.1 untuk menunjukkan kode transfer apa, selain dipotong, klien bersedia menerima respons dan apakah klien bersedia mempertahankan bidang cuplikan dalam kode transfer yang dipotong. Klien TIDAK HARUS mengirimkan nama kode transfer yang dipotong dalam TE; chunked selalu dapat diterima oleh penerima HTTP/1.1. Tiga contoh penggunaan TE ada di bawah. TE: mengempis TE: TE: trailer, mengempis;q=0,5 Ketika beberapa kode transfer dapat diterima, klien MUNGKIN memberi peringkat pada kode berdasarkan preferensi menggunakan parameter "q" yang tidak peka huruf besar-kecil (mirip dengan nilai q yang digunakan dalam bidang negosiasi konten ; lihat Bagian 12.4.2 dari [HTTP]). Nilai peringkat merupakan bilangan real dalam rentang 0 sampai 1, dimana 0,001 adalah yang paling tidak disukai dan 1 adalah yang paling disukai; nilai 0 berarti “tidak dapat diterima”. Jika nilai bidang TE kosong atau jika tidak ada bidang TE, satu-satunya kode transfer yang dapat diterima adalah yang terpotong. Pesan tanpa kode transfer selalu dapat diterima. Kata kunci "trailer" menunjukkan bahwa pengirim tidak akan membuang kolom trailer, seperti yang dijelaskan dalam Bagian 6.5 [HTTP]. Karena bidang header TE hanya berlaku untuk koneksi langsung, pengirim TE juga HARUS mengirimkan opsi koneksi "TE" dalam bidang header Koneksi (Bagian 7.6.1 dari [HTTP]) untuk mencegah bidang header TE diteruskan oleh perantara yang tidak mendukung semantiknya. 8. Menangani Pesan yang Tidak Lengkap Server yang menerima pesan permintaan yang tidak lengkap, biasanya karena permintaan yang dibatalkan atau pengecualian batas waktu yang dipicu, MUNGKIN mengirimkan respons kesalahan sebelum menutup koneksi. Klien yang menerima pesan respons yang tidak lengkap, yang dapat terjadi ketika koneksi ditutup sebelum waktunya atau ketika penguraian kode transfer yang seharusnya terpotong gagal, HARUS mencatat pesan tersebut sebagai tidak lengkap. Persyaratan cache untuk respons yang tidak lengkap dijelaskan di Bagian 3.3 dari [CACHING]. Jika respons berakhir di tengah bagian header (sebelum baris kosong diterima) dan kode status mungkin bergantung pada kolom header untuk menyampaikan makna respons secara keseluruhan, maka klien tidak dapat berasumsi bahwa makna telah disampaikan; klien mungkin perlu mengulangi permintaan tersebut untuk menentukan tindakan apa yang harus diambil selanjutnya. Isi pesan yang menggunakan kode transfer terpotong tidak lengkap jika potongan berukuran nol yang mengakhiri pengkodean belum diterima. Pesan yang menggunakan Content-Length yang valid tidak lengkap jika ukuran isi pesan yang diterima (dalam oktet) lebih kecil dari nilai yang diberikan oleh Content-Length. Respons yang tidak memiliki pengkodean transfer terpotong atau Panjang Konten diakhiri dengan penutupan koneksi dan, jika bagian header diterima utuh, dianggap selesai kecuali kesalahan ditunjukkan oleh koneksi yang mendasarinya (misalnya, "penutupan tidak lengkap" di TLS akan membiarkan responsnya tidak lengkap, seperti dijelaskan di Bagian 9.8). 9. Manajemen Koneksi Pesan HTTP tidak bergantung pada protokol koneksi lapisan transport atau lapisan sesi yang mendasarinya. HTTP hanya mengasumsikan transportasi yang andal dengan pengiriman permintaan secara berurutan dan pengiriman tanggapan secara berurutan. Pemetaan struktur permintaan dan respons HTTP ke unit data protokol transport yang mendasarinya berada di luar cakupan spesifikasi ini. Seperti yang dijelaskan dalam Bagian 7.3 [HTTP], protokol koneksi spesifik yang akan digunakan untuk interaksi HTTP ditentukan oleh konfigurasi klien dan URI target. Misalnya, skema URI "http" (Bagian 4.2.1 dari [HTTP]) menunjukkan koneksi default TCP melalui IP, dengan port TCP default 80, namun klien mungkin dikonfigurasi untuk menggunakan proxy melalui beberapa koneksi lain , port, atau protokol. Implementasi HTTP diharapkan dapat terlibat dalam manajemen koneksi, yang mencakup pemeliharaan status koneksi saat ini, membuat koneksi baru atau menggunakan kembali koneksi yang sudah ada, memproses pesan yang diterima pada koneksi, mendeteksi kegagalan koneksi, dan menutup setiap koneksi. Kebanyakan klien memelihara beberapa koneksi secara paralel, termasuk lebih dari satu koneksi per titik akhir server. Sebagian besar server dirancang untuk memelihara ribuan koneksi secara bersamaan, sekaligus mengontrol antrean permintaan untuk memungkinkan penggunaan wajar dan mendeteksi serangan penolakan layanan. 9.1. Pembentukan Di luar cakupan spesifikasi ini untuk menjelaskan bagaimana koneksi dibuat melalui berbagai protokol lapisan transport atau sesi. Setiap koneksi HTTP dipetakan ke satu koneksi transport yang mendasarinya. 9.2. Mengaitkan Respons ke Permintaan HTTP/1.1 tidak menyertakan pengidentifikasi permintaan untuk mengaitkan pesan permintaan tertentu dengan satu atau lebih pesan respons terkait. Oleh karena itu, hal ini bergantung pada urutan kedatangan respons agar sesuai dengan urutan permintaan yang dibuat pada koneksi yang sama. Lebih dari satu pesan respons per permintaan hanya terjadi ketika satu atau lebih respons informasional (1xx; lihat Bagian 15.2 dari [HTTP]) mendahului respons akhir terhadap permintaan yang sama. Klien yang memiliki lebih dari satu permintaan yang belum terselesaikan pada suatu koneksi HARUS menyimpan daftar permintaan yang belum terselesaikan dalam urutan yang dikirim dan HARUS mengaitkan setiap pesan respons yang diterima pada koneksi tersebut ke permintaan luar biasa pertama yang belum menerima pesan final (non-1xx) tanggapan. Jika klien menerima data pada koneksi yang tidak memiliki permintaan yang belum terselesaikan, klien TIDAK HARUS menganggap data tersebut sebagai respons yang valid; klien HARUS menutup koneksi, karena batasan pesan sekarang menjadi ambigu, kecuali data hanya terdiri dari satu atau lebih CRLF (yang dapat dibuang per Bagian 2.2). 9.3. Persistensi HTTP/1.1 merupakan default untuk penggunaan "koneksi persisten", yang memungkinkan beberapa permintaan dan respons dilakukan melalui satu koneksi. Implementasi HTTP HARUS mendukung koneksi persisten. Penerima menentukan apakah suatu koneksi tetap ada atau tidak berdasarkan versi protokol dan bidang header Koneksi (Bagian 7.6.1 dari [HTTP]) dalam pesan yang terakhir diterima, jika ada: * Jika opsi koneksi "tutup" ada ( Pasal 9.6), koneksi tidak akan bertahan setelah respons saat ini; jika tidak, * Jika protokol yang diterima adalah HTTP/1.1 (atau lebih baru), koneksi akan tetap ada setelah respons saat ini; lain, * Jika protokol yang diterima adalah HTTP/1.0, opsi koneksi "tetap hidup" ada, baik penerima bukan proksi atau pesannya adalah respons, dan penerima ingin menghormati "keep-alive" HTTP/1.0 mekanisme hidup", koneksi akan tetap ada setelah respons saat ini; jika tidak, * Koneksi akan ditutup setelah respons saat ini. Klien yang tidak mendukung koneksi persisten HARUS mengirimkan opsi koneksi "tutup" di setiap pesan permintaan. Server yang tidak mendukung koneksi persisten HARUS mengirimkan opsi koneksi "tutup" di setiap pesan respons yang tidak memiliki kode status 1xx (Informasional). Klien MUNGKIN mengirim permintaan tambahan pada koneksi persisten hingga klien mengirim atau menerima opsi koneksi "tutup" atau menerima respons HTTP/1.0 tanpa opsi koneksi "tetap hidup". Agar tetap persisten, semua pesan pada koneksi harus memiliki panjang pesan yang ditentukan sendiri (yaitu, pesan yang tidak ditentukan oleh penutupan koneksi), seperti yang dijelaskan dalam Bagian 6. Server HARUS membaca seluruh isi atau tutup pesan permintaan koneksi setelah mengirimkan tanggapannya; jika tidak, sisa data pada koneksi persisten akan disalahartikan sebagai permintaan berikutnya. Demikian pula, klien HARUS membaca seluruh isi pesan respons jika ingin menggunakan kembali koneksi yang sama untuk permintaan berikutnya. Server proxy TIDAK HARUS memelihara koneksi persisten dengan klien HTTP/1.0 (lihat Lampiran C.2. 2 untuk informasi dan diskusi tentang masalah bidang header Keep-Alive yang diterapkan oleh banyak klien HTTP/1.0). Lihat Lampiran C.2.2 untuk informasi lebih lanjut tentang kompatibilitas mundur dengan klien HTTP/1.0. 9.3.1. Permintaan Mencoba Kembali Koneksi dapat ditutup kapan saja, dengan atau tanpa niat. Implementasi harus mengantisipasi kebutuhan untuk pulih dari kejadian dekat yang tidak sinkron. Kondisi di mana klien dapat secara otomatis mencoba kembali rangkaian permintaan yang belum terselesaikan ditentukan dalam Bagian 9.2.2 [HTTP]. 9.3.2. Pipelining Klien yang mendukung koneksi persisten MUNGKIN "menyalurkan" permintaannya (yaitu, mengirim beberapa permintaan tanpa menunggu setiap respons). Server MUNGKIN memproses serangkaian permintaan yang disalurkan secara paralel jika semuanya memiliki metode yang aman (Bagian 9.2.1 dari [HTTP]), namun HARUS mengirimkan tanggapan yang sesuai dalam urutan yang sama dengan permintaan yang diterima. Klien yang menyalurkan permintaan HARUS mencoba lagi permintaan yang belum terjawab jika koneksi ditutup sebelum menerima semua respons yang sesuai. Saat mencoba kembali permintaan yang disalurkan setelah koneksi gagal (koneksi tidak secara eksplisit ditutup oleh server dalam respons lengkap terakhirnya), klien TIDAK HARUS melakukan pipa segera setelah pembuatan koneksi, karena permintaan pertama yang tersisa di pipa sebelumnya mungkin menyebabkan respons kesalahan yang dapat hilang lagi jika beberapa permintaan dikirim pada koneksi yang ditutup sebelum waktunya (lihat masalah reset TCP yang dijelaskan di Bagian 9.6). Metode idempoten (Bagian 9.2.2 dari [HTTP]) penting untuk pipelining karena dapat dicoba ulang secara otomatis setelah kegagalan koneksi. Agen pengguna TIDAK BOLEH melakukan permintaan saluran setelah metode non-idempoten, hingga kode status respons akhir untuk metode tersebut telah diterima, kecuali agen pengguna memiliki sarana untuk mendeteksi dan memulihkan dari kondisi kegagalan parsial yang melibatkan urutan saluran pipa. Perantara yang menerima permintaan yang disalurkan MUNGKIN menyalurkan permintaan tersebut ketika meneruskannya ke dalam, karena ia dapat mengandalkan agen pengguna keluar untuk menentukan permintaan apa yang dapat disalurkan dengan aman. Jika koneksi masuk gagal sebelum menerima respons, perantara pipelining MUNGKIN mencoba mencoba kembali serangkaian permintaan yang belum menerima respons jika semua permintaan memiliki metode idempoten; jika tidak, perantara saluran pipa HARUS meneruskan tanggapan yang diterima dan kemudian menutup koneksi keluar yang sesuai sehingga agen pengguna keluar dapat memulihkannya. 9.4. Konkurensi Seorang klien harus membatasi jumlah koneksi terbuka simultan yang dikelolanya ke server tertentu. Revisi HTTP sebelumnya memberikan jumlah koneksi tertentu sebagai batas tertinggi, tetapi hal ini ternyata tidak praktis untuk banyak aplikasi. Akibatnya, spesifikasi ini tidak mewajibkan jumlah maksimum koneksi tertentu, namun justru mendorong klien untuk bersikap konservatif saat membuka banyak koneksi. Beberapa koneksi biasanya digunakan untuk menghindari masalah "pemblokiran head-of-line", dimana permintaan yang memerlukan pemrosesan sisi server yang signifikan dan/atau mentransfer konten yang sangat besar akan memblokir permintaan berikutnya pada koneksi yang sama. Namun, setiap koneksi menghabiskan sumber daya server. Selain itu, penggunaan banyak koneksi dapat menyebabkan efek samping yang tidak diinginkan pada jaringan yang padat. Menggunakan jumlah koneksi yang lebih besar juga dapat menyebabkan efek samping pada jaringan yang tidak padat, karena agregat dan perilaku pengiriman yang disinkronkan pada awalnya dapat menyebabkan kemacetan yang tidak akan terjadi jika koneksi paralel yang digunakan lebih sedikit. Perhatikan bahwa server mungkin menolak lalu lintas yang dianggap kasar atau merupakan karakteristik serangan penolakan layanan, seperti jumlah koneksi terbuka yang berlebihan dari satu klien. 9.5. Kegagalan dan Batas Waktu Server biasanya memiliki nilai batas waktu tertentu sehingga server tidak akan lagi mempertahankan koneksi yang tidak aktif. Server proxy mungkin menjadikan ini nilai yang lebih tinggi karena kemungkinan besar klien akan membuat lebih banyak koneksi melalui server proxy yang sama. Penggunaan koneksi persisten tidak memberikan persyaratan mengenai lamanya (atau keberadaan) batas waktu ini baik untuk klien maupun server. Klien atau server yang ingin time out HARUS menutup koneksi dengan baik. Implementasinya HARUS terus memantau koneksi terbuka untuk sinyal penutupan yang diterima dan meresponsnya sebagaimana mestinya, karena penutupan cepat kedua sisi koneksi memungkinkan sumber daya sistem yang dialokasikan dapat diperoleh kembali. Klien, server, atau proxy MUNGKIN menutup koneksi transport kapan saja. Misalnya, klien mungkin mulai mengirim permintaan baru pada saat yang sama ketika server memutuskan untuk menutup koneksi "idle". Dari sudut pandang server, koneksi sedang ditutup saat sedang menganggur, namun dari sudut pandang klien, permintaan sedang berlangsung. Server HARUS mempertahankan koneksi yang persisten, bila memungkinkan, dan memungkinkan mekanisme kontrol aliran transportasi yang mendasarinya untuk mengatasi kelebihan beban sementara daripada menghentikan koneksi dengan harapan bahwa klien akan mencoba lagi. Teknik terakhir ini dapat memperburuk kemacetan jaringan atau beban server. Klien yang mengirimkan isi pesan HARUS memantau koneksi jaringan untuk melihat respons kesalahan saat mengirimkan permintaan. Jika klien melihat respons yang menunjukkan server tidak ingin menerima isi pesan dan menutup koneksi, klien HARUS segera menghentikan transmisi isi pesan dan menutup sisi koneksinya. 9.6. Pembongkaran Opsi koneksi "tutup" didefinisikan sebagai sinyal bahwa pengirim akan menutup koneksi ini setelah respons selesai. Pengirim HARUS mengirimkan bidang header Koneksi (Bagian 7.6.1 dari [HTTP]) yang berisi opsi koneksi "tutup" ketika ingin menutup koneksi. Misalnya, Koneksi: tutup sebagai bidang header permintaan menunjukkan bahwa ini adalah permintaan terakhir yang akan dikirimkan klien pada koneksi ini, sedangkan dalam respons, bidang yang sama menunjukkan bahwa server akan menutup koneksi ini setelah pesan respons selesai. Perhatikan bahwa nama bidang "Tutup" dicadangkan, karena menggunakan nama tersebut sebagai bidang header mungkin bertentangan dengan opsi koneksi "tutup". Klien yang mengirimkan opsi koneksi "tutup" TIDAK HARUS mengirim permintaan lebih lanjut pada koneksi itu (setelah permintaan yang berisi "tutup") dan HARUS menutup koneksi setelah membaca pesan respons akhir yang sesuai dengan permintaan ini. Server yang menerima opsi koneksi "tutup" HARUS memulai penutupan koneksi (lihat di bawah) setelah server mengirimkan respons akhir terhadap permintaan yang berisi opsi koneksi "tutup". Server HARUS mengirimkan opsi koneksi "tutup" sebagai respons terakhirnya pada koneksi itu. Server TIDAK HARUS memproses permintaan lebih lanjut yang diterima pada koneksi itu. Server yang mengirimkan opsi koneksi "tutup" HARUS memulai penutupan koneksi (lihat di bawah) setelah server mengirimkan respons yang berisi opsi koneksi "tutup". Server TIDAK HARUS memproses permintaan lebih lanjut yang diterima pada koneksi itu. Klien yang menerima opsi koneksi "tutup" HARUS berhenti mengirimkan permintaan pada koneksi tersebut dan menutup koneksi setelah membaca pesan respons yang berisi opsi koneksi "tutup"; jika permintaan pipeline tambahan telah dikirim pada koneksi, klien TIDAK BOLEH berasumsi bahwa permintaan tersebut akan diproses oleh server. Jika server langsung menutup koneksi TCP, terdapat risiko besar bahwa klien tidak akan dapat membaca respons HTTP terakhir. Jika server menerima data tambahan dari klien pada koneksi tertutup penuh, seperti permintaan lain yang dikirim oleh klien sebelum menerima respons server, tumpukan TCP server akan mengirimkan paket reset ke klien; sayangnya, paket reset mungkin menghapus buffer input klien yang tidak diakui sebelum dapat dibaca dan diinterpretasikan oleh parser HTTP klien. Untuk menghindari masalah reset TCP, server biasanya menutup koneksi secara bertahap. Pertama, server melakukan setengah penutupan dengan hanya menutup sisi tulis dari koneksi baca/tulis. Server kemudian melanjutkan membaca dari koneksi sampai menerima penutupan yang sesuai oleh klien, atau sampai server cukup yakin bahwa tumpukan TCP-nya telah menerima pengakuan klien atas paket yang berisi respons terakhir server. Terakhir, server menutup koneksi sepenuhnya. Tidak diketahui apakah masalah reset hanya terjadi pada TCP atau mungkin juga ditemukan pada protokol koneksi transport lainnya. Perhatikan bahwa koneksi TCP yang setengah ditutup oleh klien tidak membatasi pesan permintaan, juga tidak berarti bahwa klien tidak lagi tertarik dengan tanggapan. Secara umum, sinyal transport tidak dapat diandalkan untuk kasus-kasus tepi sinyal, karena HTTP/1.1 tidak tergantung pada transport. 9.7. Inisiasi Koneksi TLS Secara konseptual, HTTP/TLS hanya mengirimkan pesan HTTP melalui koneksi yang diamankan melalui TLS [TLS13]. Klien HTTP juga bertindak sebagai klien TLS. Ini memulai koneksi ke server pada port yang sesuai dan mengirimkan TLS ClientHello untuk memulai jabat tangan TLS. Ketika jabat tangan TLS selesai, klien kemudian dapat memulai permintaan HTTP pertama. Semua data HTTP HARUS dikirim sebagai "data aplikasi" TLS tetapi diperlakukan seperti koneksi normal untuk HTTP (termasuk potensi penggunaan kembali sebagai koneksi persisten). 9.8. Penutupan Koneksi TLS TLS menggunakan pertukaran peringatan penutupan sebelum penutupan koneksi (tanpa kesalahan) untuk menyediakan penutupan koneksi yang aman; lihat Bagian 6.1 dari [TLS13]. Ketika peringatan penutupan yang valid diterima, implementasi dapat dipastikan bahwa tidak ada data lebih lanjut yang akan diterima pada koneksi tersebut. Ketika implementasi mengetahui bahwa ia telah mengirim atau menerima semua data pesan yang penting, biasanya dengan mendeteksi batas pesan HTTP, implementasi mungkin menghasilkan "penutupan tidak lengkap" dengan mengirimkan peringatan penutupan dan kemudian menutup koneksi tanpa menunggu untuk menerima pesan yang sesuai. peringatan penutupan dari rekannya. Penutupan yang tidak lengkap tidak mempertanyakan keamanan data yang telah diterima, namun dapat mengindikasikan bahwa data berikutnya mungkin telah terpotong. Karena TLS tidak secara langsung mengetahui pembingkaian pesan HTTP, data HTTP itu sendiri perlu diperiksa untuk menentukan apakah pesan sudah lengkap. Penanganan pesan yang tidak lengkap didefinisikan dalam Bagian 8. Ketika menghadapi penutupan yang tidak lengkap, klien HARUS menganggap semua permintaan yang telah diterimanya telah selesai, 1. sebanyak data yang ditentukan dalam bidang header Panjang Konten atau 2. terminal nol -panjang potongan (ketika Transfer-Encoding dari potongan digunakan). Respons yang tidak memiliki pengkodean transfer terpotong atau Panjang Konten akan selesai hanya jika peringatan penutupan yang valid telah diterima. Memperlakukan pesan yang tidak lengkap sebagai pesan yang lengkap dapat menyebabkan implementasi diserang. Klien yang mendeteksi penutupan yang tidak lengkap HARUS pulih dengan baik. Klien HARUS mengirimkan peringatan penutupan sebelum menutup koneksi. Klien yang tidak mengharapkan untuk menerima data lagi MUNGKIN memilih untuk tidak menunggu peringatan penutupan server dan cukup menutup koneksi, sehingga menghasilkan penutupan yang tidak lengkap di sisi server. Server HARUS bersiap untuk menerima penutupan yang tidak lengkap dari klien, karena klien sering kali dapat menemukan lokasi akhir data server. Server HARUS mencoba memulai pertukaran peringatan penutupan dengan klien sebelum menutup koneksi. Server MUNGKIN menutup koneksi setelah mengirimkan peringatan penutupan, sehingga menghasilkan penutupan yang tidak lengkap di sisi klien. 10. Melampirkan Pesan sebagai Data 10.1. Jenis Media pesan/http Jenis media "pesan/http" dapat digunakan untuk menyertakan satu permintaan HTTP atau pesan respons, asalkan mematuhi batasan MIME untuk semua jenis "pesan" mengenai panjang baris dan pengkodean. Karena keterbatasan panjang garis, nilai bidang dalam "pesan/http" diperbolehkan menggunakan pelipatan garis (obs-fold), seperti dijelaskan di Bagian 5.2, untuk menyampaikan nilai bidang melalui beberapa baris. Penerima data "pesan/http" HARUS mengganti lipatan baris usang dengan satu atau lebih karakter SP saat pesan digunakan. Ketik nama: pesan Nama subtipe: http Parameter yang diperlukan: N/A Parameter opsional: versi, jenis pesan versi: Nomor versi HTTP dari pesan yang disertakan (misalnya, "1.1"). Jika tidak ada, versinya dapat ditentukan dari baris pertama badan. msgtype: Jenis pesan -- "permintaan" atau "respons". Jika tidak ada, jenisnya dapat ditentukan dari baris pertama badan. Pertimbangan pengkodean: hanya "7bit", "8bit", atau "biner" yang diizinkan Pertimbangan keamanan: lihat Bagian 11 Pertimbangan interoperabilitas: N/A Spesifikasi yang dipublikasikan: RFC 9112 (lihat Bagian 10.1). Aplikasi yang menggunakan jenis media ini: N/A Pertimbangan pengidentifikasi fragmen: N/A Informasi tambahan: Nomor ajaib: N/A Nama alias yang tidak digunakan lagi untuk jenis ini: N/A Ekstensi file: N/A File Macintosh ketik kode: N/A Orang dan alamat email yang dapat dihubungi untuk informasi lebih lanjut: Lihat bagian Alamat Penulis. Tujuan penggunaan: UMUM Batasan penggunaan: N/A Penulis: Lihat bagian Alamat Penulis. Ubah pengontrol: IESG 10.2. Tipe Media application/http Tipe media "application/http" dapat digunakan untuk menyertakan pipeline dari satu atau lebih permintaan HTTP atau pesan respons (tidak dicampur). Jenis nama: aplikasi Nama subtipe: http Parameter yang diperlukan: N/A Parameter opsional: versi, jenis pesan versi: Nomor versi HTTP dari pesan yang disertakan (misalnya, "1.1"). Jika tidak ada, versinya dapat ditentukan dari baris pertama badan. msgtype: Jenis pesan -- "permintaan" atau "respons". Jika tidak ada, jenisnya dapat ditentukan dari baris pertama badan. Pertimbangan pengkodean: Pesan HTTP yang diapit oleh jenis ini berada dalam format "biner"; penggunaan Pengkodean-Transfer-Konten yang sesuai diperlukan saat dikirimkan melalui email. Pertimbangan keamanan: lihat Bagian 11 Pertimbangan interoperabilitas: N/A Spesifikasi yang dipublikasikan: RFC 9112 (lihat Bagian 10.2). Aplikasi yang menggunakan jenis media ini: N/A Pertimbangan pengidentifikasi fragmen: N/A Informasi tambahan: Nama alias yang tidak digunakan lagi untuk jenis ini: N/A Nomor ajaib: N/A Ekstensi file: N/A File Macintosh ketik kode: N/A Orang dan alamat email yang dapat dihubungi untuk informasi lebih lanjut: Lihat bagian Alamat Penulis. Tujuan penggunaan: UMUM Batasan penggunaan: N/A Penulis: Lihat bagian Alamat Penulis. Ubah pengontrol: IESG 11. Pertimbangan Keamanan Bagian ini dimaksudkan untuk memberi tahu pengembang, penyedia informasi, dan pengguna tentang pertimbangan keamanan yang diketahui relevan dengan sintaksis dan penguraian pesan HTTP. Pertimbangan keamanan tentang semantik HTTP, konten, dan perutean dibahas di [HTTP]. 11.1. Pemisahan Respon Pemisahan respons (alias injeksi CRLF) adalah teknik umum, yang digunakan dalam berbagai serangan pada penggunaan Web, yang mengeksploitasi sifat pembingkaian pesan HTTP berbasis garis dan asosiasi permintaan ke respons pada koneksi persisten [Klein]. Teknik ini bisa sangat merusak ketika permintaan melewati cache bersama. Pemisahan respons mengeksploitasi kerentanan di server (biasanya dalam server aplikasi) di mana penyerang dapat mengirim data yang disandikan dalam beberapa parameter permintaan yang kemudian didekodekan dan digaungkan dalam bidang header respons mana pun dari respons tersebut. Jika data yang didekodekan dibuat agar terlihat seperti respons telah berakhir dan respons berikutnya telah dimulai, respons tersebut telah dipecah, dan konten dalam respons kedua dikendalikan oleh penyerang. Penyerang kemudian dapat membuat permintaan lain pada koneksi persisten yang sama dan mengelabui penerima (termasuk perantara) agar percaya bahwa bagian kedua dari pemisahan tersebut adalah jawaban resmi untuk permintaan kedua. Misalnya, parameter dalam target-permintaan mungkin dibaca oleh server aplikasi dan digunakan kembali dalam pengalihan, sehingga parameter yang sama digaungkan di bidang header Lokasi pada respons. Jika parameter didekodekan oleh aplikasi dan tidak dikodekan dengan benar ketika ditempatkan di kolom respons, penyerang dapat mengirimkan oktet CRLF yang dikodekan dan konten lainnya yang akan membuat respons tunggal aplikasi terlihat seperti dua respons atau lebih. Pertahanan umum terhadap pemisahan respons adalah dengan memfilter permintaan data yang terlihat seperti CR dan LF yang dikodekan (misalnya, "%0D" dan "%0A"). Namun, hal ini mengasumsikan server aplikasi hanya melakukan decoding URI daripada transformasi data yang lebih tidak jelas seperti transcoding charset, terjemahan entitas XML, decoding base64, format ulang sprintf, dll. Mitigasi yang lebih efektif adalah mencegah apa pun selain pustaka protokol inti server mengirimkan CR atau LF dalam bagian header, yang berarti membatasi keluaran bidang header ke API yang memfilter oktet buruk dan tidak mengizinkan server aplikasi untuk menulis langsung ke aliran protokol. 11.2. Penyelundupan Permintaan Penyelundupan Permintaan ([Linhart]) adalah teknik yang mengeksploitasi perbedaan dalam penguraian protokol di antara berbagai penerima untuk menyembunyikan permintaan tambahan (yang mungkin diblokir atau dinonaktifkan oleh kebijakan) dalam permintaan yang tampaknya tidak berbahaya. Seperti pemisahan respons, penyelundupan permintaan dapat menyebabkan berbagai serangan terhadap penggunaan HTTP. Spesifikasi ini telah memperkenalkan persyaratan baru pada penguraian permintaan, khususnya yang berkaitan dengan pembingkaian pesan di Bagian 6.3, untuk mengurangi efektivitas penyelundupan permintaan. 11.3. Integritas Pesan HTTP tidak mendefinisikan mekanisme khusus untuk memastikan integritas pesan, melainkan mengandalkan kemampuan deteksi kesalahan protokol transport yang mendasarinya dan penggunaan framing yang panjangnya atau dibatasi potongan untuk mendeteksi kelengkapan. Secara historis, kurangnya mekanisme integritas tunggal telah dibenarkan oleh sifat informal dari sebagian besar komunikasi HTTP. Namun, prevalensi HTTP sebagai mekanisme akses informasi telah mengakibatkan meningkatnya penggunaannya dalam lingkungan di mana verifikasi integritas pesan sangat penting. Mekanisme yang disediakan dengan skema "https", seperti enkripsi yang diautentikasi, memberikan perlindungan terhadap modifikasi pesan. Namun diperlukan kehati-hatian untuk memastikan bahwa penutupan koneksi tidak dapat digunakan untuk memotong pesan (lihat Bagian 9.8). Agen pengguna mungkin menolak menerima pesan yang tidak lengkap atau memperlakukannya secara khusus. Misalnya, browser yang digunakan untuk melihat riwayat kesehatan atau informasi interaksi obat perlu menunjukkan kepada pengguna ketika informasi tersebut terdeteksi oleh protokol sebagai tidak lengkap, kedaluwarsa, atau rusak selama transfer. Mekanisme tersebut mungkin diaktifkan secara selektif melalui ekstensi agen pengguna atau adanya metadata integritas pesan dalam respons. Skema "http" tidak memberikan perlindungan terhadap modifikasi pesan yang tidak disengaja atau berbahaya. Perluasan protokol mungkin digunakan untuk mengurangi risiko modifikasi pesan yang tidak diinginkan oleh perantara, bahkan ketika skema "https" digunakan. Integritas dapat dijamin dengan menggunakan kode otentikasi pesan atau tanda tangan digital yang ditambahkan secara selektif ke pesan melalui bidang metadata yang dapat diperluas. 11.4. Kerahasiaan Pesan HTTP bergantung pada protokol transport yang mendasarinya untuk memberikan kerahasiaan pesan bila diinginkan. HTTP telah dirancang khusus agar tidak bergantung pada protokol transport, sehingga dapat digunakan pada berbagai bentuk koneksi terenkripsi, dengan pemilihan transport tersebut diidentifikasi berdasarkan pilihan skema URI atau dalam konfigurasi agen pengguna. Skema "https" dapat digunakan untuk mengidentifikasi sumber daya yang memerlukan koneksi rahasia, seperti yang dijelaskan dalam Bagian 4.2.2 [HTTP]. 12. Pertimbangan IANA Pengontrol perubahan untuk registrasi berikut adalah: "IETF (iesg@ietf.org) - Satuan Tugas Rekayasa Internet". 12.1. Registrasi Nama Bidang IANA telah menambahkan nama bidang berikut ke "Registrasi Nama Bidang Hypertext Transfer Protocol (HTTP)" di Secara historis, kurangnya mekanisme integritas tunggal telah dibenarkan oleh sifat informal dari sebagian besar komunikasi HTTP. Namun, prevalensi HTTP sebagai mekanisme akses informasi telah mengakibatkan meningkatnya penggunaannya dalam lingkungan di mana verifikasi integritas pesan sangat penting. Mekanisme yang disediakan dengan skema "https", seperti enkripsi yang diautentikasi, memberikan perlindungan terhadap modifikasi pesan. Namun diperlukan kehati-hatian untuk memastikan bahwa penutupan koneksi tidak dapat digunakan untuk memotong pesan (lihat Bagian 9.8). Agen pengguna mungkin menolak menerima pesan yang tidak lengkap atau memperlakukannya secara khusus. Misalnya, browser yang digunakan untuk melihat riwayat kesehatan atau informasi interaksi obat perlu menunjukkan kepada pengguna ketika informasi tersebut terdeteksi oleh protokol sebagai tidak lengkap, kedaluwarsa, atau rusak selama transfer. Mekanisme tersebut mungkin diaktifkan secara selektif melalui ekstensi agen pengguna atau adanya metadata integritas pesan dalam respons. Skema "http" tidak memberikan perlindungan terhadap modifikasi pesan yang tidak disengaja atau berbahaya. Perluasan protokol mungkin digunakan untuk mengurangi risiko modifikasi pesan yang tidak diinginkan oleh perantara, bahkan ketika skema "https" digunakan. Integritas dapat dijamin dengan menggunakan kode otentikasi pesan atau tanda tangan digital yang ditambahkan secara selektif ke pesan melalui bidang metadata yang dapat diperluas. 11.4. Kerahasiaan Pesan HTTP bergantung pada protokol transport yang mendasarinya untuk memberikan kerahasiaan pesan bila diinginkan. HTTP telah dirancang khusus agar tidak bergantung pada protokol transport, sehingga dapat digunakan pada berbagai bentuk koneksi terenkripsi, dengan pemilihan transport tersebut diidentifikasi berdasarkan pilihan skema URI atau dalam konfigurasi agen pengguna. Skema "https" dapat digunakan untuk mengidentifikasi sumber daya yang memerlukan koneksi rahasia, seperti yang dijelaskan dalam Bagian 4.2.2 [HTTP]. 12. Pertimbangan IANA Pengontrol perubahan untuk registrasi berikut adalah: "IETF (iesg@ietf.org) - Satuan Tugas Rekayasa Internet". 12.1. Registrasi Nama Bidang IANA telah menambahkan nama bidang berikut ke "Registrasi Nama Bidang Hypertext Transfer Protocol (HTTP)" di Secara historis, kurangnya mekanisme integritas tunggal telah dibenarkan oleh sifat informal dari sebagian besar komunikasi HTTP. Namun, prevalensi HTTP sebagai mekanisme akses informasi telah mengakibatkan meningkatnya penggunaannya dalam lingkungan di mana verifikasi integritas pesan sangat penting. Mekanisme yang disediakan dengan skema "https", seperti enkripsi yang diautentikasi, memberikan perlindungan terhadap modifikasi pesan. Namun diperlukan kehati-hatian untuk memastikan bahwa penutupan koneksi tidak dapat digunakan untuk memotong pesan (lihat Bagian 9.8). Agen pengguna mungkin menolak menerima pesan yang tidak lengkap atau memperlakukannya secara khusus. Misalnya, browser yang digunakan untuk melihat riwayat kesehatan atau informasi interaksi obat perlu menunjukkan kepada pengguna ketika informasi tersebut terdeteksi oleh protokol sebagai tidak lengkap, kedaluwarsa, atau rusak selama transfer. Mekanisme tersebut mungkin diaktifkan secara selektif melalui ekstensi agen pengguna atau adanya metadata integritas pesan dalam respons. Skema "http" tidak memberikan perlindungan terhadap modifikasi pesan yang tidak disengaja atau berbahaya. Perluasan protokol mungkin digunakan untuk mengurangi risiko modifikasi pesan yang tidak diinginkan oleh perantara, bahkan ketika skema "https" digunakan. Integritas dapat dijamin dengan menggunakan kode otentikasi pesan atau tanda tangan digital yang ditambahkan secara selektif ke pesan melalui bidang metadata yang dapat diperluas. 11.4. Kerahasiaan Pesan HTTP bergantung pada protokol transport yang mendasarinya untuk memberikan kerahasiaan pesan bila diinginkan. HTTP telah dirancang khusus agar tidak bergantung pada protokol transport, sehingga dapat digunakan pada berbagai bentuk koneksi terenkripsi, dengan pemilihan transport tersebut diidentifikasi berdasarkan pilihan skema URI atau dalam konfigurasi agen pengguna. Skema "https" dapat digunakan untuk mengidentifikasi sumber daya yang memerlukan koneksi rahasia, seperti yang dijelaskan dalam Bagian 4.2.2 [HTTP]. 12. Pertimbangan IANA Pengontrol perubahan untuk registrasi berikut adalah: "IETF (iesg@ietf.org) - Satuan Tugas Rekayasa Internet". 12.1. Registrasi Nama Bidang IANA telah menambahkan nama bidang berikut ke "Registrasi Nama Bidang Hypertext Transfer Protocol (HTTP)" di browser yang digunakan untuk melihat riwayat kesehatan atau informasi interaksi obat perlu menunjukkan kepada pengguna ketika informasi tersebut terdeteksi oleh protokol sebagai tidak lengkap, kedaluwarsa, atau rusak selama transfer. Mekanisme tersebut mungkin diaktifkan secara selektif melalui ekstensi agen pengguna atau adanya metadata integritas pesan dalam respons. Skema "http" tidak memberikan perlindungan terhadap modifikasi pesan yang tidak disengaja atau berbahaya. Perluasan protokol mungkin digunakan untuk mengurangi risiko modifikasi pesan yang tidak diinginkan oleh perantara, bahkan ketika skema "https" digunakan. Integritas dapat dijamin dengan menggunakan kode otentikasi pesan atau tanda tangan digital yang ditambahkan secara selektif ke pesan melalui bidang metadata yang dapat diperluas. 11.4. Kerahasiaan Pesan HTTP bergantung pada protokol transport yang mendasarinya untuk memberikan kerahasiaan pesan bila diinginkan. HTTP telah dirancang khusus agar tidak bergantung pada protokol transport, sehingga dapat digunakan pada berbagai bentuk koneksi terenkripsi, dengan pemilihan transport tersebut diidentifikasi berdasarkan pilihan skema URI atau dalam konfigurasi agen pengguna. Skema "https" dapat digunakan untuk mengidentifikasi sumber daya yang memerlukan koneksi rahasia, seperti yang dijelaskan dalam Bagian 4.2.2 [HTTP]. 12. Pertimbangan IANA Pengontrol perubahan untuk registrasi berikut adalah: "IETF (iesg@ietf.org) - Satuan Tugas Rekayasa Internet". 12.1. Registrasi Nama Bidang IANA telah menambahkan nama bidang berikut ke "Registrasi Nama Bidang Hypertext Transfer Protocol (HTTP)" di browser yang digunakan untuk melihat riwayat kesehatan atau informasi interaksi obat perlu menunjukkan kepada pengguna ketika informasi tersebut terdeteksi oleh protokol sebagai tidak lengkap, kedaluwarsa, atau rusak selama transfer. Mekanisme tersebut mungkin diaktifkan secara selektif melalui ekstensi agen pengguna atau adanya metadata integritas pesan dalam respons. Skema "http" tidak memberikan perlindungan terhadap modifikasi pesan yang tidak disengaja atau berbahaya. Perluasan protokol mungkin digunakan untuk mengurangi risiko modifikasi pesan yang tidak diinginkan oleh perantara, bahkan ketika skema "https" digunakan. Integritas dapat dijamin dengan menggunakan kode otentikasi pesan atau tanda tangan digital yang ditambahkan secara selektif ke pesan melalui bidang metadata yang dapat diperluas. 11.4. Kerahasiaan Pesan HTTP bergantung pada protokol transport yang mendasarinya untuk memberikan kerahasiaan pesan bila diinginkan. HTTP telah dirancang khusus agar tidak bergantung pada protokol transport, sehingga dapat digunakan pada berbagai bentuk koneksi terenkripsi, dengan pemilihan transport tersebut diidentifikasi berdasarkan pilihan skema URI atau dalam konfigurasi agen pengguna. Skema "https" dapat digunakan untuk mengidentifikasi sumber daya yang memerlukan koneksi rahasia, seperti yang dijelaskan dalam Bagian 4.2.2 [HTTP]. 12. Pertimbangan IANA Pengontrol perubahan untuk registrasi berikut adalah: "IETF (iesg@ietf.org) - Satuan Tugas Rekayasa Internet". 12.1. Registrasi Nama Bidang IANA telah menambahkan nama bidang berikut ke "Registrasi Nama Bidang Hypertext Transfer Protocol (HTTP)" di

                     

                      , seperti yang dijelaskan dalam Bagian 18.4 dari [HTTP]. +======+===========+=========+======== =====+ | Nama Bidang | Status | Bagian | Komentar | +======+===========+=========+======== =====+ | Tutup | permanen | 9.6 | (dipesan) | +--------+-----------+---------+--- ------- -----+ | Versi MIME | permanen | B.1 | | +--------+-----------+---------+--- ------- -----+ | Pengkodean Transfer | permanen | 6.1 | | +--------+-----------+---------+--- ------- -----+ Tabel 1 12.2. Registrasi Jenis Media IANA telah memperbarui registri "Jenis Media" di

                      

                       dengan informasi pendaftaran di Bagian 10.1 dan 10.2 untuk masing-masing jenis media "pesan/http" dan "aplikasi/http". 12.3. Registrasi Transfer Coding IANA telah memperbarui "HTTP Transfer Coding Registry" di

                       dengan prosedur pendaftaran Bagian 7.3 dan nama pengkodean konten dirangkum dalam tabel di bawah ini. +============+======= ===== =======+=========+ | Nama | Deskripsi | Bagian | +============+======= ===== =======+=========+ | dipotong | Transfer dalam serangkaian potongan | 7.1 | +------------+------------------------------------- -------+---------+ | kompres | UNIX "kompres" format data [Welch] | 7.2 | +------------+------------------------------------- -------+---------+ | mengempis | data terkompresi "mengempiskan" ([RFC1951]) | 7.2 | | | di dalam format data "zlib" ([RFC1950]) | | +------------+------------------------------------- -------+---------+ | gzip | Format berkas GZIP [RFC1952] | 7.2 | +------------+------------------------------------- -------+---------+ | trailer | (dipesan) | 12.3 | +------------+------------------------------------- -------+---------+ | x-kompres | Tidak digunakan lagi (alias untuk kompres) | 7.2 | +------------+------------------------------------- -------+---------+ | x-gzip | Tidak digunakan lagi (alias untuk gzip) | 7.2 | +------------+------------------------------------- -------+---------+ Tabel 2 | *Catatan:* nama pengkodean "trailer" dicadangkan karena penggunaannya | akan bertentangan dengan kata kunci "trailer" di header TE | bidang (Bagian 10.1.4 dari [HTTP]). 12.4. Registrasi ID Protokol ALPN IANA telah memperbarui registri "ID Protokol Negosiasi Lapisan Aplikasi TLS (ALPN)" di 

                       dengan registrasi dibawah ini : +==========+=+=== ========+ | Protokol | Urutan Identifikasi | Referensi | +==========+==+======== ===+ | HTTP/1.1 | 0x68 0x74 0x74 0x70 0x2f | RFC 9112 | | | 0x31 0x2e 0x31 ("http/1.1") | | +----------+--------+-------- ---+ Tabel 3 13. Referensi 13.1. Referensi Standar [CACHING] Fielding, R., Ed., Nottingham, M., Ed., dan J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, Juni 2022, 

                       

                        . [HTTP] Fielding, R., Ed., Nottingham, M., Ed., dan J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, Juni 2022,

                        

                         . [RFC1950] Deutsch, P. dan JL. Gailly, "Spesifikasi Format Data Terkompresi ZLIB versi 3.3", RFC 1950, DOI 10.17487/RFC1950, Mei 1996,

                         

                          . [RFC1951] Deutsch, P., "DEFLATE Compressed Data Format Spesifikasi versi 1.3", RFC 1951, DOI 10.17487/RFC1951, Mei 1996,

                          

                           . [RFC1952] Deutsch, P., "Spesifikasi format file GZIP versi 4.3", RFC 1952, DOI 10.17487/RFC1952, Mei 1996,

                           

                            . [RFC2119] Bradner, S., "Kata kunci untuk digunakan dalam RFC untuk Menunjukkan Tingkat Persyaratan", BCP 14, RFC 2119, DOI 10.17487/RFC2119, Maret 1997,

                            

                             . [RFC5234] Crocker, D., Ed. dan P. Overell, "BNF Augmented untuk Spesifikasi Sintaks: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, Januari 2008,

                             

                              . [RFC7405] Kyzivat, P., "Dukungan String Peka Huruf Besar-kecil di ABNF", RFC 7405, DOI 10.17487/RFC7405, Desember 2014,

                              

                              . [RFC8174] Leiba, B., "Ambiguitas Huruf Besar vs Huruf Kecil dalam Kata Kunci RFC 2119", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Mei 2017,

                              

                              . [TLS13] Rescorla, E., "Protokol Keamanan Lapisan Transportasi (TLS) Versi 1.3", RFC 8446, DOI 10.17487/RFC8446, Agustus 2018,

                              

                              . [URI] Berners-Lee, T., Fielding, R., dan L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, Januari 2005,

                              

                              . [USASCII] Institut Standar Nasional Amerika, "Kumpulan Karakter Berkode -- Kode Standar Amerika 7-bit untuk Pertukaran Informasi," ANSI X3.4, 1986. [Welch] Welch, T., "Teknik Kompresi Data Berkinerja Tinggi" , Komputer IEEE 17(6), DOI 10.1109/MC.1984.1659158, Juni 1984,

                              . 13.2. Referensi Informatif [HTTP/1.0] Berners-Lee, T., Fielding, R., dan H. Frystyk, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, DOI 10.17487/RFC1945, Mei 1996, 

                              

                              . [Klein] Klein, A., "Divide and Conquer - Pemisahan Respons HTTP, Serangan Keracunan Cache Web, dan Topik Terkait", Maret 2004,

                              

                              . [Linhart] Linhart, C., Klein, A., Heled, R., dan S. Orrin, "Penyelundupan Permintaan HTTP", Juni 2005,

                              

                              . [RFC2045] Freed, N. dan N. Borenstein, "Ekstensi Surat Internet Multiguna (MIME) Bagian Satu: Format Badan Pesan Internet", RFC 2045, DOI 10.17487/RFC2045, November 1996,

                              

                              . [RFC2046] Freed, N. dan N. Borenstein, "Ekstensi Surat Internet Multiguna (MIME) Bagian Dua: Jenis Media", RFC 2046, DOI 10.17487/RFC2046, November 1996,

                              

                              . [RFC2049] Freed, N. dan N. Borenstein, "Ekstensi Surat Internet Multiguna (MIME) Bagian Lima: Kriteria dan Contoh Kesesuaian", RFC 2049, DOI 10.17487/RFC2049, November 1996,

                              

                              . [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., dan T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, DOI 10.17487/RFC2068, Januari 1997,

                              

                              . [RFC2557] Palme, J., Hopmann, A., dan N. Shelness, "Enkapsulasi MIME Dokumen Agregat, seperti HTML (MHTML)", RFC 2557, DOI 10.17487/RFC2557, Maret 1999,

                              

                              . [RFC5322] Resnick, P., Ed., "Format Pesan Internet", RFC 5322, DOI 10.17487/RFC5322, Oktober 2008,

                              

                              . [RFC7230] Fielding, R., Ed. dan J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Sintaks dan Perutean Pesan", RFC 7230, DOI 10.17487/RFC7230, Juni 2014,

                              

                              . [RFC8126] Cotton, M., Leiba, B., dan T. Narten, "Pedoman Penulisan Bagian Pertimbangan IANA dalam RFC", BCP 26, RFC 8126, DOI 10.17487/RFC8126, Juni 2017,

                              

                              . Lampiran A. Kumpulan ABNF Dalam kumpulan ABNF di bawah ini, aturan daftar diperluas sesuai Bagian 5.6.1 [HTTP]. BWS =

                              

                              Pesan HTTP = CRLF baris awal *( CRLF baris bidang ) CRLF [ isi pesan ] Nama HTTP = %x48.54.54.50 ; HTTP Versi HTTP = Nama HTTP "/" DIGIT "." DIGIT OWS =

                              

                              RWS =

                              

                              Transfer-Encoding = [ transfer-coding *( OWS "," OWS transfer-coding ) ] absolute-URI =

                              

                              bentuk absolut = jalur absolut URI absolut =

                              

                              bentuk asterisk = "*" otoritas =

                              

                              bentuk otoritas = uri-host ":" port potongan = ukuran potongan [ potongan-ext ] CRLF potongan-data CRLF potongan-data = 1*OCTET potongan-ext = *( BWS ";" BWS potongan-ext-nama [ BWS "=" BWS chunk-ext-val ] ) chunk-ext-name = token chunk-ext-val = token / kutipan-string chunk-size = 1*HEXDIG chunked-body = *chunk potongan terakhir trailer-bagian CRLF field-line = nama bidang ":" Nilai bidang OWS Nama bidang OWS =

                              

                              nilai bidang =

                              

                              potongan terakhir = 1*"0" [ potongan-ext ] Isi pesan CRLF = *Metode OCTET = token obs-fold = OWS CRLF RWS obs-teks =

                              

                              bentuk asal = jalur absolut [ "?" permintaan ] port =

                              

                              pertanyaan =

                              

                              kutipan-string =

                              

                              alasan-frasa = 1*( HTAB / SP / VCHAR / obs-teks ) baris permintaan = metode SP target-permintaan SP Target-permintaan versi HTTP = bentuk-asal / bentuk-mutlak / bentuk-otoritas / bentuk-tanda bintang mulai -line = baris permintaan / baris status kode status = 3DIGIT baris status = Kode status SP versi HTTP SP [ frase alasan ] token =

                              

                              trailer-section = *( CRLF garis lapangan ) transfer-coding =

                              

                              host-uri =

                              

                              Lampiran B. Perbedaan antara HTTP dan MIME HTTP/1.1 menggunakan banyak konstruksi yang ditentukan untuk Format Pesan Internet [RFC5322] dan Ekstensi Email Internet Multiguna (MIME) [RFC2045] untuk memungkinkan isi pesan dikirim dalam berbagai representasi terbuka dan dengan bidang yang dapat diperluas. Namun, beberapa konstruksi ini telah ditafsirkan ulang agar lebih sesuai dengan kebutuhan komunikasi interaktif, sehingga menyebabkan beberapa perbedaan dalam cara penggunaan konstruksi MIME dalam HTTP. Perbedaan ini dipilih dengan cermat untuk mengoptimalkan kinerja melalui koneksi biner, memberikan kebebasan lebih besar dalam penggunaan jenis media baru, memudahkan perbandingan, dan mengakomodasi implementasi umum. Lampiran ini menjelaskan area spesifik yang membedakan HTTP dengan MIME. Proksi dan gateway ke dan dari lingkungan MIME yang ketat perlu menyadari perbedaan ini dan menyediakan konversi yang sesuai jika diperlukan. B.1. HTTP Versi MIME bukan protokol yang sesuai dengan MIME. Namun, pesan dapat menyertakan satu kolom header Versi MIME untuk menunjukkan versi protokol MIME yang digunakan untuk membuat pesan. Penggunaan kolom header MIME- Version menunjukkan bahwa pesan tersebut sepenuhnya sesuai dengan protokol MIME (sebagaimana didefinisikan dalam [RFC2045]). Pengirim bertanggung jawab untuk memastikan kesesuaian penuh (jika memungkinkan) saat mengekspor pesan HTTP ke lingkungan MIME yang ketat. B.2. Konversi ke Bentuk Kanonik MIME mengharuskan bagian isi surat Internet dikonversi ke bentuk kanonik sebelum ditransfer, seperti yang dijelaskan dalam Bagian 4 [RFC2049], dan konten dengan jenis "teks" mewakili jeda baris sebagai CRLF, melarang penggunaan CR atau LF di luar urutan jeda baris [RFC2046]. Sebaliknya, HTTP tidak peduli apakah CRLF, bare CR, atau bare LF digunakan untuk menunjukkan jeda baris dalam konten. Proxy atau gateway dari HTTP ke lingkungan MIME yang ketat harus menerjemahkan semua jeda baris dalam jenis media teks ke bentuk CRLF kanonik RFC 2049. Namun perlu diperhatikan, hal ini mungkin menjadi rumit dengan adanya Content-Encoding dan fakta bahwa HTTP mengizinkan penggunaan beberapa rangkaian karakter yang tidak menggunakan oktet 13 dan 10 untuk masing-masing mewakili CR dan LF. Konversi akan mematahkan checksum kriptografi apa pun yang diterapkan pada konten asli kecuali konten asli sudah dalam bentuk kanonik. Oleh karena itu, bentuk kanonik direkomendasikan untuk konten apa pun yang menggunakan checksum tersebut dalam HTTP. B.3. Konversi Format Tanggal HTTP/1.1 menggunakan serangkaian format tanggal terbatas (Bagian 5.6.7 dari [HTTP]) untuk menyederhanakan proses perbandingan tanggal. Proksi dan gateway dari protokol lain harus memastikan bahwa bidang header Tanggal yang ada dalam pesan sesuai dengan salah satu format HTTP/1.1 dan menulis ulang tanggal jika perlu. B.4. Konversi MIME Pengkodean Konten tidak mencakup konsep apa pun yang setara dengan bidang header Pengkodean Konten HTTP. Karena ini bertindak sebagai pengubah jenis media, proksi dan gateway dari HTTP ke protokol yang mendukung MIME harus mengubah nilai bidang header Tipe Konten atau mendekode representasi sebelum meneruskan pesan. (Beberapa aplikasi eksperimental Tipe Konten untuk email Internet telah menggunakan parameter tipe media ";conversions=

                              

                              " untuk melakukan fungsi yang setara dengan Content-Encoding. Namun, parameter ini bukan bagian dari standar MIME.) B.5. Konversi Content-Transfer-Encoding HTTP tidak menggunakan bidang Content-Transfer-Encoding pada MIME. Proxy dan gateway dari protokol yang sesuai dengan MIME ke HTTP perlu menghapus semua Content-Transfer-Encoding sebelum mengirimkan pesan respons ke klien HTTP. Proxy dan gateway dari protokol yang sesuai dengan HTTP ke MIME bertanggung jawab untuk memastikan bahwa pesan tersebut berada di alamat yang benar. format dan pengkodean untuk pengangkutan aman pada protokol tersebut, di mana "transportasi aman" ditentukan oleh batasan protokol yang digunakan. Proxy atau gateway tersebut harus mengubah dan memberi label pada data dengan Pengkodean-Transfer-Konten yang sesuai jika hal tersebut akan meningkatkan kemungkinan transportasi yang aman melalui protokol tujuan.B.6.MHTML dan Batasan Panjang JalurImplementasi HTTP yang berbagi kode dengan implementasi MHTML [RFC2557] perlu menyadari batasan panjang jalur MIME. Karena HTTP tidak memiliki batasan ini, HTTP tidak melipat garis panjang. Pesan MHTML yang diangkut melalui HTTP mengikuti semua konvensi MHTML, termasuk batasan dan pelipatan panjang baris, kanonikalisasi, dll., karena HTTP mentransfer isi pesan tanpa modifikasi dan, selain dari tipe "multipart/byteranges" (Bagian 14.6 dari [HTTP] ), tidak menafsirkan konten atau baris header MIME apa pun yang mungkin terdapat di dalamnya. Lampiran C. Perubahan dari RFC Sebelumnya C.1. Perubahan dari HTTP/0.9 Karena HTTP/0.9 tidak mendukung bidang header dalam permintaan, tidak ada mekanisme untuk mendukung host virtual berbasis nama (pemilihan sumber daya dengan memeriksa bidang header Host). Server mana pun yang mengimplementasikan host virtual berbasis nama harus menonaktifkan dukungan untuk HTTP/0.9. Sebagian besar permintaan yang tampak seperti HTTP/0.9, pada kenyataannya, merupakan permintaan HTTP/1.x yang dibangun dengan buruk yang disebabkan oleh klien yang gagal mengkodekan target permintaan dengan benar. C.2. Perubahan dari HTTP/1.0 C.2.1. Server Web Multihome Persyaratan bahwa klien dan server mendukung bidang header Host (Bagian 7.2 dari [HTTP]), melaporkan kesalahan jika tidak ada dalam permintaan HTTP/1.1, dan menerima URI absolut (Bagian 3.2) termasuk yang paling penting perubahan yang ditentukan oleh HTTP/1.1. Klien HTTP/1.0 yang lebih lama mengasumsikan hubungan alamat IP dan server satu-ke-satu; tidak ada mekanisme yang ditetapkan untuk membedakan server yang dituju dari suatu permintaan selain alamat IP yang menjadi tujuan permintaan tersebut. Bidang header Host diperkenalkan selama pengembangan HTTP/1.1 dan, meskipun dengan cepat diterapkan oleh sebagian besar browser HTTP/1.0, persyaratan tambahan ditempatkan pada semua permintaan HTTP/1.1 untuk memastikan adopsi yang lengkap. Pada saat penulisan ini, sebagian besar layanan berbasis HTTP bergantung pada bidang header Host untuk permintaan penargetan. C.2.2. Koneksi Tetap Hidup Di HTTP/1.0, setiap koneksi dibuat oleh klien sebelum permintaan dan ditutup oleh server setelah mengirimkan respons. Namun, beberapa implementasi menerapkan versi koneksi persisten yang dinegosiasikan secara eksplisit ("Keep-Alive") yang dijelaskan dalam Bagian 19.7.1 dari [RFC2068]. Beberapa klien dan server mungkin ingin kompatibel dengan pendekatan sebelumnya terhadap koneksi persisten, dengan menegosiasikannya secara eksplisit menggunakan bidang header permintaan "Koneksi: tetap hidup". Namun, beberapa implementasi eksperimental koneksi persisten HTTP/1.0 salah; misalnya, jika server proksi HTTP/1.0 tidak memahami Koneksi, server tersebut akan meneruskan bidang header tersebut secara keliru ke server masuk berikutnya, yang akan mengakibatkan koneksi terhenti. Salah satu solusi yang dicoba adalah pengenalan bidang header Proxy-Connection, yang ditargetkan secara khusus pada proxy. Dalam praktiknya, hal ini juga tidak bisa dilakukan, karena proxy sering kali diterapkan dalam beberapa lapisan, sehingga menimbulkan masalah yang sama seperti yang dibahas di atas. Oleh karena itu, klien dianjurkan untuk tidak mengirimkan bidang header Proxy-Connection dalam permintaan apa pun. Klien juga didorong untuk mempertimbangkan penggunaan "Koneksi: tetap hidup" dalam permintaan dengan hati-hati; Meskipun mereka dapat mengaktifkan koneksi persisten dengan server HTTP/1.0, klien yang menggunakannya perlu memantau koneksi untuk permintaan "hung" (yang menunjukkan bahwa klien harus berhenti mengirimkan bidang header), dan mekanisme ini tidak boleh digunakan oleh klien sama sekali ketika proxy sedang digunakan. C.2.3. Pengenalan Transfer-Encoding HTTP/1.1 memperkenalkan bidang header Transfer-Encoding (Bagian 6.1). Pengkodean transfer perlu didekodekan sebelum meneruskan pesan HTTP melalui protokol yang mendukung MIME. C.3. Perubahan dari RFC 7230 Sebagian besar bagian yang memperkenalkan tujuan desain HTTP, riwayat, arsitektur, kriteria kesesuaian, pembuatan versi protokol, URI, perutean pesan, dan bidang header telah dipindahkan ke [HTTP]. Dokumen ini telah direduksi menjadi hanya sintaks perpesanan dan persyaratan manajemen koneksi khusus untuk HTTP/1.1. Bare CR dilarang di luar konten. (Bagian 2.2) Definisi bentuk otoritas ABNF telah berubah dari komponen otoritas URI yang lebih umum (di mana port bersifat opsional) menjadi format host:port spesifik yang diperlukan oleh CONNECT. (Pasal 3.2.3) Penerima diharuskan menghindari serangan penyelundupan/pemisahan saat memproses framing pesan yang ambigu. (Bagian 6.1) Di ABNF untuk ekstensi terpotong, spasi (buruk) di sekitar ";" dan "=" telah diperkenalkan kembali. Spasi kosong telah dihapus di [RFC7230], namun perubahan tersebut ditemukan merusak implementasi yang sudah ada. (Bagian 7.1.1) Semantik bidang trailer kini melampaui spesifikasi pengkodean transfer yang terpotong. Algoritma decoding untuk potongan (Bagian 7.1.3) telah diperbarui untuk mendorong penyimpanan/penerusan kolom trailer secara terpisah dari bagian header, untuk hanya mengizinkan penggabungan ke bagian header jika penerima mengetahui definisi bidang terkait mengizinkan dan menentukan cara menggabungkan, dan sebaliknya membuang bidang cuplikan alih-alih menggabungkan. Bagian trailer sekarang disebut bagian trailer agar lebih konsisten dengan bagian header dan lebih berbeda dengan bagian body. (Bagian 7.1.2) Parameter pengkodean transfer yang disebut "q" tidak diperbolehkan untuk menghindari konflik dengan penggunaan peringkat di bidang header TE. (Bagian 7.3) Ucapan Terima Kasih Lihat Lampiran "Ucapan Terima Kasih" dari [HTTP], yang juga berlaku untuk dokumen ini. Indeks ACDFGHMORTXA bentuk absolut (target permintaan) Bagian 3.2.2 aplikasi/http Jenis Media *_Bagian 10.2_* bentuk asterisk (target permintaan) Bagian 3.2.4 formulir otoritas (target permintaan) Bagian 3.2. 3 C potongan (Format Pengkodean) Bagian 6.1; Bagian 6.3 dipotong (transfer coding) *_Bagian 7.1_* tutup Bagian 9.3; *_Bagian 9.6_* kompres (pengkodean transfer) *_Bagian 7.2_* Bidang header koneksi Bagian 9.6 Bidang header Panjang Konten Bagian 6.2 Bidang header Pengkodean-Transfer-Konten Lampiran B.5 D mengempis (pengkodean transfer) *_Bagian 7.2_* F Bidang Tutup *_Bagian 9.6, Paragraf 4_* Versi MIME *_Lampiran B.1_* Pengkodean Transfer *_Bagian 6.1_* G Tata Bahasa ALPHA *_Bagian 1.2_* CR *_Bagian 1.2_* CRLF *_Bagian 1.2_* CTL *_Bagian 1.2 _* DIGIT *_Bagian 1.2_* DQUOTE *_Bagian 1.2_* HEXDIG *_Bagian 1.2_* HTAB *_Bagian 1.2_* Pesan HTTP *_Bagian 2.1_* Nama HTTP *_Bagian 2.3_* Versi HTTP *_Bagian 2.3_* LF *_Bagian 1.2_* OCTET *_Bagian 1.2_* SP *_Bagian 1.2_* Pengkodean Transfer *_Bagian 6.1_* VCHAR *_Bagian 1.2_* bentuk absolut Bagian 3.2; *_Bagian 3.2.2_* bentuk asterisk Bagian 3.2; *_Bagian 3.2.4_* formulir wewenang Bagian 3.2; *_Bagian 3.2.3_* potongan *_Bagian 7.1_* potongan-data *_Bagian 7.1_* potongan-ext Bagian 7.1; *_Bagian 7.1.1_* nama potongan-ext *_Bagian 7.1.1_* potongan-ext-val *_Bagian 7.1.1_* ukuran potongan *_Bagian 7.1_* badan potongan *_Bagian 7.1_* garis bidang *_Bagian 5_ *; Bagian 7.1.2 nama bidang Bagian 5 nilai bidang Bagian 5 potongan terakhir *_Bagian 7.1_* isi pesan *_Bagian 6_* metode *_Bagian 3.1_* lipatan obs *_Bagian 5.2_* formulir asal Bagian 3.2; *_Bagian 3.2.1_* frase alasan *_Bagian 4_* baris permintaan *_Bagian 3_* target permintaan *_Bagian 3.2_* baris awal *_Bagian 2.1_* kode status *_Bagian 4_* baris status *_Bagian 4_* bagian trailer Bagian 7.1; *_Bagian 7.1.2_* gzip (pengkodean transfer) *_Bagian 7.2_* Bidang Header H Versi MIME *_Lampiran B.1_* Pengkodean Transfer *_Bagian 6.1_* Baris header Bagian header 2.1 Bagian header 2.1 Bagian 2.1 M Tipe Media application/http *_Bagian 10.2_* pesan/http *_Bagian 10.1_* pesan/http Jenis Media *_Bagian 10.1_* metode *_Bagian 3.1_* Bidang header Versi MIME *_Lampiran B.1_* O formulir asal (permintaan -target) Bagian 3.2.1 R target permintaan *_Bagian 3.2_* T bidang header Pengkodean Transfer *_Bagian 6.1_*