Hypertext Transfer Protocol (HTTP) adalah sebuah protokol aplikasi untuk didistribusikan, kolaboratif, sistem informasi hypermedia. HTTP adalah dasar komunikasi data untuk World Wide Web.
Hypertext terstruktur teks yang menggunakan link logis (hyperlink) antara node yang berisi teks. HTTP adalah protokol untuk pertukaran atau hypertext transfer.
Pengembangan standar HTTP dikoordinasi oleh Internet Engineering Task Force (IETF) dan World Wide Web Consortium (W3C), yang berpuncak pada publikasi serangkaian Permintaan untuk Komentar (RFC), terutama RFC 2616 (Juni 1999), yang didefinisikan HTTP / 1.1, versi HTTP yang paling umum digunakan saat ini. Pada bulan Juni 2014, RFC 2616 sudah pensiun dan HTTP / 1.1 didefinisikan kembali oleh RFC 7230, 7231, 7232, 7233, 7234, dan 7235. HTTP / 2 saat ini
tinjauan teknisURL dimulai dengan skema HTTP dan label WWW nama domain.
Fungsi HTTP sebagai protokol request-response dalam model komputasi client-server. Sebuah web browser, misalnya, mungkin klien dan aplikasi yang berjalan pada komputer hosting situs web mungkin server. Klien mengajukan pesan permintaan HTTP ke server. Server, yang menyediakan sumber daya seperti file HTML dan konten lainnya, atau melakukan fungsi lain atas nama klien, mengembalikan pesan respon ke klien. Tanggapan berisi informasi status penyelesaian tentang permintaan dan mungkin juga mengandung konten yang diminta dalam tubuh pesannya.
Sebuah web browser adalah contoh dari agen pengguna (UA). Jenis lain dari agen pengguna termasuk perangkat lunak pengindeksan yang digunakan oleh penyedia layanan pencarian (web crawler), browser suara, aplikasi mobile, dan perangkat lunak lainnya yang mengakses, mengkonsumsi, atau menampilkan konten web.
HTTP dirancang untuk memungkinkan elemen jaringan menengah untuk meningkatkan atau mengaktifkan komunikasi antara klien dan server. Situs lalu lintas tinggi sering mendapat manfaat dari server web cache yang memberikan konten atas nama server hulu untuk meningkatkan waktu respon. Web browser sebelumnya cache diakses sumber web dan menggunakan kembali mereka bila memungkinkan untuk mengurangi lalu lintas jaringan. Server proxy HTTP pada batas jaringan pribadi dapat memfasilitasi komunikasi untuk klien tanpa alamat routable secara global, dengan menyampaikan pesan dengan server eksternal.
HTTP adalah sebuah protokol lapisan aplikasi yang dirancang dalam kerangka Internet Protocol Suite. Definisi menganggap protokol lapisan transport yang mendasari dan dapat diandalkan,
dan Transmission Control Protocol (TCP) yang biasa digunakan. Namun HTTP dapat menggunakan protokol diandalkan seperti User Datagram Protocol (UDP), misalnya dalam Simple Service Discovery Protocol (SSDP).
Sumber daya HTTP diidentifikasi dan terletak di jaringan dengan Uniform Resource Identifier (URI) -atau, lebih khusus, Uniform Locators Sumber Daya (URL) -menggunakan http atau https skema URI. URI dan hyperlink di Hypertext Markup Language (HTML) dokumen membentuk jaring dokumen antar-linked hypertext.
HTTP / 1.1 merupakan revisi dari HTTP asli (HTTP / 1.0). Dalam HTTP / 1.0 koneksi terpisah ke server yang sama dibuat untuk setiap permintaan sumber daya. HTTP / 1.1 bisa menggunakan kembali sambungan beberapa kali untuk men-download gambar, script, stylesheet, dll setelah halaman telah disampaikan. Oleh karena itu HTTP / 1.1 komunikasi mengalami kurang latency sebagai pembentukan koneksi TCP menyajikan overhead yang cukup.
sejarahTim Berners-Lee
The hypertext Istilah ini diciptakan oleh Ted Nelson pada tahun 1965 di Xanadu Project, yang pada gilirannya terinspirasi oleh visi Vannevar Bush (1930-an) dari pengambilan informasi berbasis mikrofilm dan manajemen "memex" sistem dijelaskan dalam esainya As We May Think (1945 ). Tim Berners-Lee dan timnya dihargai karena penemuan HTTP asli bersama dengan HTML dan teknologi yang terkait untuk server web dan web browser berbasis teks. Berners-Lee pertama kali mengajukan proyek "WorldWideWeb" pada tahun 1989 - sekarang dikenal sebagai World Wide Web. Versi pertama dari protokol hanya memiliki satu metode, yaitu GET, yang akan meminta halaman dari server. Tanggapan dari server selalu halaman HTML.
Versi mendokumentasikan pertama HTTP adalah HTTP v0.9 (1991). Dave Raggett memimpin Kelompok Kerja HTTP (HTTP WG) pada tahun 1995 dan ingin memperluas protokol dengan operasi diperpanjang, negosiasi diperpanjang, meta-informasi yang lebih kaya, diikat dengan protokol keamanan yang menjadi lebih efisien dengan menambahkan metode tambahan dan field header. RFC 1945 secara resmi diperkenalkan dan diakui V1.0 HTTP pada tahun 1996.
HTTP WG berencana menerbitkan standar baru pada bulan Desember 1995 dan dukungan untuk pra-standar HTTP / 1.1 berdasarkan RFC kemudian berkembang 2068 (disebut HTTP-NG) dengan cepat diadopsi oleh pengembang browser besar di awal tahun 1996. Pada bulan Maret tahun 1996, HTTP pra-standar / 1.1 didukung di Arena, Netscape 2.0, Netscape Navigator Emas 2.01, Mosaic 2.7, Lynx 2.5, dan Internet Explorer 2.0. Adopsi pengguna akhir dari browser baru itu cepat. Pada bulan Maret 1996, salah satu perusahaan web hosting melaporkan bahwa lebih dari 40% dari browser yang digunakan di Internet adalah HTTP 1.1 compliant. Bahwa perusahaan web hosting yang sama melaporkan bahwa pada bulan Juni tahun 1996, 65% dari semua browser mengakses server mereka HTTP / 1.1 compliant. HTTP / 1.1 standar sebagaimana didefinisikan dalam RFC 2068 secara resmi dirilis pada bulan Januari 1997. Perbaikan dan pembaruan HTTP / 1.1 standar yang dirilis di bawah RFC 2616 pada bulan Juni 1999.
Pada tahun 2007, Kelompok Kerja HTTPbis dibentuk, sebagian, untuk merevisi dan mengklarifikasi HTTP / 1.1 spec. Pada bulan Juni 2014, WG merilis update enam-bagian spesifikasi obsoleting RFC 2616:
RFC 7230 - HTTP / 1.1: Pesan Syntax dan Routing
RFC 7231 - HTTP / 1.1: Semantik dan Konten
RFC 7232 - HTTP / 1.1: Permintaan Bersyarat
RFC 7233 - HTTP / 1.1: Rentang Permintaan
RFC 7234 - HTTP / 1.1: Caching
RFC 7235 - HTTP / 1.1: Otentikasi...
sesi HTTP
Sesi HTTP adalah urutan transaksi permintaan jaringan-respon. Klien HTTP memulai permintaan dengan membentuk Transmission Control Protocol (TCP) koneksi ke port tertentu pada server (biasanya port 80, kadang-kadang port 8080, lihat Daftar TCP dan nomor port UDP). Sebuah server HTTP yang mendengarkan pada port yang menunggu pesan permintaan klien. Setelah menerima permintaan, server akan mengirimkan kembali baris status, seperti "HTTP / 1.1 200 OK", dan pesan tersendiri. Tubuh pesan ini biasanya sumber daya yang diminta, meskipun pesan kesalahan atau informasi lainnya juga dapat dikembalikan.
metode permintaanHTTP 1.1 permintaan dibuat menggunakan telnet. Pesan permintaan, bagian header respon, dan respon tubuh yang disorot.
HTTP mendefinisikan metode (kadang-kadang disebut sebagai kata kerja) untuk menunjukkan tindakan yang diinginkan akan dilakukan pada sumber daya diidentifikasi. Apa sumber daya ini mewakili, apakah data yang sudah ada sebelumnya atau data yang dihasilkan secara dinamis, tergantung pada pelaksanaan server. Seringkali, sumber daya sesuai dengan file atau output dari sebuah eksekusi yang berada di server. HTTP / 1.0 spesifikasi yang ditetapkan GET, POST dan KEPALA metode dan HTTP / 1.1 spesifikasi menambahkan 5 metode baru: PILIHAN, PUT, DELETE, TRACE dan CONNECT. Dengan yang ditentukan dalam dokumen-dokumen semantik mereka terkenal dan dapat diandalkan. Setiap klien dapat menggunakan metode apapun dan server dapat dikonfigurasi untuk mendukung kombinasi metode. Jika metode ini tidak diketahui perantara itu akan diperlakukan sebagai metode yang tidak aman dan non-idempoten. Tidak ada batasan untuk jumlah metode yang dapat didefinisikan dan ini memungkinkan untuk metode masa depan akan ditentukan tanpa melanggar infrastruktur yang ada. Sebagai contoh, WebDAV didefinisikan 7 metode baru dan RFC 5789 ditentukan metode PATCH.
GETPermintaan representasi dari sumber tertentu. Permintaan menggunakan GET hanya harus mengambil data dan seharusnya tidak berpengaruh lainnya. (Hal ini juga berlaku dari beberapa metode HTTP lainnya.) W3C telah menerbitkan prinsip panduan tentang perbedaan ini, mengatakan, "desain aplikasi Web harus diinformasikan oleh prinsip-prinsip di atas, tetapi juga oleh keterbatasan yang relevan." Lihat metode yang aman di bawah ini.
KEPALAMeminta respon identik dengan salah satu yang akan sesuai dengan permintaan GET, tapi tanpa respon tubuh. Hal ini berguna untuk mengambil meta-informasi tertulis dalam header respon, tanpa harus mengangkut seluruh konten.
POSTPermintaan bahwa server menerima entitas tertutup di permintaan sebagai bawahan baru dari sumber daya web yang diidentifikasi oleh URI. Data diposting mungkin, misalnya, penjelasan untuk sumber daya yang ada; pesan untuk papan buletin, newsgroup, mailing list, atau komentar benang; blok data yang merupakan hasil menyerahkan formulir web untuk proses penanganan data; atau item yang akan ditambahkan ke database.
PUTPermintaan bahwa badan tertutup disimpan di bawah disediakan URI. Jika URI mengacu pada sumber daya yang sudah ada, hal itu diubah; jika URI tidak menunjuk ke sebuah sumber daya yang ada, maka server dapat menciptakan sumber daya dengan URI.
DELETEMenghapus sumber daya tertentu.
TRACEGema kembali permintaan yang diterima sehingga klien dapat melihat apa (jika ada) perubahan atau penambahan yang telah dibuat oleh server penengah.
PILIHANMengembalikan metode HTTP server mendukung untuk URL tertentu. Hal ini dapat digunakan untuk memeriksa fungsi server web dengan meminta '*' bukan sumber daya tertentu.
CONNECTMengubah koneksi permintaan ke TCP transparan / IP terowongan, biasanya untuk memfasilitasi SSL-dienkripsi komunikasi (HTTPS) melalui proxy HTTP tidak terenkripsi. Lihat HTTP CONNECT Tunneling.
PATCHBerlaku modifikasi parsial untuk sumber daya.
Server HTTP yang diperlukan untuk melaksanakan setidaknya GET dan metode KEPALA dan, bila memungkinkan, juga metode PILIHAN.
metode aman
Beberapa metode (misalnya, HEAD, GET, PILIHAN dan TRACE), menurut kebiasaan, yang didefinisikan sebagai aman, yang berarti mereka hanya ditujukan untuk pencarian informasi dan tidak harus mengubah keadaan server. Dengan kata lain, mereka tidak harus memiliki efek samping, di luar efek relatif tidak berbahaya seperti penebangan, caching, penyajian iklan banner atau incrementing counter web. Membuat permintaan GET sewenang-wenang tanpa memperhatikan konteks negara aplikasi karenanya harus dianggap aman. Namun, hal ini tidak diamanatkan oleh standar, dan itu secara eksplisit mengakui bahwa tidak mungkin untuk menjamin hal seperti itu.
Sebaliknya, metode seperti POST, PUT, DELETE dan PATCH dimaksudkan untuk aktivitas yang dapat menyebabkan efek samping baik di server, atau efek samping eksternal seperti transaksi keuangan atau transmisi email. Metode tersebut karena itu tidak biasanya digunakan oleh robot sesuai web atau web crawler; beberapa yang tidak sesuai cenderung membuat permintaan tanpa memperhatikan konteks atau konsekuensi. Meskipun keselamatan ditentukan dari permintaan GET, dalam praktek penanganan mereka dengan server tidak secara teknis terbatas dengan cara apapun. Oleh karena itu, pemrograman ceroboh atau sengaja dapat menyebabkan perubahan non-sepele pada server. Hal ini tidak disarankan, karena dapat menyebabkan masalah untuk caching web, mesin pencari dan agen otomatis lainnya, yang dapat membuat perubahan yang tidak diinginkan pada server.
Metode dan aplikasi web idempoten
Metode PUT dan DELETE didefinisikan untuk idempoten, yang berarti bahwa beberapa permintaan yang identik harus memiliki efek yang sama dengan satu permintaan (perhatikan idempotence yang mengacu pada keadaan sistem setelah permintaan telah selesai, maka sementara aksi server mengambil (misalnya menghapus catatan) atau kode respon itu kembali mungkin berbeda pada kunjungan berikutnya, sistem negara akan sama setiap kali). Metode GET, HEAD, PILIHAN dan TRACE, yang diresepkan aman, juga harus idempoten, HTTP adalah protokol stateless. Sebaliknya, metode POST belum tentu idempoten, dan karena itu mengirimkan permintaan POST identik beberapa kali lebih dapat mempengaruhi negara atau menyebabkan efek samping lebih lanjut (seperti transaksi keuangan). Dalam beberapa kasus ini mungkin diinginkan, namun dalam kasus lain ini bisa disebabkan oleh kecelakaan, seperti ketika pengguna tidak menyadari bahwa tindakan mereka akan menghasilkan mengirim permintaan lain, atau mereka tidak menerima umpan balik yang memadai bahwa permintaan pertama mereka sukses. Sementara web browser dapat menampilkan kotak dialog peringatan untuk memperingatkan pengguna dalam beberapa kasus di mana reload halaman bisa kembali mengajukan permintaan POST, biasanya sampai ke aplikasi web untuk menangani kasus-kasus di mana permintaan POST tidak boleh mengirimkan lebih dari satu kali. Perhatikan bahwa apakah metode ini idempoten tidak ditegakkan oleh protokol atau server web. Hal ini sangat mungkin untuk menulis aplikasi web di mana (misalnya) memasukkan database atau tindakan non-idempoten lain dipicu oleh GET atau permintaan lainnya. Mengabaikan rekomendasi ini, bagaimanapun, dapat mengakibatkan konsekuensi yang tidak diinginkan, jika agen pengguna mengasumsikan bahwa mengulang permintaan yang sama aman jika tidak.
keamanan
Metode pelaksanaan seperti TRACE, TRACK dan DEBUG dianggap berpotensi tidak aman oleh beberapa profesional keamanan karena penyerang dapat menggunakannya untuk mengumpulkan informasi atau keamanan memotong kontrol selama serangan. Perangkat lunak keamanan seperti Dipertahankan Nessus dan laporan Microsoft UrlScan Alat Keamanan pada kehadiran metode ini sebagai masalah keamanan. TRACK dan DEBUG tidak HTTP valid 1.1 verba.
kode StatusDalam HTTP / 1.0 dan sejak, baris pertama dari respon HTTP disebut baris status dan termasuk status kode angka (seperti "404") dan frase alasan tekstual (seperti "Not Found"). Cara agen pengguna menangani respon terutama tergantung pada kode dan sekunder pada field header respon lainnya. Kode status khusus dapat digunakan karena, jika agen pengguna bertemu dengan kode yang tidak mengakui, ia dapat menggunakan digit pertama dari kode tersebut untuk menentukan kelas umum respon.
Juga, frase alasan standar hanya rekomendasi, dan bisa diganti dengan "setara lokal" kebijaksanaan pengembang Web. Jika kode status menunjukkan masalah, agen pengguna mungkin menampilkan frase alasan kepada pengguna untuk memberikan informasi lebih lanjut tentang sifat dari masalah. Standar ini juga memungkinkan user agent untuk mencoba menafsirkan kalimat alasan, meskipun ini mungkin tidak bijaksana karena standar secara eksplisit menetapkan bahwa kode status yang dapat dibaca oleh mesin dan frase alasan yang terbaca-manusia. Kode status HTTP terutama dibagi menjadi lima kelompok untuk penjelasan yang lebih baik dari permintaan dan respon antara klien dan server sebagai nama: Informational 1XX, Sukses 2xx, 3xx Redirection, Kesalahan Klien 4xx dan Server Error 5XX.
koneksi persistentDalam HTTP / 0.9 dan 1.0, koneksi ditutup setelah sepasang request / respon tunggal. Dalam HTTP / 1.1 yang terus-hidup-mekanisme diperkenalkan, di mana sambungan bisa digunakan kembali untuk lebih dari satu permintaan. Koneksi persisten seperti mengurangi permintaan latency jelas, karena klien tidak perlu negosiasi ulang TCP koneksi 3-Way-Handshake setelah permintaan pertama telah dikirim. Efek samping lain yang positif adalah bahwa secara umum koneksi menjadi lebih cepat dengan waktu karena lambat start-mekanisme TCP.
Versi 1.1 dari protokol juga membuat perbaikan optimasi bandwidth untuk HTTP / 1.0. Sebagai contoh, HTTP / 1.1 diperkenalkan Transfer chunked pengkodean untuk memungkinkan konten pada koneksi persisten dapat ditayangkan daripada buffer. HTTP pipelining lanjut mengurangi jeda waktu, yang memungkinkan klien untuk mengirimkan beberapa permintaan sebelum menunggu setiap respon. Perbaikan lain protokol adalah byte melayani, di mana server mengirimkan hanya bagian dari sumber daya secara eksplisit diminta oleh klien.
HTTP adalah protokol stateless. Sebuah protokol stateless tidak memerlukan server HTTP untuk mempertahankan informasi atau status tentang setiap pengguna selama beberapa permintaan. Namun, beberapa aplikasi web menerapkan negara atau sesi sisi server menggunakan cookies misalnya HTTP atau variabel tersembunyi dalam bentuk web.
koneksi terenkripsiCara yang paling populer membangun koneksi HTTP terenkripsi adalah Secure HTTP.
Dua metode lain untuk membangun koneksi HTTP terenkripsi juga ada, disebut aman Hypertext Transfer Protocol dan HTTP / 1.1 sundulan Upgrade. Dukungan Browser untuk ini dua terakhir adalah, bagaimanapun, hampir tidak ada sehingga Secure HTTP adalah metode dominan membangun koneksi HTTP terenkripsi.
pesan permintaan- Sebuah garis permintaan, misalnya GET /images/logo.png HTTP / 1.1, yang meminta sumber daya disebut /images/logo.png dari server.
- Field header permintaan, seperti Accept-Language: en
- Baris kosong.
- Sebuah badan pesan opsional.
Garis permintaan dan bidang header lain harus setiap akhir dengan <CR> <LF> (yaitu, karakter carriage return diikuti oleh karakter line feed). Baris kosong harus terdiri dari hanya <CR> <LF> dan tidak ada spasi lainnya. Dalam HTTP / 1.1 protokol, semua field header kecuali host adalah opsional.
Sebuah garis permintaan yang hanya berisi nama path diterima oleh server untuk menjaga kompatibilitas dengan HTTP klien sebelum HTTP / 1.0 spesifikasi RFC 1945.
pesan respon- Sebuah Status-Line, yang meliputi kode status dan pesan alasan. (misalnya, HTTP / 1.1 200 OK, yang menunjukkan bahwa permintaan klien berhasil)
- Field header respon, seperti Content-Type: text / html
- Baris kosong
- Sebuah badan pesan opsional
Status-Line dan bidang header lain semua harus diakhiri dengan <CR> <LF> (carriage return diikuti oleh line feed). Baris kosong harus terdiri dari hanya <CR> <LF> dan tidak ada spasi lainnya.
sesi contoh
Di bawah ini adalah percakapan antara sampel klien HTTP dan server HTTP berjalan pada www.example.com, port 80.
permintaan klien- GET /index.html HTTP / 1.1
- Host: www.example.com
Sebuah permintaan klien (terdiri dalam hal ini garis permintaan dan hanya satu kolom header) diikuti dengan baris kosong, sehingga permintaan berakhir dengan baris ganda, masing-masing dalam bentuk carriage return diikuti dengan line feed. The "Host" lapangan membedakan antara berbagai nama DNS berbagi satu alamat IP, yang memungkinkan-nama berdasarkan virtual hosting. Sementara opsional dalam HTTP / 1.0, itu adalah wajib dalam HTTP / 1.1.
respon server- HTTP / 1.1 200 OK
- Tanggal: Mon, 23 Mei 2005 22:38:34 GMT
- Server: Apache / 1.3.3.7 (Unix) (Red-Hat / Linux)
- Last-Modified: Wed, 8 Januari 2003 23:11:55 GMT
- ETag: "3f80f-1b6-3e1cb03b"
- Content-Type: text / html; charset = UTF-8
- Content-Length: 131
- Terima-Ranges: bytes
- Koneksi: tutup
<html>
<head>
<title> Contoh Halaman </ title>
</ head>
<body>
Hello World, ini adalah dokumen HTML yang sangat sederhana.
</ body>
</ html>
ETag (tag badan) kolom header digunakan untuk menentukan apakah versi cache dari sumber daya yang diminta identik dengan versi terbaru dari sumber daya pada server. Content-Type menentukan jenis media internet dari data yang disampaikan oleh pesan HTTP, sementara Content-Length menunjukkan panjang dalam bytes. HTTP / 1.1 webserver menerbitkan kemampuannya untuk menanggapi permintaan untuk rentang byte tertentu dari dokumen dengan menetapkan bidang Terima-Ranges: bytes. Hal ini berguna, jika klien harus memiliki hanya bagian-bagian tertentu dari sumber daya yang dikirim oleh server, yang disebut byte melayani. Ketika Connection: close dikirim, itu berarti bahwa server web akan segera menutup koneksi TCP setelah transfer respon ini.
Sebagian besar garis header opsional. Ketika Content-Length hilang panjang ditentukan dengan cara lain. Chunked Transfer encoding menggunakan ukuran potongan 0 untuk menandai akhir dari konten. Encoding identitas tanpa Content-Length membaca isi sampai soket ditutup.
Sebuah Content-Encoding seperti gzip dapat digunakan untuk kompres data yang ditransmisikan.
protokol yang samaProtokol Gopher adalah protokol pengiriman konten yang mengungsi karena HTTP di awal 1990-an. Protokol SPDY baru juga mirip dengan HTTP, memodifikasi interaksi permintaan-respon antara klien dan server. By Azure
_tn.jpg)
![Download Bleach Episode Lengkap 1-366 Tamat [Batch] Subtitle Indonesia](https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjg7xSKCNNTN5Qt7Di1NNLFxoqX5xxz8RIAMvIokagQibdhLFsoRrLTknwsSfTTZ8LU39Fwpk5I6KiDaE_SoghX3sxRuf_XgqkrP3tVBBVCQ6zneSddsXDQbVA7AcWIgR7FcAIlWtSpouY_/s72-c/awesome-bleach-widescreen-high-definition-wallpaper-download-pictures-free.jpg "Download Bleach Episode Lengkap 1-366 Tamat [Batch] Subtitle Indonesia")
