Sesi HTTP ialah sejujukan urus niaga permintaan-sambutan rangkaian. Sebuah klien HTTP memulakan permintaan, dan membuat sambunganProtokol Kawalan Penghantaran (TCP) kepada sesebuahport tertentu pada sesebuah hos (biasanya port 80; lihatSenarai 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.
Baris permintaan, sepertiGET /images/logo.gif HTTP/1.1 yang meminta sumber bernama/images/logo.gif dari pelayan
Pengepala, sepertiAccept-Language: en
Baris kosong
Isi mesej (tidak wajib)
Baris permintaan dan pengepala mesti berakhir dengan <CR><LF> (iaitukembali pembawa diikutisuap baris). Baris kosong hanya terdiri daripada <CR><LF> tanpa apa-aparuang 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 dalamRFC1945[1].
Permintaan HTTP dengan telnet. Pengepala permintaan dan sambutan dan isi sambutan diserlahkan.
HTTP mentakrifkan lapan cara (atau "verb") yang menandakan tindakan yang hendak dilakukan padasumber 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 dalamaplikasi web. Salah satu sebabnya adalah GET boleh digunakan sewenang-wenangnya olehbot atauperangkak (crawler) yang tidak patut menimbangkan kesan sampingan yang boleh diakibatkan oleh sesebuah permintaan. (Lihatkaedah selamat di bawah.)
Menghantar data untuk diproses (cth., dari suatubentuk 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 untukURL tertentu. Boleh digunakan untuk memastikan keberkesanan pelayan web dengan meminta '*' dan bukannya sumber yang tertentu.
CONNECT
Menukar sambungan permintaan menjaditerowong TCP/IP lutsinar, biasanya untuk memudahkan komunikasi tersulitSSL (HTTPS) melaluiproksi HTTP yang tidak disulitkan.[2]
Pelayan HTTP diperlukan untuk melaksanakan sekurang-kurangnya kaedah GET dan HEAD,[3] dan juga kaedah OPTIONS jika boleh.
Sesetengah kaedah (misalnya, HEAD, GET, OPTIONS dan TRACE) ditakrifkan sebagaiselamat, iaitu bertujuan untuk penerimaan maklumat sahaja tanpa mengubah keadaan pelayan. Dalam erti kata lain, kaedah-kaedah tesebut tidak patut menimbulkankesan sampingan yang boleh memudarat sepertimengelog, bercache, melayaniklan sepanduk atau menokokpenghitung 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 sepertiurus niaga kewangan atau penghantarane-mel. Maka itu, kaedah-kaedah sedemikian biasanya tidak digunakan olehrobot web atauperangkak web yang patuh, yang cenderung melakukan permintaan tanpa mempertimbangkan konteks atau akibatnya.
Walaupun permintaanGET 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 dalamcache web,enjin carian dan agen-agen berautomat yang lain, yang boleh menyebabkan perubahan yang tidak diingini dalam pelayan.
Kaedah-kaedah PUT dan DELETE ditakrifkan sebagaiidempoten, 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 (sepertiurus 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. Wakaupunpelayar web boleh memaparkankotak 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 seandainyaagen pengguna menganggap bahawa mengulangi permintaan yang sama adalah selamat padahal sebenarnya adalah sebaliknya.
Dalam HTTP/1.0 dan selanjutnya, baris pertama sambutan HTTP dipanggilbaris status yang merangkumikod status berangka (seperti "404") danungkapan sebab (seperti "Tidak Dijumpai"). Caraagen 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 pihakpembangun 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.
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 mengurangkankependaman (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 memperkenalkanpengekodan 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 jugalayanan bait (byte serving), iaitu apabila pelayan cuma menghantar sebahagian sumber yang terang-terangan diminta oleh klien.
HTTP ialah protokoltanpa keadaan. Kelebihan protokol tanpa keadaan adalah hos tidak perlu mengekalkan maklumat mengenai pengguna antara permintaan, tetapi ini memaksapembangun web menggunakan kaedah-kaedah lain untuk mengekalkan keadaan pengguna. Contohnya, apabila hos perlu menyesuaikan kandunganlaman web untuk pengguna,aplikasi web mesti digubah untuk memantau kegiatan pengguna dari halaman ke halaman. Salah satu cara penyelesaian masalah ini melibatkan penghantaran dan penerimaankuki. Kaedah-kaedah lain termasuk sesi pihak pelayan, pemboleh ubah terlindung (apabila melayari halaman berbentukborang), dan parameter terkodURL (seperti/index.php?session_id=some_unique_session_code).
Kini, terdapat dua cara memastikan keselamatan sambungan HTTP, iaitu skimHTTPSURI dan pengepalaUpgrade HTTP 1.1 yang diperkenalkan olehRFC 2817. Bagaimanapun, hampir-hampir tiadanya sokongan pelayar bagi pengepalaUpgrade, oleh itu skim HTTPS URI masih lagi kaedah paling dikenali untuk membuat sambungan HTTP yang selamat. HTTP selamat ditatatanda dengan awalanHTTPS:// dan bukanHTTP://.
HTTPS: ialahskim URI serupa dari segi sintaks dengan skimhttp: yang digunakan untuk sambungan HTTP biasa, tetapi mengisyaratkan pelayan untuk menggunakan lapisan penyulitanSSL/TLS tambahan untuk melindungi trafik. SSL sesuai khususnya untuk HTTP kerana boleh memberikan perlindungan sekalipun sebelah pihak dalam perhubungan adalahdisahkan. Demikianlah rupanya bagi urus niaga HTTP melalui Internet, di mana biasanya hanyapelayan disahkan (oleh klien yang memeriksasijil pelayan).
HTTP 1.1 memperkenalkan sokongan untuk pengepalaUpgrade. Dalam pertukarannya, klien bermula dengan membuat permintaan "bersihkan teks", yang kemudiannya ditingkatkan menjadiTLS. 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:
Pelayan mengembalikan kod status 426 kerana kod-kod 400 menandakan kegagalan klien (lihatSenarai 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,
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).
