Protokol utama untuk halaman di Internet ialah HTTP. Protokol ini digunakan setiap kali anda melawat tapak baharu, apabila teks atau gambar dipaparkan pada tapak, apabila anda mengklik pautan.

Seluruh Internet adalah berdasarkan HTTP, walaupun kebanyakan pengguna tidak tahu betapa popularnya HTTP dalam kehidupan seharian mereka.

HTTP ialah protokol yang digunakan untuk memindahkan hiperteks (HyperText Transfer Protocol).

Interaksi antara penyemak imbas anda dan pelayan dengan maklumat adalah berdasarkan protokol ini. Terima kasih kepada kesederhanaannya, penyemak imbas dan pelayan bersambung dengan cepat. Tetapi kami tidak perlu menyelidiki semua butiran protokol; kami hanya akan menerangkan prinsip asas operasinya.

Terdapat banyak protokol yang boleh anda gunakan di Internet, HTTP hanyalah satu daripada banyak, yang mempunyai tugas dan tujuannya sendiri.

Ia sangat mudah sehingga anda sudah biasa dengan perisian yang diperlukan untuk berfungsi dengan HTTP - penyemak imbas anda.

Tanpa mengira nama penyemak imbas, nama protokol sentiasa ditambah pada bar alamat secara lalai: “http://”. Anda mungkin tidak melihat teks ini jika penyemak imbas menyembunyikannya. Tetapi anda hanya perlu menyalin nama tapak, bersama-sama dengannya di tempat yang betul Protokol HTTP juga akan dimasukkan.

- Apakah maksud awalan “http://” sebelum nama tapak?
- Ini bermakna anda sedang mengakses sumber melalui protokol HTTP.

Mengapakah protokol HTTP dicipta?

Dengan bantuannya, dokumen hiperteks dihantar, atau, lebih mudah, halaman di tapak yang kami perlukan.

Pelanggan (pelayar) menerima halaman web, dan pelayan menghantar halaman. Teknologi ini dipanggil teknologi pelayan-pelanggan.

Terima kasih kepada HTTP, ia telah menjadi mungkin untuk menghantar halaman web di Internet. Tetapi apakah yang terkandung dalam halaman itu sendiri yang dihantar oleh pelayan kepada kami? Kod HTML biasa yang memasuki penyemak imbas, yang hanya boleh mentafsir maklumat yang diterima dengan betul dan menunjukkan kepada anda tapak yang telah siap.

Kembali pada tahun 2006, hampir separuh daripada trafik HTTP Amerika Utara terdiri daripada penstriman audio dan video.

Cara HTTP berfungsi

1. Penyemak imbas menghantar permintaan meminta halaman pelayan yang dikehendaki.
2. Pelayan menerima permintaan dan mula mencari halaman.
3. Penyemak imbas menerima respons daripada pelayan dengan hasil permintaan:
   • Kod halaman yang diminta dan maklumat perkhidmatan - jika halaman ditemui.
   • Kod ralat dan maklumat perkhidmatan sekiranya berlaku kegagalan.

Apabila penyemak imbas membuat permintaan untuk fail, permintaan itu mengandungi khas arahan HTTP. Jika fail yang diminta benar-benar wujud pada pelayan, fail tersebut dihantar. Tetapi halaman penerima perlu memutuskan sama ada untuk menunjukkan fail pada skrin, menyimpannya ke cakera, atau melakukan sesuatu yang lain dengan hasilnya.

Untuk mengenal pasti sumber pada rangkaian, protokol HTTP menggunakan URI global. Perbezaan antara HTTP dan protokol lain ialah ia tidak menyimpan keadaannya. Iaitu, keadaan antara pasangan permintaan-tindak balas tidak disimpan.

HTTP bukan satu-satunya protokol yang digunakan di Internet. Juga digunakan:

• FTP (File Transfer Protocol) ialah protokol pemindahan fail.
• POP (Post Office Protocol) dan SMTP (Simple Mail Transport Protocol) - untuk pemesejan E-mel.
• SHTTP (Secure Hypertext Transfer Protocol) ialah versi HTTP yang disulitkan. Maklumat yang dihantar melalui protokol ini disulitkan. Biasanya, keselamatan adalah penting apabila data sensitif ditukar.

Dan protokol lain yang mempunyai satu sifat yang baik - semuanya berfungsi tanpa disedari oleh anda dan saya.

Mac 1991 - Tim Berners-Lee mencadangkan menggunakan HTTP.

Berners-Leelah yang membangunkan semua perkara pertama yang berkaitan dengan Internet: penyemak imbas, pelayan, hiperpautan, tapak web pertama (info.cern.ch). Anda boleh melihat rupa laman web pertama dengan mengikuti pautan.

Versi HTTP telah bertambah baik dari semasa ke semasa; HTTP 1.1 telah menjadi popular, yang membolehkan anda membiarkan sambungan antara pelayan dan penyemak imbas terbuka untuk masa yang lama, yang menjadikan protokol lebih cekap.

Pada tahun 2015, HTTP/2 muncul, yang menjadi binari, dan cara maklumat dipecahkan kepada serpihan berubah.

Keselamatan HTTP

HTTP sendiri tidak membayangkan penyulitan maklumat. Tetapi terdapat sambungan untuk protokol yang boleh membungkus data protokol SSL atau TLS.

HTTPS (S - Secure) ialah penyelesaian popular yang tidak membenarkan pemintasan maklumat yang dihantar dan melindungi maklumat daripada serangan MITM "man-in-the-middle" atau serangan man-in-the-middle.

MITM pada asasnya ialah telefon yang rosak di mana maklumat sengaja diubah. Baik pelanggan mahupun pelayan tidak mengetahui tentang penggantian itu.

HTTP terdiri daripada apa?

Kami telah banyak menyebut bahawa pelayan dan pelanggan menghantar dan menerima permintaan. Jadi apa yang terkandung dalam permintaan ini? Setiap mesej HTTP terdiri daripada tiga bahagian:

1. Baris permulaan, yang menentukan jenis mesej.
2. Tajuk yang mencirikan badan mesej.
3. Badan mesej, yang sudah mengandungi data yang diperlukan.

Terima kasih kepada ciri HTTP, kami dapat mencipta enjin carian, forum, kedai dalam talian. Perdagangan datang ke Internet, penyedia Internet dan syarikat lain yang aktivitinya berlaku di Internet mula muncul. Dan semua terima kasih kepada protokol HTTP, yang kini anda kenali.

Artikel itu mendedahkan intipati protokol HTTP, dan juga bercakap tentang skema yang berbeza untuk operasinya. Perhatian istimewa memfokuskan pada intipati interaksi antara penyemak imbas dan pelayan.

Intipati cara HTTP berfungsi

Pertama sekali, anda harus memahami proses interaksi antara pelayan dan pelayar pengguna. Untuk memaparkan halaman tapak pada skrin, penyemak imbas menghantar isyarat permintaan kepada pelayan, selepas itu kandungan tapak yang dikodkan datang dari pelayan, yang ditukar kepada paparan biasa tapak. Mempelajari proses ini untuk pembangun web adalah penting kerana dengan memahami intipati proses, anda boleh mempercepatkan prestasi sumber anda.

Pertukaran data antara pelayan dan penyemak imbas berlaku melalui protokol HTTP. Pelayar itu sendiri, dari sudut pengaturcaraan, adalah Pelanggan HTTP, kerana ia menggunakan protokol ini semasa menghantar permintaan dan untuk menerima data respons.

Sekarang mari kita dedahkan intipati konsep protokol HTTP

HTTP (HyperText Transfer Protocol)– proses mengikut mana semua jenis pertukaran maklumat dijalankan di World Wide Web.

Kami, sebagai pembangun web, hanya berminat dalam proses pertukaran dan paparan maklumat.

Protokol disegerakkan

Pertukaran data dijalankan mengikut skema "pelayan-pelanggan". Dalam skim ini, pelanggan ialah peranti yang menghantar permintaan untuk memberikan beberapa maklumat, dan pelayan ialah sistem yang menerima permintaan, memprosesnya dan menghantar respons kembali kepada klien. Proses interaksi itu sendiri boleh dibahagikan kepada dua peringkat: menghantar permintaan HTTP dan menerima respons HTTP.

Permintaan dan respons tidak boleh dihantar serentak; penyegerakan proses mesti dikekalkan. Iaitu, penghantaran respons akan bermula hanya selepas selesai menghantar permintaan; kerja pada prinsip yang berbeza adalah mustahil. Untuk menjadikannya lebih jelas, mari kita lukiskan analogi dengan bas: anda tidak akan dapat menggunakannya sehingga ia tiba di perhentian.

Bagaimanakah permintaan dibuat?

Proses menghantar permintaan ke pelayan boleh dibahagikan kepada beberapa komponen:

1. Pertama sekali, permintaan DNS dibuat, yang mesti menukar alamat tapak daripada format URI kepada IP (bentuk angka alamat URI). Ini ialah format alamat yang digunakan di World Wide Web.
2. Selepas menentukan IP, sambungan diwujudkan antara pelayan dan klien HTTP.
3. Memajukan permintaan.
4. Kelewatan, yang termasuk menghantar maklumat ke pelayan, memprosesnya dan menghantar respons kepada permintaan. Pengaturcara memanggil tempoh masa ini menunggu jawapan.
5. Menerima jawapan kepada permintaan.

Anda boleh menjejaki semua peringkat ini menggunakan panel pembangun web dalam penyemak imbas anda.

Daripada senarai semua peringkat, yang pertama agak panjang. Pada permulaan pembangunan protokol HTTP menggunakan skim pemprosesan data lapuk, yang menyediakan untuk memutuskan sambungan selepas respons kepada permintaan yang diperlukan diterima. Ini sangat melambatkan proses bekerja di ruang Internet. Walau bagaimanapun, selepas penyeragaman baru protokol dikeluarkan HTTP versi 1.1, mod sambungan baharu telah tersedia - terus-hidup, mengikut mana sambungan telah menjadi tidak dapat dipisahkan. Akibatnya, selepas memproses permintaan pertama, anda tidak perlu melalui peringkat pertama lagi, tetapi segera beralih ke yang kedua.

nota itu

Sambungan dikekalkan hanya dalam satu sumber web. Apabila berpindah ke hos lain, sambungan terputus dan peringkat pertama sekali lagi menjadi bahagian penting dalam proses pemprosesan permintaan.

Proses paling lama dalam protokol sedang menunggu jawapan. Dalam kes ini, menaik taraf spesifikasi tidak akan mengurangkan masa pemprosesan. Juga, proses ini tidak terjejas dalam apa-apa cara oleh kuasa peranti yang melaluinya sumber itu dikeluarkan. Komputer memasuki proses hanya pada peringkat akhir, apabila jawapan telah tiba dan perlu diproses.

Bentuk kerja ini mengurangkan peluang tapak kepada sifar dalam persaingan dengan aplikasi desktop. Ini membawa cara pertama untuk mempercepatkan tapak web - anda perlu meminimumkan bilangan panggilan ke pelayan yang ditulis dalam kod.

Sambungan HTTP selari

Untuk menyelesaikan masalah kependaman yang lama dan gangguan dalam komunikasi dengan hos, skema komunikasi selari telah dibuat antara pelanggan dan pelayan. Dalam erti kata lain, anda boleh mewujudkan sambungan dengan beberapa hos secara serentak. Pembangun standard HTTP 1.1 Adalah disyorkan untuk menyambung tidak lebih daripada 2 saluran sambungan secara serentak. Tetapi perlu diingat bahawa spesifikasi itu bermula pada zaman dinosaur purba. Kini penyemak imbas dengan mudah menyokong komunikasi dengan 4 saluran serentak secara lalai, dan jika anda menggali tetapan klien, angka ini boleh ditingkatkan kepada 8.

Setiap saluran beroperasi mengikut skema sambungan lama, tetapi peningkatan bilangannya telah membawa kepada perubahan ketara dari segi masa pemuatan sumber.

Sambungan HTTP saluran paip

Dengan perkembangan teknologi, proses interaksi antara pelayan dan pelayar mula berkembang dengan ketara. Satu kejayaan penting dalam perkara ini ialah penciptaan skema saluran paip untuk menghantar permintaan ke pelayan (dalam asal - Saluran paip HTTP). Mengikut skim ini, ia menjadi mungkin untuk menghantar beberapa permintaan melalui satu saluran tanpa menunggu jawapan kepada mereka. Sebaliknya, pelayan mula menghantar respons kepada setiap permintaan mengikut keutamaan.

Terima kasih kepada inovasi ini, ia juga mungkin untuk mengurangkan bilangan paket TCP/IP. Oleh itu, anda boleh meletakkan beberapa dalam satu pakej sedemikian Permintaan HTTP. Akibatnya, bukan sahaja operasi protokol akan bertambah baik, tetapi juga kecekapan Internet secara keseluruhan akan meningkat.

Merumuskan

Pada masa ini spesifikasi HTTP 1.1 adalah satu set peraturan yang ketinggalan zaman dari segi moral. Kerja-kerja pemodenannya telah berlangsung sejak sekian lama, contoh yang cemerlang ini adalah HTTP-NG Dan SPDY. Membangunkan HTTP Ia juga boleh dilakukan dengan menambah baik bahasa pengaturcaraan laman web HTML5. Semua proses ini akan mempercepatkan operasi protokol, tetapi peraturan meminimumkan akses kepada pelayan, yang akan meningkatkan kelajuan sumber, akan sentiasa relevan.

Untuk Dunia Wide Web. Protokol tersebut ialah teks berstruktur yang menggunakan sambungan logik(hiperpautan) antara nod yang mengandungi data tertentu. Oleh itu, ia adalah satu cara untuk menukar atau menghantar hiperteks.

Protokol HTTP beroperasi sebagai fungsi tindak balas permintaan dalam model pengkomputeran pelayan pelanggan. Jadi, pelayar web bertindak sebagai pelanggan, dan pengehosan laman web adalah pelayan. Pelanggan menghantar mesej Permintaan HTTP kepada pelayan yang menyediakan sumber-sumber tertentu(seperti fail HTML dan bahan lain) dan kemudian mengembalikan mesej respons. Respons mengandungi maklumat tentang permintaan itu, dan mungkin juga mengandungi kandungan yang diminta dalam kandungan mesej.

Pelayar adalah contoh asas ejen pengguna (pelanggan). Jenis ejen pengguna lain termasuk perisian yang digunakan untuk pengindeksan oleh penyedia carian, aplikasi mudah alih dan sumber lain yang menggunakan atau memaparkan kandungan web.

Protokol HTTP direka bentuk untuk menyediakan elemen rangkaian perantaraan untuk meningkatkan atau membolehkan komunikasi antara pelanggan dan pelayan. Tapak trafik tinggi sering mendapat manfaat daripada pelayan web cache yang menyediakan kandungan bagi pihak sumber huluan, mengurangkan masa muat. Cache pelayar web membolehkan pengguna mengurangkan trafik rangkaian. Pelayan proksi yang menggunakan protokol HTTP dalam rangkaian tempatan, boleh menyediakan sambungan untuk pelanggan yang tidak membenarkan penghalaan alamat global dengan menyampaikan mesej daripada pelayan luaran.

Sesi HTTP ialah proses permintaan dan respons yang berurutan. Pelanggan memulakan permintaan dengan membuat sambungan TCP ke port tertentu pada pelayan, dan pelayan mendengar pada port tersebut dan menunggu mesej permintaan. Apabila ia diterima, pelayan menghantar mesej respons. Badan mesej ini biasanya mewakili sumber yang diminta, walaupun mesej ralat atau maklumat lain mungkin dipaparkan.

Apabila mempertimbangkan tujuan protokol HTTP, perlu diperhatikan bahawa ia mentakrifkan kaedah untuk tujuan menentukan tindakan yang diperlukan, dilakukan menggunakan sumber yang dikenal pasti. Dalam kes ini, jenis maklumat yang dipaparkan (data sedia ada atau dijana secara dinamik) bergantung pada pelaksanaan pelayan. Selalunya sumber sedemikian sepadan dengan fail atau skrip yang terdapat pada pengehosan.

Sesetengah kaedah yang digunakan oleh Protokol Pemindahan Hiperteks HTTP hanya bertujuan untuk mendapatkan semula maklumat dan tidak seharusnya mengubah keadaan pelayan. Dalam erti kata lain, mereka tidak mempunyai kesan yang serius, kecuali untuk kesan yang agak tidak berbahaya daripada caching atau peningkatan statistik pelawat.

Sebaliknya, protokol HTTP juga boleh menggunakan kaedah yang bertujuan untuk tindakan yang boleh menjejaskan sama ada pelayan atau lain-lain sumber luar- aktifkan transaksi kewangan atau lakukan pemindahan e-mel. Kadangkala, kaedah sedemikian digunakan oleh robot web atau beberapa tapak dan boleh membuat permintaan tanpa mengira tugas utama.

22.04.05 13625

Tujuan protokol

Protokol Pemindahan HyperText (HTTP)- ini adalah protokol tahap tinggi(iaitu, lapisan aplikasi), menyediakan kelajuan pemindahan data yang diperlukan yang diperlukan untuk sistem maklumat hipermedia teragih. HTTP digunakan oleh projek Seluruh Dunia Web sejak 1990.

Praktikal Sistem maklumat memerlukan lebih daripada carian data primitif, pengubahsuaian dan anotasi. HTTP/1.0 menyediakan set kaedah terbuka yang boleh digunakan untuk menentukan tujuan permintaan. Ia dibina berdasarkan disiplin rujukan, di mana Pengecam Sumber Sejagat (URI), dalam bentuk lokasi (URL) atau nama (URN), digunakan untuk menunjukkan sumber yang mana kaedah tertentu harus digunakan. Format mesej adalah serupa dengan Internet Mail atau Multipurpose Internet Mail Extensions (MIME).

HTTP/1.0 juga digunakan untuk komunikasi antara penonton pengguna yang berbeza dan get laluan yang memberikan akses hipermedia kepada sedia ada protokol Internet seperti SMTP, NNTP, FTP, Gopher dan WAIS. HTTP/1.0 direka bentuk untuk membenarkan get laluan sedemikian pelayan proksi, tanpa sebarang kehilangan, hantar data menggunakan protokol versi terdahulu yang disebutkan.

Struktur Umum

HTTP adalah berdasarkan paradigma permintaan/tindak balas. Program yang meminta (biasanya dipanggil klien) mewujudkan sambungan dengan program perkhidmatan penerima (biasanya dipanggil pelayan) dan menghantar permintaan kepada pelayan dalam bentuk berikut: kaedah permintaan, URI, versi protokol, diikuti dengan mesej seperti MIME mengandungi maklumat kawalan permintaan, maklumat tentang klien dan mungkin badan mesej. Pelayan bertindak balas dengan mesej yang mengandungi rentetan status (termasuk versi protokol dan kod status kejayaan atau ralat), diikuti dengan mesej seperti MIME yang merangkumi maklumat tentang pelayan, metamaklumat tentang kandungan respons dan mungkin respons badan sendiri. Perlu diingatkan bahawa satu program boleh menjadi pelanggan dan pelayan pada masa yang sama. Penggunaan istilah ini dalam teks ini hanya merujuk kepada peranan yang dilakukan oleh program semasa sesi komunikasi tertentu itu, dan bukan kepada fungsi umum program.

Di Internet, komunikasi biasanya berdasarkan protokol TCP/IP. Untuk WWW, nombor port lalai ialah TCP 80, tetapi nombor port lain juga boleh digunakan - ini tidak mengecualikan kemungkinan menggunakan HTTP sebagai protokol peringkat teratas.

Untuk kebanyakan aplikasi, satu sesi dibuka oleh klien untuk setiap permintaan dan ditutup oleh pelayan sebaik sahaja respons kepada permintaan telah selesai. Walau bagaimanapun, ini bukan ciri protokol. Kedua-dua pelanggan dan pelayan mesti dapat menutup sesi komunikasi, sebagai contoh, akibat daripada beberapa tindakan pengguna. Walau apa pun, pemutusan sambungan yang dimulakan oleh mana-mana pihak menamatkan permintaan semasa, tanpa mengira statusnya.

Konsep umum

Permintaan ialah mesej yang dihantar oleh klien kepada pelayan.
Baris pertama mesej ini termasuk kaedah untuk digunakan pada sumber yang diminta, pengecam sumber dan versi protokol untuk digunakan. Untuk keserasian dengan protokol HTTP/0.9, terdapat dua format permintaan HTTP:

Pertanyaan = Pertanyaan Mudah | Permintaan Penuh Permintaan Mudah = "DAPATKAN" SP Diminta-URI CRLF Permintaan Penuh = Status-Baris *(Pengepala-Umum | Pengepala-Permintaan | Pengepala-Kandungan) CRLF [ Permintaan-Kandungan ]

Jika pelayan HTTP/1.0 menerima Simple-Request, ia mesti bertindak balas dengan HTTP/0.9 Simple-Response. Pelanggan HTTP/1.0 yang mampu memproses Respons Penuh tidak boleh menghantar Permintaan Mudah.

Status Talian

Baris Status bermula dengan baris dengan nama kaedah, diikuti dengan URI Permintaan dan versi protokol yang digunakan. Baris Status berakhir dengan aksara CRLF. Elemen garis dipisahkan oleh ruang (SP). Aksara LF dan CR tidak dibenarkan dalam Baris Status, kecuali urutan CRLF penutup.

String-Status = Kaedah SP Minta URI SP Versi-HTTP CRLF

Perlu diingatkan bahawa perbezaan antara Talian Status Permintaan Penuh dan Talian Status Permintaan Mudah terdiri daripada kehadiran medan Versi HTTP.

Kaedah

Medan Kaedah menentukan kaedah yang harus digunakan pada sumber yang dikenal pasti oleh URI Permintaan. Nama kaedah adalah sensitif huruf besar-besaran. Senarai kaedah sedia ada boleh dikembangkan.

Kaedah = "DAPAT" | "KEPALA" | "LETAK" | "POST" | "PADAM" | "LINK" | "NYAHPAUT" | kaedah tambahan

Senarai kaedah yang dibenarkan oleh sumber tertentu boleh dinyatakan dalam medan Tajuk-Kandungan "Mata". Walau bagaimanapun, pelanggan sentiasa dimaklumkan oleh pelayan melalui kod status respons sama ada aplikasi itu dibenarkan kaedah ini untuk sumber yang ditentukan, kerana kebolehterimaan kaedah yang berbeza mungkin berubah secara dinamik. Jika kaedah tertentu diketahui oleh pelayan, tetapi tidak dibenarkan untuk sumber yang ditentukan, pelayan MESTI memulangkan kod status "Kaedah 405 Tidak Dibenarkan", dan kod status "501 Tidak Dilaksanakan" jika kaedah itu tidak diketahui atau tidak disokong oleh pelayan yang diberikan. Kaedah HTTP/1.0 biasa diterangkan di bawah.

DAPATKAN

Kaedah GET digunakan untuk mendapatkan semula sebarang maklumat yang dikenal pasti oleh URI Permintaan. Jika URI Permintaan merujuk kepada proses yang menghasilkan data, respons akan menjadi data yang dijana oleh proses itu, bukan kod proses itu sendiri (melainkan ia adalah output proses).

Kaedah GET ditukar kepada "GET bersyarat" jika mesej permintaan termasuk medan pengepala "Jika-Diubahsuai-Sejak". Sebagai tindak balas kepada GET bersyarat, badan sumber yang diminta dihantar hanya jika ia telah diubah suai sejak tarikh yang dinyatakan dalam pengepala "Jika-Diubah-Sejak". Algoritma untuk menentukan ini termasuk kes berikut:

• Jika kod status respons permintaan adalah selain daripada "200 OK", atau tarikh yang dinyatakan dalam medan pengepala "Jika-Diubahsuai-Sejak" tidak betul, respons akan sama dengan respons biasa DAPATKAN permintaan.
• Jika sumber telah berubah sejak tarikh yang ditentukan, respons juga akan sama dengan respons kepada permintaan GET biasa.
• Jika sumber tidak diubah suai sejak tarikh yang ditentukan, pelayan akan mengembalikan kod status "304 Not Modified".

Menggunakan kaedah GET bersyarat bertujuan untuk memunggah rangkaian, kerana ia membolehkan anda mengelakkan penghantaran maklumat berlebihan melalui rangkaian.

KEPALA

Kaedah HEAD adalah serupa dengan kaedah GET, kecuali kecuali itu bahawa pelayan tidak mengembalikan Badan Respons dalam respons. Maklumat meta yang terkandung dalam pengepala HTTP bagi respons kepada permintaan HEAD mestilah sama dengan maklumat yang terkandung dalam pengepala HTTP bagi respons kepada permintaan GET. Kaedah ini boleh digunakan untuk mendapatkan maklumat meta tentang sumber tanpa menghantar sumber itu sendiri melalui rangkaian. Kaedah "KEPALA Bersyarat", serupa dengan GET bersyarat, tidak ditentukan.

POS

Kaedah POST digunakan untuk meminta pelayan menerima maklumat yang disertakan dalam permintaan sebagai bawahan kepada sumber yang dinyatakan dalam Talian Status dalam medan URI Permintaan. Kaedah POST direka untuk membenarkan satu kaedah biasa digunakan untuk fungsi berikut:

• Abstrak sumber sedia ada
• Menambahkan mesej pada kumpulan berita, senarai mel atau kumpulan artikel yang serupa
• Penghantaran blok data untuk memproses data pemprosesan
• Memperluas pangkalan data melalui operasi tambah

Fungsi sebenar yang dilakukan oleh kaedah POST ditentukan oleh pelayan dan biasanya bergantung pada URI Permintaan. Maklumat yang ditambah dianggap sebagai subordinat URI yang ditentukan dalam erti kata yang sama bahawa fail adalah bawahan kepada direktori di mana ia berada, artikel baharu adalah bawahan kepada kumpulan berita yang mana ia ditambah, entri adalah bawahan kepada pangkalan data.

Pelanggan boleh mencadangkan URI untuk mengenal pasti sumber baharu dengan memasukkan pengepala "URI" dalam permintaan. Walau bagaimanapun, pelayan harus menganggap URI ini sebagai pembayang sahaja dan boleh menyimpan badan permintaan di bawah URI yang berbeza atau tiada URI langsung.

Jika, akibat pemprosesan permintaan POST, a sumber baharu, respons mesti mempunyai kod status "201 Created" dan mengandungi URI sumber baharu.

LETAK

Kaedah PUT meminta pelayan untuk menyimpan Badan Permintaan di bawah URI yang sama dengan URI Permintaan. Jika URI Permintaan merujuk kepada sumber yang sedia ada, Badan Permintaan harus dianggap sebagai versi diubah suai daripada sumber ini. Jika sumber yang dirujuk oleh URI Permintaan tidak wujud dan URI yang diberikan boleh dianggap sebagai perihalan untuk sumber baharu, pelayan boleh mencipta sumber dengan URI yang diberikan. Jika sumber baharu telah dibuat, pelayan mesti memaklumkan klien yang meminta melalui respons dengan kod status "201 Created". Jika sumber sedia ada telah diubah suai, respons "200 OK" mesti dihantar untuk memaklumkan pelanggan bahawa operasi berjaya diselesaikan. Jika sumber dengan URI yang ditentukan tidak boleh dibuat atau diubah suai, mesej ralat yang sesuai mesti dihantar.

Perbezaan asas antara kaedah POST dan PUT ialah maksud berbeza medan URI Permintaan. Untuk kaedah POST diberi URI menentukan sumber yang akan memanipulasi maklumat yang terkandung dalam badan permintaan sebagai lampiran. Sumber itu boleh menjadi proses pemprosesan data, pintu masuk kepada beberapa protokol lain atau sumber berasingan yang membenarkan anotasi. Sebaliknya, URI untuk permintaan PUT mengenal pasti maklumat yang terkandung dalam Kandungan Permintaan. Pengguna permintaan PUT mengetahui dengan tepat apa URI yang ingin digunakan dan penerima permintaan itu tidak seharusnya cuba menggunakan permintaan itu kepada beberapa sumber lain.

PADAM

Kaedah DELETE digunakan untuk memadam sumber yang dikenal pasti oleh URI Permintaan. Keputusan kaedah ini pada pelayan boleh diubah melalui campur tangan manusia (atau beberapa cara lain). Pada dasarnya, pelanggan tidak boleh pasti bahawa operasi pemadaman telah selesai, walaupun kod status ditukar pelayan ini om, memaklumkan tentang kejayaan menyelesaikan tindakan itu. Walau bagaimanapun, pelayan tidak seharusnya melaporkan kejayaan sehingga ia hampir dipadamkan pada masa respons sumber ini atau pindahkan ke kawasan yang tidak boleh dicapai.

PAUTAN

Kaedah LINK mewujudkan perhubungan antara sumber sedia ada yang dinyatakan dalam URI Permintaan dan sumber sedia ada lain. Perbezaan antara kaedah LINK dan kaedah lain yang membenarkan mewujudkan pautan antara dokumen ialah kaedah LINK tidak membenarkan menghantar Badan Permintaan dalam permintaan, dan akibat daripada kaedah ini, sumber baharu tidak dicipta.

NYAHPAUT

Kaedah UNLINK mengalih keluar satu atau lebih hubungan pautan untuk sumber yang dinyatakan dalam URI Permintaan. Perhubungan ini boleh diwujudkan menggunakan kaedah LINK atau beberapa kaedah lain yang menyokong pengepala "Pautan". Mengalih keluar pautan ke sumber tidak bermakna sumber itu tidak lagi wujud atau menjadi tidak tersedia untuk rujukan masa hadapan.

Medan Pengepala Permintaan

Medan Permintaan-Pengepala membenarkan klien menghantar ke pelayan Maklumat tambahan tentang permintaan dan tentang pelanggan itu sendiri.

Request-Header = Terima | Terima-Charset | Terima-Pengekodan | Terima-Bahasa | Keizinan | Daripada | Jika-Diubahsuai-Sejak | Pragma | Perujuk | Ejen Pengguna | pengepala sambungan

Selain itu, pengepala tambahan boleh ditakrifkan melalui mekanisme sambungan; aplikasi yang tidak mengenalinya mesti menganggap pengepala ini sebagai Kandungan Pengepala.

Beberapa medan pengepala permintaan akan dibincangkan di bawah.

daripada

Jika medan Daripada hadir, ia mesti mengandungi alamat E-mel penuh pengguna yang mengawal program ejen yang membuat permintaan. Alamat ini mesti dinyatakan dalam format yang ditakrifkan dalam RFC 822. Format bidang ini seterusnya: Daripada = "Dari" ":" spesifikasi alamat. Sebagai contoh:

Daripada: [e-mel dilindungi]

Medan ini boleh digunakan untuk fungsi log masuk, serta untuk mengenal pasti sumber permintaan yang salah atau tidak diingini. Ia tidak boleh digunakan sebagai bentuk kawalan akses yang tidak dikelaskan. Tafsiran medan ini ialah permintaan yang sedang diproses dibuat bagi pihak pengguna yang diberi yang bertanggungjawab terhadap kaedah yang digunakan. Khususnya, ejen robot harus menggunakan pengepala ini supaya orang yang bertanggungjawab terhadap robot boleh dihubungi jika masalah timbul. Alamat mel Internet yang ditunjukkan dalam medan ini tidak perlu sepadan dengan alamat hos dari mana permintaan ini dihantar. Jika boleh, alamatnya adalah Internet yang boleh diakses alamat tanpa mengira sama ada ia sebenarnya alamat Internet Alamat emel atau E-mel Internet yang mewakili alamat sistem mel lain.

Nota: Pelanggan tidak boleh menggunakan medan pengepala Daripada tanpa kebenaran pengguna, kerana ini mungkin bercanggah dengan kepentingan peribadinya atau dengan sistem keselamatan setempatnya. Adalah amat disyorkan bahawa pengguna diberi pilihan untuk melumpuhkan, mendayakan atau mengubah suai medan ini pada bila-bila masa sebelum membuat permintaan.

Jika-Diubahsuai-Sejak

Medan pengepala If-Modified-Since digunakan dengan kaedah GET untuk menjadikannya bersyarat: jika sumber yang diminta tidak berubah dalam masa yang dinyatakan dalam medan ini, salinan sumber itu tidak akan dikembalikan oleh pelayan; sebaliknya, respons "304 Not Modified" tanpa Badan Respons akan dikembalikan.

If-Modified-Since = "If-Modified-Sejak" ":" tarikh HTTP

Contoh penggunaan tajuk:

Tujuan ciri ini adalah untuk membolehkan pengemaskinian maklumat cache setempat yang cekap dengan sekurang-kurangnya maklumat yang dihantar. Keputusan yang sama boleh dicapai menggunakan kaedah HEAD diikuti dengan menggunakan GET jika pelayan telah menunjukkan bahawa kandungan dokumen telah berubah.

Ejen Pengguna

Medan pengepala Ejen Pengguna mengandungi maklumat tentang ejen pengguna yang menghantar permintaan. Medan ini digunakan untuk statistik, penjejakan ralat protokol dan pengecaman automatik ejen pengguna. Walaupun tidak diperlukan, ejen pengguna hendaklah sentiasa memasukkan medan ini dalam permintaan mereka. Medan mungkin mengandungi berbilang baris yang mewakili nama produk perisian, garis miring ke hadapan pilihan yang menunjukkan versi produk dan lain-lain produk perisian, yang membentuk bahagian penting ejen pengguna. Mengikut konvensyen, produk disenaraikan dalam tertib menurun tentang kepentingannya kepada pengenalpastian aplikasi.

Ejen Pengguna = "Ejen Pengguna" ":" 1*(produk) produk = rentetan ["/" versi produk] versi produk = rentetan

Ejen Pengguna: CERN-LineMode/2.15 libwww/2.17b3

Baris yang menerangkan nama produk hendaklah pendek dan tepat - menggunakan tajuk ini untuk mengiklankan sebarang maklumat lain yang tidak berkaitan adalah tidak dibenarkan dan akan dianggap tidak konsisten dengan protokol. Walaupun sebarang rentetan boleh hadir dalam medan versi produk, baris yang diberi hanya boleh digunakan untuk menunjukkan versi produk. Medan Ejen Pengguna mungkin termasuk maklumat tambahan dalam ulasan yang bukan sebahagian daripada nilainya.

Struktur tindak balas

Selepas menerima dan mentafsir permintaan, pelayan menghantar respons mengikut borang berikut:

Jawapan = Simple-Jawapan | Respons Penuh Respons Mudah = [ Kandungan Respons ] Respons Penuh = Status Baris *(Pengepala Biasa | Pengepala Respons | Pengepala Kandungan) CRLF [ Kandungan Respons ]

Respons Ringkas hanya perlu dihantar sebagai respons kepada Permintaan Mudah HTTP/0.9, atau jika pelayan hanya menyokong protokol HTTP/0.9 terhad. Jika pelanggan menghantar Permintaan Penuh HTTP/1.0 dan menerima respons yang tidak bermula dengan Talian Status, ia mesti menganggap bahawa respons pelayan ialah Respons Mudah dan memprosesnya dengan sewajarnya. Perlu diingatkan bahawa Simple-Response hanya terdiri daripada maklumat yang diminta (tiada pengepala) dan aliran data berhenti sebaik pelayan menutup sesi komunikasi.

Status Talian

Baris pertama Permintaan Penuh ialah Talian Status yang terdiri daripada versi protokol, diikuti dengan kod status berangka dan ayat teks yang berkaitan. Semua elemen Line-Status dipisahkan oleh ruang. Aksara CR dan LF tidak dibenarkan, kecuali urutan CRLF mengekori.

Line-Status=Versi-HTTP SP Status-Kod SP Frasa-Penjelasan.

Memandangkan Talian Status sentiasa bermula dengan versi protokol "HTTP/" 1*DIGIT "." 1*DIGIT (cth HTTP/1.0), kewujudan ungkapan ini dianggap asas untuk menentukan sama ada respons itu ialah Respons-Mudah atau Respons Penuh. Walaupun format Respons Mudah tidak menghalang rentetan sedemikian daripada muncul (yang akan menyebabkan mesej respons disalahtafsirkan sebagai Respons Penuh), kemungkinan kejadian sedemikian hampir kepada sifar.

Kod Status dan penjelasan untuknya

Elemen Kod Status ialah kod keseluruhan 3 digit yang mengenal pasti hasil percubaan untuk mentafsir dan memenuhi permintaan. Frasa Penjelasan yang mengikutinya bertujuan untuk penerangan teks ringkas Kod Status. Kod Status bertujuan untuk digunakan oleh mesin, manakala Frasa Penjelasan bertujuan untuk seseorang. Pelanggan tidak perlu memeriksa dan memaparkan Frasa Penerangan.

Digit pertama Kod Status bertujuan untuk menentukan kelas respons. Dua digit terakhir tidak memainkan sebarang peranan pengkategorian. Terdapat 5 makna bagi digit pertama:

1. 1xx: Bermaklumat - Tidak digunakan, tetapi dikhaskan untuk kegunaan masa hadapan
2. 2xx: Kejayaan - Permintaan telah diterima sepenuhnya, difahami dan diterima untuk diproses.
3. 3xx: Ubah hala - Pelanggan harus mengambil tindakan selanjutnya untuk berjaya menyelesaikan permintaan. Perlu tindakan tambahan kadangkala boleh dilaksanakan oleh klien tanpa interaksi pengguna, tetapi sangat disyorkan bahawa ini hanya berlaku dalam kes di mana kaedah yang digunakan dalam permintaan adalah acuh tak acuh (GET atau HEAD).
4. 4xx: Ralat Pelanggan - Permintaan yang mengandungi sintaks tidak sah tidak dapat diselesaikan dengan jayanya. Kelas 4xx bertujuan untuk menerangkan kes di mana ralat telah dibuat pada pihak pelanggan. Jika pelanggan masih belum menyelesaikan permintaan apabila ia menerima respons dengan Kod Status - 4xx, ia mesti segera berhenti menghantar data ke pelayan. Jenis Kod Status ini boleh digunakan untuk sebarang kaedah yang digunakan dalam permintaan.
5. 5xx: Ralat Pelayan - Pelayan tidak dapat memberikan respons kepada permintaan yang diserahkan dengan betul. Dalam kes ini
   pelayan sama ada tahu ia membuat ralat atau tidak dapat memproses permintaan. Kecuali respons kepada permintaan HEAD, pelayan menghantar penerangan tentang situasi ralat dan sama ada keadaan itu bersifat sementara atau kekal dalam Kandungan Respons. Jenis Kod Status ini boleh digunakan untuk sebarang kaedah yang digunakan dalam permintaan.

Makna individu Kod Status dan Frasa Penjelasan yang sepadan diberikan di bawah. Frasa Penjelasan ini hanya disyorkan - ia boleh digantikan dengan mana-mana frasa lain yang mengekalkan maknanya dan dibenarkan oleh protokol.

Status-Kod = "200" ; OK | "201" ; Dicipta | "202" ; Diterima | "203" ; Maklumat Sementara | "204" ; Tiada Kandungan | "300" ; Pelbagai Pilihan | "301" ; Dipindahkan Secara Kekal | "302" ; Dipindahkan Buat Sementara | "303" ; Kaedah | "304" ; Tidak Diubah Suai | "400" ; Permintaan Buruk | "401" ; Tanpa kebenaran | "402" ; Pembayaran Diperlukan | "403" ; Dilarang | "404" ; Tidak Ditemui | "405" ; Kaedah Tidak Dibenarkan | "406" ; Tiada Yang Boleh Diterima | "407" ; Pengesahan Proksi Diperlukan | "408" ; Minta Tamat Masa | "409" ; Konflik | "410" ; Pergi | "500" ; Pelayan Dalaman Ralat | "501" ; Tidak Dilaksanakan | "502" ; Gerbang Buruk | "503" ; Perkhidmatan Tidak Tersedia | "504" ; Tamat Masa Gateway | Kod Sambungan Kod Sambungan = 3DIGIT Frasa-Penjelasan = rentetan *(rentetan SP)

daripada aplikasi HTTP Memahami semua Kod Status tidak diperlukan, walaupun pemahaman sedemikian jelas wajar. Walau bagaimanapun, aplikasi dikehendaki dapat mengenali kelas Kod Status (dikenal pasti oleh digit pertama) dan merawat semua Kod Status status respons seolah-olah ia bersamaan dengan Kod Status x00.

Medan Tajuk-Respons

Medan pengepala respons membenarkan pelayan menghantar maklumat tambahan tentang respons yang tidak boleh disertakan dalam Talian Status. Medan pengepala ini tidak bertujuan untuk menyampaikan maklumat tentang kandungan respons yang dihantar sebagai tindak balas kepada permintaan, tetapi ia mungkin mengandungi maklumat tentang pelayan itu sendiri.

Response-Header= Awam | Cuba Semula-Selepas | Pelayan | WWW-Sahkan | pengepala sambungan

Walaupun medan tambahan pengepala respons boleh dilaksanakan melalui mekanisme sambungan, aplikasi yang tidak mengenali medan ini mesti menganggapnya sebagai medan Pengepala-Kandungan. Penerangan penuh medan ini boleh didapati dalam spesifikasi protokol HTTP CERN.

Konsep Umum

Permintaan Penuh dan Respons Penuh boleh digunakan untuk menyampaikan beberapa maklumat dalam permintaan dan respons yang berasingan. Maklumat ini ialah Kandungan Permintaan atau Kandungan Respons, masing-masing dan Pengepala Kandungan.

Medan Tajuk-Kandungan

Medan Kandungan Pengepala mengandungi maklumat meta pilihan masing-masing mengenai Kandungan Permintaan atau Kandungan Respons. Jika kandungan mesej yang sepadan (permintaan atau respons) tidak ada, maka Content-Header mengandungi maklumat tentang sumber yang diminta.

Beberapa medan pengepala kandungan diterangkan di bawah.

benarkan

Medan Benarkan pengepala ialah senarai kaedah yang sumber yang dikenal pasti oleh URI Permintaan menyokong. Tujuan medan ini adalah untuk memberitahu penerima dengan tepat kaedah sah yang dikaitkan dengan sumber; medan ini mesti ada dalam jawapan dengan kod status "Kaedah 405 Tidak Dibenarkan".

Allow = "Allow" ":" 1#method

Contoh penggunaan:

Benarkan: DAPATKAN, KEPALA, LETAK

Sudah tentu, pelanggan boleh mencuba kaedah lain. Walau bagaimanapun, adalah disyorkan untuk mengikuti kaedah yang ditunjukkan dalam bidang ini. Medan ini tidak mempunyai nilai lalai; jika dibiarkan tidak ditentukan, set kaedah yang dibenarkan ditentukan oleh pelayan pada masa setiap permintaan.

Panjang Kandungan

Medan Panjang Kandungan menentukan saiz badan mesej yang dihantar oleh pelayan sebagai tindak balas kepada permintaan atau, dalam kes permintaan HEAD, saiz badan mesej yang akan dihantar sebagai tindak balas kepada permintaan GET.

Panjang Kandungan = "Panjang-Kandungan" ":" 1*DIGIT

Sebagai contoh:

Panjang Kandungan: 3495

Walaupun tidak diperlukan, aplikasi amat digalakkan untuk menggunakan medan ini untuk menganalisis saiz mesej yang dihantar, tanpa mengira jenis maklumat yang terkandung di dalamnya. Untuk medan Panjang Kandungan, sebarang nilai integer yang lebih besar daripada sifar adalah sah.

Jenis kandungan

Medan pengepala Jenis Kandungan mengenal pasti jenis maklumat dalam badan mesej yang dihantar kepada pihak penerima atau, dalam kes kaedah HEAD, jenis maklumat (media) yang akan dihantar jika kaedah GET digunakan.

Content-Type = "Content-Type" ":" jenis persekitaran

Jenis media ditakrifkan secara berasingan.
Contoh:

Jenis Kandungan: teks/html; charset=ISO-8859-4

Medan Jenis Kandungan tidak mempunyai nilai lalai.

Terakhir Diubah Suai

Medan pengepala mengandungi tarikh dan masa di mana pihak penghantar percaya sumber itu diubah suai kali terakhir. Semantik medan ini ditakrifkan dalam istilah yang menerangkan cara penerima harus mentafsirnya: jika penerima mempunyai salinan sumber yang lebih lama daripada tarikh yang diluluskan dalam medan Terakhir Diubah suai, maka salinan itu harus dianggap lapuk. .

Last-Modified = "Last-Modified" ":" HTTP date

Contoh penggunaan:

Maksud tepat medan pengepala ini bergantung pada pelaksanaan pihak yang menghantar dan sifat sumber itu sendiri. Untuk fail, ini mungkin merupakan masa pengubahsuaian terakhirnya. Untuk gerbang pangkalan data, ini mungkin masanya kemaskini terakhir data dalam pangkalan data. Walau apa pun, penerima hanya perlu bimbang tentang keputusan—apa yang terdapat dalam medan yang diberikan—dan tidak bimbang tentang cara keputusan itu diperoleh.

Badan mesej

Badan mesej merujuk kepada Kandungan Permintaan atau Kandungan Respons, masing-masing. Badan mesej, jika ada, dihantar dalam permintaan atau respons HTTP/1.0 dalam format dan pengekodan yang ditentukan oleh medan Header-Content.

Message-Body = *OCTET (di mana OCTET ialah sebarang aksara 8-bit)

Badan mesej disertakan dalam permintaan hanya jika kaedah permintaan membayangkan kehadirannya. Untuk spesifikasi HTTP/1.0, kaedah ini adalah POST dan PUT. Secara umum, kehadiran badan mesej ditunjukkan dengan kehadiran medan pengepala kandungan seperti Panjang Kandungan dan/atau Pengekodan Pemindahan Kandungan dalam permintaan yang dihantar.

Untuk mesej respons, kehadiran badan mesej dalam respons bergantung pada kaedah yang digunakan dalam permintaan dan Kod Status. Semua respons kepada permintaan HEAD mestilah tidak mengandungi badan mesej, walaupun kehadiran beberapa medan pengepala mesej mungkin menunjukkan kemungkinan kehadirannya. Sehubungan itu, respons "204 Tiada Kandungan", "304 Tidak Diubah Suai" dan "406 Tiada Boleh Diterima" juga seharusnya tidak termasuk badan mesej.

baik buruk

Protokol Pemindahan Hiperteks HTTP (RFC 1945, 2068) direka untuk memindahkan dokumen hiperteks daripada pelayan kepada klien. protokol HTTP merujuk kepada protokol lapisan aplikasi. Menurut RFC, protokol pengangkutan mesti ada protokol untuknya mewujudkan sambungan, penghantaran data yang boleh dipercayai dan tanpa mengekalkan sempadan antara mesej. Dalam amalan, dalam kebanyakan kes, protokol pengangkutan untuk HTTP adalah protokol TCP, dan pelayan HTTP (Pelayan web) berada dalam keadaan menunggu sambungan dari pihak klien, secara standard pada port TCP 80 dan klien HTTP ( pelayar web) ialah pemula sambungan.

Dalam istilah Web, semua yang boleh diakses oleh pengguna - dokumen, imej, program - dipanggil sumber. Setiap sumber mempunyai alamat unik untuk Web, dipanggil pengecam sumber universal (URI - Pengecam Sumber Universal). Dalam kes yang paling umum, URI kelihatan seperti ini:

protocol://user:password@host:port/path/file?paremeters#fragment

Medan URI individu mempunyai makna berikut:

protokol - protokol aplikasi di mana sumber diakses;

pengguna - pengguna yang bagi pihaknya sumber itu diakses atau pengguna itu sendiri sebagai sumber;

kata laluan - kata laluan pengguna untuk pengesahan apabila mengakses sumber;

hos - alamat IP atau nama pelayan di mana sumber itu berada;

port - nombor port di mana pelayan sedang berjalan, menyediakan akses kepada sumber;

laluan - laluan ke fail yang mengandungi sumber;

fail - fail yang mengandungi sumber;

parameter - parameter untuk pemprosesan oleh program sumber;

serpihan - titik dalam fail bermula dari mana sumber harus dipaparkan.

Interaksi antara klien dan pelayan Web dijalankan dengan bertukar-tukar mesej. Mesej HTTP dibahagikan kepada permintaan klien kepada pelayan dan respons pelayan kepada klien.

Mesej permintaan dan respons mempunyai format yang sama. Kedua-dua jenis mesej kelihatan seperti ini: pertama terdapat baris permulaan, kemudian mungkin satu atau lebih medan pengepala, juga dipanggil hanya pengepala, kemudian baris kosong (iaitu, baris yang terdiri daripada aksara CR dan LF), menunjukkan hujung medan pengepala dan kemudian mungkin badan mesej:

garisan permulaan

medan pengepala 1

medan pengepala 2

medan pengepala N

badan mesej

Format baris awal klien dan pelayan berbeza dan akan dibincangkan di bawah. Terdapat empat jenis tajuk:

pengepala umum, yang boleh hadir dalam kedua-dua permintaan dan respons;

pengepala permintaan, yang hanya boleh hadir dalam permintaan;

pengepala respons, yang hanya boleh hadir dalam respons;

pengepala entiti, yang merujuk kepada badan mesej dan menerangkan kandungannya.

Setiap pengepala terdiri daripada tajuk, aksara bertindih ":" dan nilai. Tajuk yang paling penting ditunjukkan dalam jadual. 1.

Jadual 1
Pengepala protokol HTTP
Tajuk	Tujuan
Tajuk Objek
	Menyenaraikan kaedah yang disokong oleh pelayan
Pengekodan Kandungan	Cara badan mesej dikodkan, contohnya untuk mengurangkan saiz
	Panjang mesej dalam bait
	Jenis kandungan dan mungkin beberapa parameter
	Teg sumber unik pada pelayan yang membolehkan anda membandingkan sumber
	Tarikh dan masa apabila sumber pada pelayan akan berubah dan perlu diambil semula
	Tarikh dan masa kandungan terakhir diubah suai
Tajuk respons
	Bilangan saat selepas permintaan mesti diulang untuk mendapatkan kandungan baharu
	URI sumber untuk mengakses untuk mendapatkan kandungan
	Tarikh dan masa atau bilangan saat selepas itu permintaan mesti diulang untuk mendapatkan respons yang berjaya
	Nama perisian peruntukan pelayan yang menghantar jawapan
Minta pengepala
	Jenis kandungan yang "faham" dan boleh dimainkan oleh pelanggan
	Pengekodan aksara di mana pelanggan boleh menerima kandungan teks
	Cara pelayan boleh mengekod mesej
	Nombor hos dan port dari mana dokumen itu diminta
Jika-Diubahsuai-Sejak Jika-Tidak Diubahsuai-Sejak	Minta pengepala untuk akses sumber bersyarat
	Minta sebahagian daripada dokumen
	Nama perisian pelanggan
Tajuk Umum
	Menunjukkan pelayan untuk menutup atau mengekalkan-hidup sesi
	Tarikh dan masa mesej dijana

Penerangan terperinci tentang pengepala HTTP/1.0 boleh didapati dalam RFC 2068.

Badan mesej mengandungi maklumat sebenar yang dihantar— muatan mesej. Badan mesej ialah urutan oktet (bait). Badan mesej boleh dikodkan, sebagai contoh, untuk mengurangkan jumlah maklumat yang dihantar, dan kaedah pengekodan ditunjukkan dalam pengepala objek Pengekodan Kandungan.

Mesej permintaan daripada klien kepada pelayan terdiri daripada baris permintaan, pengepala (umum, permintaan, objek), dan mungkin badan mesej. Baris permintaan bermula dengan kaedah, diikuti dengan pengecam sumber yang diminta, versi protokol dan aksara akhir baris yang mengekori:

<Метод> <Идентификатор> <Версия HTTP>

Kaedah ini menentukan arahan protokol HTTP untuk digunakan pada sumber yang diminta. Sebagai contoh, kaedah GET menunjukkan bahawa pelanggan ingin mendapatkan semula kandungan sumber. Pengecam mengenal pasti sumber yang diminta. Versi HTTP ditunjukkan oleh baris seperti ini:

HTTP/<версия>.<подверсия>

RFC 2068 memperkenalkan protokol HTTP/1.1.

Mari kita lihat kaedah utama protokol HTTP.

Kaedah OPTIONS meminta maklumat tentang pilihan sambungan (cth, kaedah, jenis dokumen, pengekodan) yang disokong oleh pelayan untuk sumber yang diminta. Kaedah ini membenarkan pelanggan untuk menentukan pilihan dan/atau keperluan yang berkaitan dengan sumber atau keupayaan pelayan tanpa melakukan sebarang tindakan pada sumber atau menyebabkan ia dimuatkan.

Jika respons pelayan bukan mesej ralat, maka pengepala objek mengandungi maklumat yang boleh dianggap sebagai pilihan sambungan. Sebagai contoh, pengepala Benarkan menyenaraikan semua kaedah yang disokong oleh pelayan untuk sumber tertentu.

Jika pengecam sumber yang diminta ialah asterisk (“*”), maka permintaan OPTIONS bertujuan untuk menangani pelayan secara keseluruhan.

Jika ID sumber yang diminta bukan asterisk, maka permintaan OPTIONS digunakan pada pilihan yang tersedia apabila menyambung ke sumber yang ditentukan.

Kaedah GET membolehkan anda mendapatkan sebarang maklumat yang berkaitan dengan sumber yang diminta. Dalam kebanyakan kes, jika ID sumber yang diminta menghala ke dokumen (cth, dokumen HTML, dokumen teks, grafik, video), maka pelayan mengembalikan kandungan dokumen tersebut (kandungan fail). Jika sumber yang diminta ialah aplikasi (program) yang menjana beberapa data semasa operasinya, maka data ini dikembalikan dalam badan mesej respons, dan bukan imej binari bagi fail boleh laku. Ini digunakan, sebagai contoh, semasa membuat aplikasi CGI. Jika pengecam sumber yang diminta menghala ke direktori (direktori, folder), maka, bergantung pada tetapan pelayan, sama ada kandungan direktori (senarai fail) atau kandungan salah satu fail yang terletak dalam direktori ini (biasanya index.html atau Default.htm). Apabila digesa untuk folder, namanya mungkin atau mungkin tidak ditunjukkan dengan "/" di hujungnya. Jika aksara ini tidak terdapat pada penghujung pengecam sumber, pelayan mengeluarkan salah satu respons ubah hala (dengan kod status 301 atau 302).

Satu variasi kaedah GET ialah "GET bersyarat", di mana mesej permintaan termasuk pengepala permintaan If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match atau If-Julat . Kaedah GET bersyarat meminta pemindahan objek hanya jika ia memenuhi syarat yang diterangkan dalam pengepala yang diberikan. Contohnya, jika pengepala If-Modified-Since hadir, kandungan sumber yang diminta akan diambil hanya jika ia tidak berubah sejak titik masa yang ditentukan sebagai nilai pengepala ini. Kaedah GET bersyarat bertujuan untuk mengurangkan beban rangkaian yang tidak perlu, kerana ia mengelakkan muat semula data yang telah disimpan oleh pelanggan.

Terdapat juga "GET separa" di mana mesej permintaan termasuk pengepala permintaan Julat. GET separa meminta supaya hanya sebahagian daripada objek dipindahkan. Kaedah GET separa direka untuk mengurangkan overhed rangkaian yang tidak perlu dengan meminta hanya sebahagian daripada objek apabila bahagian lain telah dimuat turun oleh klien. Nilai pengepala Julat ialah rentetan "bait =" diikuti dengan julat bait untuk diambil semula. Bait dinomborkan bermula dari 0. Bait permulaan dan akhir julat dipisahkan oleh aksara “–”. Kedua-dua bait permulaan dan akhir dalam julat mungkin tiada. Jika anda perlu mendapatkan beberapa julat, ia disenaraikan dipisahkan dengan koma. Jika beberapa julat yang disenaraikan bersilang, pelayan menggabungkannya. Mesej respons untuk permintaan GET separa mesti mengandungi pengepala Julat Kandungan yang menentukan julat yang hendak dilalui. Jika pelayan menghantar berbilang julat tidak bertindih, pengepala Jenis Kandungan mengambil nilai khas "multypart/byteranges". Badan mesej dibahagikan kepada bahagian yang dipisahkan oleh pemisah yang dijana pelayan dan diluluskan sebagai parameter pengepala Jenis Kandungan. setiap satu bahagian berasingan mengandungi sendiri Pengepala Jenis Kandungan dan Julat Kandungan dengan baris kosong sebelum kandungan julat.

Kaedah HEAD adalah sama dengan GET, kecuali pelayan tidak mengembalikan badan mesej dalam respons. Maklumat yang terkandung dalam pengepala HTTP bagi respons kepada permintaan HEAD adalah sama dengan maklumat yang diberikan sebagai tindak balas kepada permintaan GET untuk sumber yang sama. Kaedah ini boleh digunakan untuk mendapatkan maklumat tentang objek permintaan tanpa terus melalui badan objek. Kaedah HEAD boleh digunakan untuk menguji pautan hiperteks.

Kaedah POST digunakan untuk permintaan di mana pelayan beralamat menerima data yang disertakan dalam badan mesej permintaan (objek) dan menghantarnya kepada aplikasi yang ditentukan sebagai sumber yang diminta untuk pemprosesan. POST direka untuk kaedah umum melaksanakan fungsi berikut:

anotasi sumber sedia ada;

menghantar mesej ke sistem papan buletin (BBS), kumpulan berita, senarai mel atau kumpulan artikel yang serupa;

memindahkan blok data, contohnya hasil input dalam bentuk, kepada proses pemprosesan;

pelaksanaan pertanyaan kepada pangkalan data (DB);

Malah, fungsi yang dilakukan oleh kaedah POST ditentukan oleh aplikasi yang ditunjukkan oleh ID sumber yang diminta. Bersama kaedah GET, kaedah POST digunakan semasa membuat aplikasi CGI. Penyemak imbas boleh mengeluarkan permintaan dengan kaedah POST semasa menyerahkan borang. Untuk tujuan ini elemen FORM dokumen HTML yang mengandungi borang mesti mempunyai atribut kaedah dengan nilai POST.

Aplikasi yang dimulakan oleh POST boleh melakukan tindakan pada pelayan dan tidak mengembalikan sebarang kandungan sebagai hasilnya. Bergantung pada sama ada respons termasuk badan mesej yang menerangkan hasil atau tidak, kod status dalam respons boleh sama ada 200 (OK) atau 204 (Tiada Kandungan).

Jika sumber pada pelayan telah dibuat, respons mengandungi kod status 201 (Dibuat) dan termasuk pengepala respons Lokasi.

Badan mesej yang dihantar dalam permintaan PUT disimpan pada pelayan, dan pengecam sumber yang diminta akan menjadi pengecam dokumen yang disimpan. Jika pengecam sumber yang diminta menunjuk kepada sumber yang sedia ada, maka objek yang disertakan dalam badan mesej dianggap sebagai versi diubah suai sumber yang terletak pada pelayan. Jika sumber baharu telah dibuat, pelayan memberitahu ejen pengguna dengan membalas dengan kod status 201 (Dicipta).

Perbezaan antara kaedah POST dan PUT ialah nilai ID yang berbeza bagi sumber yang diminta. URI dalam permintaan POST mengenal pasti sumber yang memproses objek yang disertakan dalam badan mesej. Sumber ini boleh menjadi aplikasi yang menerima data. Sebaliknya, URI dalam PUT permintaan mengenal pasti objek yang disertakan dalam permintaan sebagai badan mesej, iaitu, ejen pengguna memberikan URI yang diberikan kepada sumber yang disertakan.

Kaedah DELETE meminta pelayan untuk memadamkan sumber yang mempunyai ID yang diminta. Permintaan dengan kaedah ini mungkin ditolak oleh pelayan jika pengguna tidak mempunyai hak untuk memadamkan sumber yang diminta.

Kaedah TRACE digunakan untuk mengembalikan permintaan yang dihantar pada tahap protokol HTTP. Penerima permintaan (pelayan Web) menghantar semula mesej yang diterima kepada klien sebagai badan mesej respons dengan kod status 200 (OK). Permintaan TRACE tidak boleh mengandungi badan mesej.

TRACE membolehkan pelanggan melihat apa yang pelayan terima di hujung yang lain dan menggunakan data ini untuk ujian atau diagnostik.

Jika permintaan itu berjaya, respons mengandungi keseluruhan mesej permintaan dalam badan mesej respons, dan pengepala objek Jenis Kandungan ialah "mesej/http".

Maklumat terperinci tentang kaedah protokol HTTP/1.1 boleh didapati dalam RFC 2068.

Selepas menerima dan mentafsir mesej permintaan, pelayan bertindak balas dengan mesej respons HTTP.

Baris pertama respons ialah Talian Status. Ia terdiri daripada versi protokol, kod status berangka, frasa penjelasan, dipisahkan dengan ruang dan aksara hujung baris mengekori:

<Версия HTTP> <Код состояния> <Поясняющая фраза>

Versi protokol mempunyai makna yang sama seperti dalam permintaan.

Elemen Kod Status ialah kod tiga digit (tiga digit) integer untuk hasil pemahaman dan memenuhi permintaan. Frasa Sebab ialah penerangan teks pendek bagi kod status. Kod status bertujuan untuk diproses oleh perisian, dan frasa penjelasan bertujuan untuk pengguna.

Digit pertama kod status menentukan kelas respons. Dua digit terakhir tidak mempunyai peranan khusus dalam pengelasan. Terdapat 5 makna bagi digit pertama:

1xx: Kod maklumat – permintaan diterima, pemprosesan diteruskan.

2xx: Kod yang berjaya– tindakan berjaya diterima, difahami dan diproses.

3xx: Ubah hala kod - tindakan lanjut mesti diambil untuk melengkapkan permintaan.

4xx: Kod ralat pelanggan - permintaan mempunyai ralat sintaks atau tidak dapat diselesaikan.

5xx: Kod Ralat Pelayan - Pelayan tidak dapat menyelesaikan permintaan yang sah.

Frasa penjelasan untuk setiap kod status disenaraikan dalam RFC 2068 dan disyorkan, tetapi boleh digantikan dengan yang setara tanpa sekatan protokol. Sebagai contoh, dalam versi pelayan HTTP bahasa Rusia yang disetempatkan, frasa ini digantikan dengan yang Rusia. Dalam jadual 2 menunjukkan kod tindak balas pelayan HTTP.

jadual 2
Kod respons pelayan HTTP
	Frasa penerang mengikut
1xx: Kod maklumat
		teruskan
2xx: Kod yang berjaya
		Tiada isi kandungan
		Tetapkan Semula Kandungan
	Kandungan Separa	Kandungan separa
3xx: Ubah hala kod
	Bergerak Sementara	Bergerak buat sementara waktu
		Tidak diubah suai
4xx: Kod ralat pelanggan
		Permintaan buruk
		tanpa kebenaran
		Tidak ditemui
	Kaedah Tidak Dibenarkan	Kaedah tidak dibenarkan
	Permintaan tamat masa	Permintaan tamat masa
		Konflik
	Panjang Diperlukan	Panjang diperlukan
	Minta Entiti Terlalu Besar	Objek permintaan terlalu besar

Hujung meja. 2
	Frasa penerang mengikut	Frasa penjelasan yang setara dalam bahasa Rusia
5xx: Kod ralat pelayan
	Dalaman Ralat Pelayan	Ralat Pelayan Dalaman
	Tidak dilaksanakan	Tidak dilaksanakan
	Perkhidmatan Tidak Tersedia	Perkhidmatan tidak tersedia
	Versi HTTP Tidak Disokong	Tidak disokong versi HTTP

Maklumat terperinci tentang kod respons dan pengepala yang mengiringi respons ini boleh didapati dalam RFC 2068.

Baris status diikuti oleh pengepala (umum, respons dan objek) dan mungkin badan mesej.

Salah satu fungsi yang paling penting Pelayan web adalah untuk menyediakan akses kepada sebahagian daripada tempatan sistem fail. Untuk melakukan ini, direktori tertentu ditentukan dalam tetapan pelayan, yang merupakan direktori akar untuk pelayan Web ini. Untuk menerbitkan dokumen, iaitu, untuk membuatnya boleh diakses oleh pengguna, "melawat" pelayan ini (menyambung kepadanya melalui protokol HTTP), anda perlu menyalin dokumen ini ke direktori akar Pelayan web atau salah satu subdirektorinya. Apabila menyambung melalui HTTP, proses dibuat pada pelayan dengan hak pengguna, yang, sebagai peraturan, tidak benar-benar wujud, tetapi dicipta khas untuk melihat sumber pelayan. Dengan mengkonfigurasi hak dan kebenaran pengguna tertentu, anda boleh mengawal akses kepada sumber Web.