Protokol Pemindahan Hiperteks: Perbezaan antara semakan
Kandungan dihapus Kandungan ditambah
k bot mengubah: pt:Hypertext Transfer Protocol |
Tiada ringkasan suntingan |
||
Baris 1:
'''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 [[TCP and UDP port|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 <tt>GET /images/logo.gif HTTP/1.1</tt> yang meminta sumber bernama <tt>/images/logo.gif</tt> dari pelayan
* [[Senarai pengepala HTTP|Pengepala]], seperti <tt>Accept-Language: en</tt>
* 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 [http://www.ietf.org/rfc/rfc1945.txt RFC1945]<ref name="apacheweek_com-http11">{{cite web|title=Apache Week. HTTP/1.1|url=http://www.apacheweek.com/features/http11}} 090502 apacheweek.com</ref>.
==Kaedah permintaan==
[[Image:Http request telnet ubuntu.png|thumb|right|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 Internet|bot]] atau [[Perangkak web|perangkak]] (''crawler'') yang tidak patut menimbangkan kesan sampingan yang boleh diakibatkan oleh sesebuah permintaan. (Lihat [[#Kaedah selamat|kaedah selamat]] di bawah.)
; [[POST (HTTP)|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 [[Protokol penerowongan|terowong TCP/IP]] lutsinar, biasanya untuk memudahkan komunikasi tersulit [[Transport Layer Security|SSL]] (HTTPS) melalui [[Pelayan proksi|proksi]] HTTP yang tidak disulitkan.<ref>{{cite web|url=http://www.kb.cert.org/vuls/id/150227|accessdate=2007-05-10|date=2002-05-17|title=Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections|publisher=US-CERT}}</ref>
Pelayan HTTP diperlukan untuk melaksanakan sekurang-kurangnya kaedah GET dan HEAD,<ref>[http://tools.ietf.org/html/rfc2616#section-5.1.1 HTTP 1.1 Section 5.1.1]</ref> 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 (sains komputer)|kesan sampingan]] yang boleh memudarat seperti [[Log pelayan|mengelog]], ber[[cache]], melayan [[Sepanduk web|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 [[e-dagang|urus niaga kewangan]] atau penghantaran [[e-mel]]. Maka itu, kaedah-kaedah sedemikian biasanya tidak digunakan oleh [[bot Internet|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 [[e-dagang|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==
{{See also|Senarai kod status HTTP}}
Dalam HTTP/1.0 dan selanjutnya, baris pertama sambutan HTTP dipanggil ''baris status'' yang merangkumi ''kod status'' berangka (seperti "[[HTTP 404|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.<ref>[http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1 6.1 Status-Line]</ref>
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==
{{main|Sambungan berterusan HTTP}}
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 [[pelayan tanpa keadaan|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 (web)|borang]]), dan parameter terkod [[URL]] (seperti <code>/index.php?session_id=some_unique_session_code</code>).
==HTTP selamat==
Kini, terdapat dua cara memastikan keselamatan sambungan HTTP, iaitu skim [[Https|HTTPS]] [[Uniform Resource Identifier|URI]] dan pengepala <tt>Upgrade</tt> HTTP 1.1 yang diperkenalkan oleh RFC 2817. Bagaimanapun, hampir-hampir tiadanya sokongan pelayar bagi pengepala <tt>Upgrade</tt>, oleh itu skim HTTPS URI masih lagi kaedah paling dikenali untuk membuat sambungan HTTP yang selamat. HTTP selamat ditatatanda dengan awalan <tt>HTTPS://</tt> dan bukan <tt>HTTP://</tt>.
===Skim HTTPS URI===
{{main|HTTPS}}
<tt>HTTPS:</tt> ialah [[skim URI]] serupa dari segi sintaks dengan skim <tt>http:</tt> yang digunakan untuk sambungan HTTP biasa, tetapi mengisyaratkan pelayan untuk menggunakan lapisan penyulitan [[Lapisan Soket Selamat|SSL]]/[[Sekuriti Lapisan Pengangkutan|TLS]] tambahan untuk melindungi trafik. SSL sesuai khususnya untuk HTTP kerana boleh memberikan perlindungan sekalipun sebelah pihak dalam perhubungan adalah [[Pengesahan|disahkan]]. Demikianlah rupanya bagi urus niaga HTTP melalui Internet, di mana biasanya hanya [[pelayan web|pelayan]] disahkan (oleh klien yang memeriksa [[Sijil kunci awam|sijil]] pelayan).
===Pengepala Upgrade HTTP 1.1===
HTTP 1.1 memperkenalkan sokongan untuk pengepala <tt>Upgrade</tt>. Dalam pertukarannya, klien bermula dengan membuat permintaan "bersihkan teks", yang kemudiannya ditingkatkan menjadi [[Sekuriti Lapisan Pengangkutan|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:
<pre>
GET /encrypted-area HTTP/1.1
Host: www.example.com
</pre>
Pelayan:
<pre>
HTTP/1.1 426 Upgrade Required
Upgrade: TLS/1.0, HTTP/1.1
Connection: Upgrade
</pre>
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==
Baris 24 ⟶ 128:
* [[Pelayan web]]
* [[Jaringan Sejagat]]
==Rujukan==
{{reflist}}
==Pautan luar==
| |||