Protokol Pemindahan Hiperteks

HTTP (singkatan bagi Hypertext Transfer Protocol, bahasa Melayu: Protokol Pemindahan Hiperteks) ialah suatu protokol perisian yang digunakan untuk memindahkan maklumat melalui Jaringan Sejagat dan intranet. HTTP dibangunkan secara bersama oleh Konsortium Jaringan Sejagat (W3C) dan Pasukan Petugas Kejuruteraan Internet (IETF). Versi terkini bagi HTTP ialah HTTP/1.1.

Sesi HTTP

Sesi HTTP ialah sejujukan urus niaga permintaan-sambutan rangkaian. Sebuah klien HTTP memulakan permintaan, dan membuat sambungan Protokol Kawalan Penghantaran (TCP) kepada sesebuah port tertentu pada sesebuah hos (biasanya port 80; lihat Senarai nombor port TCP dan UDP). Sebuah pelayan HTTP yang mendengari port itu menunggu mesej permintaan klien. Setelah menerima permintaan itu, pelayan itu menghantar balik baris status seperti "HTTP/1.1 200 OK", serta mesej tersendiri yang berisi sumber yang diminta, mesej ralat, atau macam-macam lagi maklumat.

Mesej permintaan

Mesej permintaan terdiri daripada yang berikut:

Baris permintaan, seperti GET /images/logo.gif HTTP/1.1 yang meminta sumber bernama /images/logo.gif dari pelayan
Pengepala, seperti Accept-Language: en
Baris kosong
Isi mesej (tidak wajib)

Baris permintaan dan pengepala mesti berakhir dengan <CR><LF> (iaitu kembali pembawa diikuti suap baris). Baris kosong hanya terdiri daripada <CR><LF> tanpa apa-apa ruang putih. Dalam protokol HTTP/1.1, semua pengepala kecuali Host tidak diwajibkan.

Baris permintaan yang mengandungi nama laluan sahaja diterima oleh pelayan untuk memastikan keserasian dengan klien HTTP sebelum spesifikasi HTTP/1.0 dalam RFC1945^[1].

Kaedah permintaan

Permintaan HTTP dengan telnet. Pengepala permintaan dan sambutan dan isi sambutan diserlahkan.

HTTP mentakrifkan lapan cara (atau "verb") yang menandakan tindakan yang hendak dilakukan pada sumber yang dikenal pasti. Apa yang diwakili oleh sumber ini, sama ada data yang sudah sedia ada atau data yang dijana secara dinamik, tertakluk pada pelaksanaan pelayan. Selalunya, sumber berhubung dengan fail atau output boleh laku yang terletak dalam pelayan.

HEAD: Meminta sambutan yang seiras dengan yang akan berhubung dengan permintaan GET, cuma tanpa isi sambutan. Berguna untuk menerima meta-maklumat yang ditulis dalam pengepala sambutan, tanpa perlu mengangkut seluruh kandungan.

GET: Meminta perwakilan sumber yang ditentukan. Perhatian: GET tidak wajar digunakan untuk operasi yang menimbulkan kesan sampingan, seperti menggunakannya untuk membuat tindakan dalam aplikasi web. Salah satu sebabnya adalah GET boleh digunakan sewenang-wenangnya oleh bot atau perangkak (crawler) yang tidak patut menimbangkan kesan sampingan yang boleh diakibatkan oleh sesebuah permintaan. (Lihat kaedah selamat di bawah.)
POST: Menghantar data untuk diproses (cth., dari suatu bentuk HTML) ke sumber yang dikenal pasti. Data disertakan dalam isi permintaan, maka menghasilkan sumber baru atau mengemaskini sumber-sumber sedia ada, atau kedua-duanya sekali.
PUT: Memuat naik perwakilan sumber yang ditentukan.
DELETE: Memadam sumber yang ditentukan.
TRACE: Menggema balik permintaan yang diterima, supaya klien boleh melihat apa yang ditambah atau diubah oleh pelayan perantaraan dalam permintaan.
OPTIONS: Mengembalikan kaedah HTTP yang disokong oleh pelayan untuk URL tertentu. Boleh digunakan untuk memastikan keberkesanan pelayan web dengan meminta '*' dan bukannya sumber yang tertentu.
CONNECT: Menukar sambungan permintaan menjadi terowong TCP/IP lutsinar, biasanya untuk memudahkan komunikasi tersulit SSL (HTTPS) melalui proksi HTTP yang tidak disulitkan.^[2]

Pelayan HTTP diperlukan untuk melaksanakan sekurang-kurangnya kaedah GET dan HEAD,^[3] dan juga kaedah OPTIONS jika boleh.

Kaedah selamat

Sesetengah kaedah (misalnya, HEAD, GET, OPTIONS dan TRACE) ditakrifkan sebagai selamat, iaitu bertujuan untuk penerimaan maklumat sahaja tanpa mengubah keadaan pelayan. Dalam erti kata lain, kaedah-kaedah tesebut tidak patut menimbulkan kesan sampingan yang boleh memudarat seperti mengelog, bercache, melayan iklan sepanduk atau menokok penghitung kenaan. Oleh itu, permintaan GET sewenang-wenang tanpa mempertimbangkan konteks keadaan aplikasi dianggap selamat.

Berbeza pula dengan kaedah-kaedah seperti POST, PUT dan DELETE yang dimaksudkan untuk tindakan yang boleh menyebabkan kesan sampingan dalam pelayan atau luaran seperti urus niaga kewangan atau penghantaran e-mel. Maka itu, kaedah-kaedah sedemikian biasanya tidak digunakan oleh robot web atau perangkak web yang patuh, yang cenderung melakukan permintaan tanpa mempertimbangkan konteks atau akibatnya.

Walaupun permintaan GET ditentukan sebagai selamat, sebenarnya cara pelayan menanganinya adalah tidak terbatas. Oleh itu, sebarang kelalaian dalam pengaturcaraan boleh mudah menyebabkan perubahan yang ketara dalam pelayan. Ini tidak digalakkan kerana akan menimbulkan masalah dalam cache web, enjin carian dan agen-agen berautomat yang lain, yang boleh menyebabkan perubahan yang tidak diingini dalam pelayan.

Kaedah idempoten dan aplikasi web

Kaedah-kaedah PUT dan DELETE ditakrifkan sebagai idempoten, iaitu sebanyak mana permintaan yang seiras haruslah sama kesannya seperti permintaan tunggal. Kaedah-kaedah GET, HEAD, OPTIONS dan TRACE yang selamat pula sepatutnya idempoten juga, kerana HTTP ialah protokol tanpa keadaan.

Kaedah POST berbeza pula iaitu tidak semestinya idempoten, oleh itu penghantaran permintaan POST yang serupa berbanyak kali boleh menjejaskan keadaan atau menimbulkan kesan sampingan (seperti urus niaga kewangan). Sesekali, ini boleh diterima, tetapi begitu juga timbul dari ketaksengajaan, seperti pengguna tidak menyedari tindakannya akan menyebabkan lain pula permintaan yang dihantar, atau tidak menerima maklum balas yang mencukupi bahawa pemintaan pertama mereka berjaya. Wakaupun pelayar web boleh memaparkan kotak dialog amaran untuk mengingatkan pengguna apabila menyegar semula halaman boleh menghantar semula permintaan POST, namun pada kebiasaannya adalah terpulang kepada aplikasi web untuk memastikan permintaan POST tidak wajar dihantar semula lebih daripada sekali.

Perhatian: sama ada kaedah itu idempoten tidak dikuatkuasa oleh protokol atau pelayan web. Sememangnya kita boleh menggubah sebuah aplikasi web yang mana (contohnya) sisipan pangkalan data atau mana-mana tindakan bukan idempoten dipicukan oleh permintaan GET atau lain-lain. Bagaimanapun, jika cadangan ini tidak diendahkan, maka mungkin timbulnya kesan-kesan yang tidak diingini seandainya agen pengguna menganggap bahawa mengulangi permintaan yang sama adalah selamat padahal sebenarnya adalah sebaliknya.

Kod status

Dalam HTTP/1.0 dan selanjutnya, baris pertama sambutan HTTP dipanggil baris status yang merangkumi kod status berangka (seperti "404") dan ungkapan sebab (seperti "Tidak Dijumpai"). Cara agen pengguna menangani sambutan berkenaan banyak bergantung kepada kod dan juga pengepala sambutan. Kod status tersuai boleh digunakan kerana, seandainya menemui kod yang tidak dikenalinya, agen pengguna boleh menggunakan angka pertama kod berkenaan untuk menentukan dari golongan mana sambutan itu.^[4]

Selain itu, ungkapan sebab yang mengikut piawaian adalah sekadar cadangan dan boleh diganti oleh ungkapan lain yang sama ertinya atas budi bicara pihak pembangun web. Jika kod status menandakan masalah, agen pengguna boleh memaparkan ungkapan sebab kepada penguna untuk menyalurkan maklumat lanjut mengenai sifat masalah ini. Piawaian juga membolehkan agen pengguna untuk cuba mentafsirkan ungkapan sebab, namun ini tidak digalakakn kerana piawaian terang-terangan menetapkan bahawa kod status boleh dibaca oleh mesin manakala ungkapan sebab pula adalah untuk bacaan manusia.

Sambungan berterusan

Dalam HTTP/0.9 dan 1.0, sambungan ditutup selepas sepasang permintaan/sambutan tunggal disalurkan. Dalam HTTP/1.1 pula, diperkenalkan mekanisme pengekal yang membolehkan sambungan diguna semula untuk lebih daripada satu permintaan.

Sambungan berterusan sebegini jelas mengurangkan kependaman (lag), kerana klien tidak perlu merundingkan semula sambungan TCP selepas dihantarnya permintaan pertama.

HTTP/1.1 telah menambah baik pengoptimuman lebar jalur pada HTTP/1.0. Contohnya, HTTP/1.1 memperkenalkan pengekodan pindah berketul (chunked transfer encoding) untuk membolehkan kandungan distrimkan melalui sambungan beterusan tanpa perlu ditimbal. Penalian paip HTTP mengurangkan lagi lat masa, membolehkan klien menghantar sebanyak mana permintaan sebelum sambutan terdahulu diterima pada permintaan pertama. Selain itu, terdapat juga layanan bait (byte serving), iaitu apabila pelayan cuma menghantar sebahagian sumber yang terang-terangan diminta oleh klien.

Keadaan sesi HTTP

HTTP ialah protokol tanpa keadaan. Kelebihan protokol tanpa keadaan adalah hos tidak perlu mengekalkan maklumat mengenai pengguna antara permintaan, tetapi ini memaksa pembangun web menggunakan kaedah-kaedah lain untuk mengekalkan keadaan pengguna. Contohnya, apabila hos perlu menyesuaikan kandungan laman web untuk pengguna, aplikasi web mesti digubah untuk memantau kegiatan pengguna dari halaman ke halaman. Salah satu cara penyelesaian masalah ini melibatkan penghantaran dan penerimaan kuki. Kaedah-kaedah lain termasuk sesi pihak pelayan, pemboleh ubah terlindung (apabila melayari halaman berbentuk borang), dan parameter terkod URL (seperti /index.php?session_id=some_unique_session_code).

HTTP selamat

Kini, terdapat dua cara memastikan keselamatan sambungan HTTP, iaitu skim HTTPS URI dan pengepala Upgrade HTTP 1.1 yang diperkenalkan oleh RFC 2817. Bagaimanapun, hampir-hampir tiadanya sokongan pelayar bagi pengepala Upgrade, oleh itu skim HTTPS URI masih lagi kaedah paling dikenali untuk membuat sambungan HTTP yang selamat. HTTP selamat ditatatanda dengan awalan HTTPS:// dan bukan HTTP://.

Skim HTTPS URI

HTTPS: ialah skim URI serupa dari segi sintaks dengan skim http: yang digunakan untuk sambungan HTTP biasa, tetapi mengisyaratkan pelayan untuk menggunakan lapisan penyulitan SSL/TLS tambahan untuk melindungi trafik. SSL sesuai khususnya untuk HTTP kerana boleh memberikan perlindungan sekalipun sebelah pihak dalam perhubungan adalah disahkan. Demikianlah rupanya bagi urus niaga HTTP melalui Internet, di mana biasanya hanya pelayan disahkan (oleh klien yang memeriksa sijil pelayan).

Pengepala Upgrade HTTP 1.1

HTTP 1.1 memperkenalkan sokongan untuk pengepala Upgrade. Dalam pertukarannya, klien bermula dengan membuat permintaan "bersihkan teks", yang kemudiannya ditingkatkan menjadi TLS. Sama ada klien atau pelayan boleh meminta agar sambungan ditingkatkan. Kegunaan utamanya ialah permintaan bersihkan teks oleh klien, diikuti permintaan oleh pelayan agar meningkatkan sambungan, yang berupa begini:

Klien:

GET /encrypted-area HTTP/1.1
Host: www.example.com

Pelayan:

HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade

Pelayan mengembalikan kod status 426 kerana kod-kod 400 menandakan kegagalan klien (lihat Senarai kod status HTTP) yang memaklumkan klien-klien legasi bahawa kegagalan tersebut adalah berkenaan dengan klien.

Manfaat penggunaan kaedah ini untuk membuat sambungan yang selamat adalah bahawa ia:

menghapuskan penghalaan semula dan penulisan semula URL yang tidak teratur dan bermasalah di pihak pelayan,
membolehkan pengehosan maya untuk laman-laman web selamat (tetapu HTTPS juga membolehkannya dengan menggunakan penunjuk nama pelayan)
mengurangkan kekeliruan pengguna dengan memberikan laluan tunggal untuk mencapai sumber tertentu

Namun begitu, kaedah ini ada kelemahannya, iaitu keperluan HTTP yang selamat tidak boleh ditentukan dalam URL. Secara praktis, pelayan (yang tidak dipercayai) akan dipertanggungjawabkan kerana membolehkan HTTP selamat, bukannya klien (yang dipercayai).

Contoh

Berikut ialah contoh pertanyaan dan jawapan yang berlaku dalam HTTP. Pelanggan HTTP seperti pelayar web membuat pertanyaan berikut:

GET /index.html HTTP/1.1
Host: www.example.com

Pelayan HTTP yang menerima pertanyaan tersebut menjawab pula dengan teks permulaan berikut:

HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Server: Apache/1.3.3.7 (Unix)  (Red-Hat/Linux)
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Etag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Content-Length: 438
Connection: close
Content-Type: text/html; charset=UTF-8

Lihat juga

Rujukan

^ "Apache Week. HTTP/1.1". 090502 apacheweek.com
^ "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". US-CERT. 2002-05-17. Dicapai pada 2007-05-10.
^ HTTP 1.1 Section 5.1.1
^ 6.1 Status-Line

Pautan luar

Laman HTTP di tapak web W3C
RFC 2616—Spesifikasi yang menentukan HTTP/1.1
RFC 2617—Spesifikasi yang menentukan pengesahan HTTP

Rencana berkenaan pengkomputeran ini ialah rencana tunas. Anda boleh membantu Wikipedia dengan mengembangkannya.

[apacheweek_com-http11-1] "Apache Week. HTTP/1.1". 090502 apacheweek.com

[2] "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections". US-CERT. 2002-05-17. Dicapai pada 2007-05-10.

[3] HTTP 1.1 Section 5.1.1

[4] 6.1 Status-Line

[1]

[2]

[3]

[4]