|
#ALIH [[HTTP]]
{{Infobox protocol|image=HTTP logo.svg|standard=RFC 1945 HTTP/1.0 <small>(1996)</small><br />
RFC 2616 HTTP/1.1 <small>(1999)</small><br />
RFC 7540 HTTP/2 <small>(2015)</small><br />
RFC 7541 Kompresi Header <small>(2, 2015)</small><br />
RFC 7230 Pesan sintaks dan Routing <small>(1.1, 2014)</small><br />
RFC 7231 Semantik dan Konten <small>(1.1, 2014)</small><br />
RFC 7232 Permintaan Bersyarat <small>(1.1, 2014)</small><br />
RFC 7233 Rentang Permintaan <small>(1.1, 2014)</small><br />
RFC 7234 Caching <small>(1.1, 2014)</small><br />
RFC 7235 Autentikasi <small>(1.1, 2014)</small>|developer=Mulanya [[CERN]]; [[IETF]], [[W3C]]|introdate={{Start date and age|1991|df=yes}}|newer=}}'''Hypertext Transfer Protocol''' ('''HTTP''') adalah [[protokol aplikasi|protokol pada lapisan aplikasi]] untuk sistem informasi hypermedia yang terdistribusi dan kolaboratif.<ref name=":1">{{Cite web|url=https://tools.ietf.org/html/rfc2616.html|title=Hypertext Transfer Protocol -- HTTP/1.1|last=Leach|first=Paul J.|last2=Berners-Lee|first2=Tim|website=tools.ietf.org|language=en|access-date=2020-06-23|last3=Mogul|first3=Jeffrey C.|last4=Masinter|first4=Larry|last5=Fielding|first5=Roy T.|last6=Gettys|first6=James}}</ref> HTTP adalah dasar komunikasi data untuk [[World Wide Web]], di mana dokumen [[hiperteks]] menyertakan hyperlink ke sumber daya lain yang dapat dengan mudah diakses pengguna, misalnya dengan mengklik [[mouse]] atau dengan mengetuk layar di peramban web.
Pengembangan HTTP diprakarsai oleh [[Tim Berners-Lee]] di [[CERN]] pada tahun 1989. Pengembangan Permintaan HTTP awal untuk Komentar (RFC) adalah upaya terkoordinasi oleh [[Internet Engineering Task Force]] (IETF) dan [[World Wide Web Consortium]] (W3C), dengan pekerjaan kemudian pindah ke IETF.
HTTP/1.1 pertama kali didokumentasikan dalam RFC 2068 pada tahun 1997. Spesifikasi itu sudah usang oleh RFC 2616 pada tahun 1999, yang juga digantikan oleh keluarga RFC 7230 RFC pada tahun 2014.
[[HTTP/2]] adalah ekspresi semantik HTTP yang lebih efisien "on the wire", dan diterbitkan pada 2015; sekarang didukung oleh hampir semua peramban web<ref>{{Cite web|url=https://caniuse.com/#search=http2|title=Can I use... Support tables for HTML5, CSS3, etc|website=caniuse.com|access-date=2020-06-23}}</ref> dan server web utama melalui [[Transport Layer Security]] (TLS) menggunakan ekstensi [[Application-Layer Protocol Negotiation]] (ALPN)<ref>{{Cite web|url=https://tools.ietf.org/html/rfc7301.html|title=Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension|last=Friedl|first=Stephan|last2=Langley|first2=Adam|website=tools.ietf.org|language=en|access-date=2020-06-23|last3=Popov|first3=Andrey}}</ref> di mana diperlukan [[Transport Layer Security|TLS 1.2]] atau yang lebih baru.<ref>{{Cite web|url=https://http2.github.io/http2-spec/#TLSUsage|title=Hypertext Transfer Protocol Version 2 (HTTP/2)|last=Belshe|first=M.|last2=Peon|first2=R.|date=2015-05-30|website=http2.github.io|language=en|access-date=2020-06-23|last3=Thomson|first3=M.|archive-date=2013-07-15|archive-url=https://web.archive.org/web/20130715004452/https://http2.github.io/http2-spec/#TLSUsage|dead-url=yes}}</ref>
[[HTTP/3]] adalah penerus yang diusulkan untuk HTTP/2,<ref>{{Cite web|url=https://tools.ietf.org/html/draft-ietf-quic-http-22.html|title=Hypertext Transfer Protocol Version 3 (HTTP/3)|last=Bishop <[email protected]>|first=Mike|website=tools.ietf.org|language=en|access-date=2020-06-23}}</ref> yang sudah digunakan di web, menggunakan [[Udp|UDP]] bukan [[TCP]] untuk protokol transportasi yang mendasarinya. Seperti HTTP/2, protokol ini tidak ketinggalan versi utama sebelumnya. Dukungan untuk HTTP/ 3 ditambahkan ke [[Cloudflare]] dan [[Google Chrome]] pada September 2019,<ref>{{Cite web|url=https://www.zdnet.com/article/cloudflare-google-chrome-and-firefox-add-http3-support/|title=Cloudflare, Google Chrome, and Firefox add HTTP/3 support|last=Cimpanu|first=Catalin|website=ZDNet|language=en|access-date=2020-06-23}}</ref> dan dapat diaktifkan di versi stabil Chrome dan Firefox.<ref>{{Cite web|url=https://community.cloudflare.com/t/firefox-nightly-supports-http-3/127778|title=Firefox Nightly supports HTTP 3|date=2019-11-06|website=Cloudflare Community|language=en-US|access-date=2020-06-23}}</ref>
== Gambaran teknikal ==
[[Berkas:Internet1.svg|ka|jmpl|[[URL]] dimulai dengan skema HTTP dan label nama domain [[WWW]]]]
HTTP berfungsi sebagai protokol [[Permintaan-respon|permintaan-respons]] dalam model komputasi klien-server. [[Peramban web]], misalnya, mungkin ''klien'' dan aplikasi yang berjalan di komputer yang meng-[[Host (jaringan)|hosting]] [[situs web]] mungkin adalah ''server''. Klien mengirimkan 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 ''respons'' ke klien. Respons tersebut berisi informasi status penyelesaian tentang permintaan dan mungkin juga berisi konten yang diminta di badan pesannya.
Peramban web adalah contoh ''[[user agent]]'' (UA). Jenis lain dari agen pengguna termasuk perangkat lunak pengindeksan yang digunakan oleh penyedia pencarian ([[perayap web]]), [[peramban suara]], [[aplikasi seluler]], dan [[perangkat lunak]] lain yang mengakses, menggunakan, atau menampilkan konten web.
HTTP dirancang untuk mengizinkan elemen jaringan perantara untuk meningkatkan atau mengaktifkan komunikasi antara klien dan server. Situs web dengan lalu lintas tinggi sering kali mendapatkan keuntungan dari server [[Tembolok web|cache web]] yang mengirimkan konten atas nama [[Server upstream|server hulu]] untuk meningkatkan waktu respon. Tembolok peramban web sebelumnya mengakses sumber daya web dan menggunakannya kembali, jika memungkinkan, untuk mengurangi lalu lintas jaringan. [[Server proxy]] HTTP pada batas [[jaringan pribadi]] dapat memfasilitasi komunikasi untuk klien tanpa alamat yang dapat dirutekan secara global, dengan menyampaikan pesan dengan server eksternal.
[[Sumber daya web|Sumber daya HTTP]] diidentifikasi dan ditempatkan di jaringan oleh [[Url|Uniform Resource Locators]] (URL), menggunakan skema ''http'' dan ''[[https]]'' [[Pengidentifikasi sumber seragam|Uniform Resource Identifiers]] (URI). Seperti yang didefinisikan dalam RFC 3986, URI dikodekan sebagai [[hyperlink]] dalam dokumen [[HTML]], sehingga dapat membentuk dokumen hypertext yang saling terkait.
== Sejarah ==
[[Berkas:Tim_Berners-Lee_CP_2.jpg|jmpl|[[Tim Berners-Lee]]]]
Istilah [[hypertext]] diciptakan oleh [[Ted Nelson]] pada tahun 1965 di [[Proyek Xanadu]], yang pada gilirannya terinspirasi oleh visi 1930-an [[Vannevar Bush]] tentang pengambilan informasi berbasis mikrofilm dan sistem "[[memex]]" manajemen yang dijelaskan dalam esai 1945-nya "[[As We May Think]]". [[Tim Berners-Lee]] dan timnya di [[CERN]] dikreditkan dengan menciptakan HTTP asli, bersama dengan HTML dan teknologi terkait untuk server web dan browser web berbasis teks. Berners-Lee pertama kali mengusulkan proyek "WorldWideWeb" pada tahun 1989 - sekarang dikenal sebagai [[World Wide Web]]. Versi pertama protokol hanya memiliki satu metode, yaitu GET, yang akan meminta halaman dari server.<ref>{{cite web|url=https://www.w3.org/History/19921103-hypertext/hypertext/WWW/Protocols/HTTP.html|title=HyperText Transfer Protocol|last=Berners-Lee|first=Tim|publisher=[[World Wide Web Consortium]]|accessdate=31 August 2010}}</ref> Respons dari server selalu berupa halaman HTML.<ref>{{cite web|url=https://www.w3.org/Protocols/HTTP/AsImplemented.html|title=The Original HTTP as defined in 1991|author=Tim Berners-Lee|author-link=Tim Berners-Lee|publisher=World Wide Web Consortium|accessdate=24 July 2010}}</ref>
Versi HTTP terdokumentasi pertama adalah '''[https://www.w3.org/pub/WWW/Protocols/HTTP/AsImplemented.html HTTP V0.9]''' (1991). [[Dave Raggett]] memimpin Kelompok Kerja HTTP (HTTP WG) pada tahun 1995 dan ingin memperluas protokol dengan operasi yang diperpanjang, negosiasi yang lebih luas, meta-informasi yang lebih kaya, diikat dengan protokol keamanan yang menjadi lebih efisien dengan menambahkan metode tambahan dan [[bidang header]].<ref>{{Cite web|url=https://www.w3.org/Arena/webworld/httpwgcharter.html|title=HTTP Working Group|website=www.w3.org|access-date=2020-06-23}}</ref> RFC 1945 secara resmi memperkenalkan dan mengakui HTTP V1.0 pada tahun 1996.
Pada tahun 2007, [https://httpwg.org/ '''Kelompok Kerja HTTP'''] dibentuk, sebagian, untuk merevisi dan mengklarifikasi spesifikasi HTTP/1.1. Pada Juni 2014, WG merilis spesifikasi enam bagian yang diperbarui RFC 2616 yang sudah usang:
* {{IETF RFC|7230}}, ''HTTP/1.1: Sintaks dan Routing Pesan''
* {{IETF RFC|7231}}, ''HTTP/1.1: Semantik dan Konten''
* {{IETF RFC|7232}}, ''HTTP/1.1: Permintaan Bersyarat''
* {{IETF RFC|7233}}, ''HTTP/1.1: Rentang Permintaan''
* {{IETF RFC|7234}}, ''HTTP/1.1: Caching''
* {{IETF RFC|7235}}, ''HTTP/1.1: Autentikasi''
[[HTTP/2]] diterbitkan sebagai {{IETF RFC|7540}} pada Mei 2015.
{| class="wikitable"
!Tahun
!Versi HTTP
|-
|1991
|0.9
|-
|1996
|1.0
|-
|1997
|1.1
|-
|2015
|[[HTTP/2|2.0]]
|-
|2018
|[[HTTP/3|3.0]]
|}
== Sesi HTTP ==
Sesi HTTP adalah urutan transaksi respons-permintaan jaringan. Klien HTTP memulai permintaan dengan membuat koneksi [[Transmission Control Protocol]] (TCP) ke [[Port (Jaringan Komputer)|port]] tertentu pada server (biasanya port 80, terkadang port 8080; lihat [[Daftar nomor port TCP dan UDP]]). Server HTTP yang mendengarkan port itu menunggu pesan permintaan klien. Setelah menerima permintaan, server mengirim kembali baris status, seperti "HTTP/1.1 200 OK", dan pesannya sendiri. Isi pesan ini biasanya adalah sumber yang diminta, meskipun pesan kesalahan atau informasi lain juga dapat dikembalikan.<ref name=":1" />
=== Koneksi persisten ===
Dalam HTTP/0.9 dan 1.0, koneksi ditutup setelah satu pasangan permintaan / respons. Dalam HTTP/1.1 mekanisme keep-hidup diperkenalkan, di mana koneksi dapat digunakan kembali untuk lebih dari satu permintaan. ''Koneksi persisten'' seperti itu mengurangi [[Latensi (teknik)|latensi]] permintaan dengan jelas, karena klien tidak perlu menegosiasikan kembali koneksi TCP 3-Way-Handshake setelah permintaan pertama dikirim. Efek samping positif lainnya adalah, secara umum, koneksi menjadi lebih cepat seiring berjalannya waktu karena mekanisme [[TCP congestion control#Slow start|slow-start]]-TCP.
Versi 1.1 protokol juga membuat peningkatan optimasi bandwidth ke HTTP/1.0. Misalnya, HTTP/1.1 memperkenalkan [[chunked transfer encoding]] untuk memungkinkan konten pada koneksi yang persisten di-stream daripada buffer. [[Perpipaan HTTP]] lebih lanjut mengurangi waktu jeda, memungkinkan klien untuk mengirim beberapa permintaan sebelum menunggu setiap tanggapan. Tambahan lain untuk protokol adalah [[byte serving]], di mana server mentransmisikan hanya sebagian dari sumber daya yang secara eksplisit diminta oleh klien.
=== Status sesi HTTP ===
HTTP adalah [[stateless protocol]]. Stateless protocol tidak memerlukan [[Server web|server HTTP]] untuk menyimpan informasi atau status tentang setiap pengguna selama beberapa permintaan. Namun, beberapa [[aplikasi web]] menerapkan independen atau [[Sesi (ilmu komputer)|sesi sisi server]] semenggunakan misalnya [[cookie HTTP]] atau [[Variabel (ilmu komputer)|variabel]] tersembunyi dalam [[Formulir (HTML)|formulir web]].
== Autentikasi HTTP ==
HTTP menyediakan beberapa skema otentikasi seperti [[otentikasi akses dasar]] dan [[intisari akses otentikasi]] yang beroperasi melalui mekanisme respons-respons di mana server mengidentifikasi dan mengeluarkan tantangan sebelum menyajikan konten yang diminta.
HTTP menyediakan kerangka kerja umum untuk kontrol akses dan otentikasi, melalui serangkaian skema otentikasi respons-responsif, yang dapat digunakan oleh server untuk menantang permintaan klien dan oleh klien untuk memberikan informasi otentikasi.<ref name=":0">{{Cite web|url=https://tools.ietf.org/html/rfc7235.html|title=Hypertext Transfer Protocol (HTTP/1.1): Authentication|last=Reschke|first=Julian F.|last2=Fielding|first2=Roy T.|website=tools.ietf.org|language=en|access-date=2020-06-23}}</ref>
=== Alam autentikasi ===
Spesifikasi Otentikasi HTTP juga menyediakan konstruksi sewenang-wenang, spesifik implementasi untuk membagi lebih lanjut sumber daya yang umum untuk [[Uniform Resource Identifier|URI]] root yang diberikan. String nilai ranah, jika ada, dikombinasikan dengan URI akar kanonik untuk membentuk komponen ruang perlindungan dari tantangan. Ini berlaku memungkinkan server untuk menentukan cakupan otentikasi terpisah di bawah satu URI root.<ref name=":0" />
== Format pesan ==
Klien mengirim '''permintaan''' ke server dan server mengirim '''tanggapan'''.
=== Permintaan pesan ===
[[Berkas:Http request telnet ubuntu.png|jmpl|ka|250px|Permintaan HTTP 1.1 dibuat menggunakan telnet. Pesan [[Hypertext Transfer Protocol#Permintaan pesan|permintaan]], bagian tajuk [[Hypertext Transfer Protocol#Pesan tanggapan|respons]], dan badan respons disorot.]]
Pesan permintaan terdiri dari:
* baris permintaan (mis., ''GET /images/logo.png HTTP / 1.1'', yang meminta sumber daya yang disebut {{code|/images/logo.png}} dari server)
* bidang tajuk permintaan (mis., ''Bahasa Terima: id'')
* garis kosong
* [[Badan pesan HTTP|badan pesan]] opsional
Baris permintaan dan bidang tajuk lainnya masing-masing harus diakhiri dengan <CR> <LF> (yaitu, karakter [[carriage return]] diikuti oleh karakter umpan baris). Baris kosong harus terdiri dari hanya <CR> <LF> dan tidak ada [[Karakter spasi putih|spasi putih]] lainnya.<ref name=":1" /> Dalam protokol HTTP/1.1, semua bidang tajuk kecuali ''Host'' adalah opsional.
Baris permintaan yang hanya berisi nama jalur diterima oleh server untuk menjaga kompatibilitas dengan klien HTTP sebelum spesifikasi HTTP/1.0 dalam RFC 1945<ref>{{Cite web|url=http://www.apacheweek.com/features/http11.html|title=Apache Week. HTTP/1.1|website=www.apacheweek.com|access-date=2020-06-23}}</ref>
==== Metode permintaan ====
HTTP mendefinisikan metode (kadang-kadang disebut sebagai kata kerja, tetapi tidak ada dalam spesifikasi yang menyebutkan kata kerja, juga OPTIONS atau HEAD kata kerja) untuk menunjukkan tindakan yang diinginkan untuk dilakukan pada sumber daya yang diidentifikasi. Sumber daya ini mewakili, apakah data yang sudah ada sebelumnya atau data yang dihasilkan secara dinamis, tergantung pada implementasi server. Seringkali, sumber daya berhubungan dengan file atau output dari executable yang berada di server. Spesifikasi HTTP/1.0<ref>{{Cite web|url=https://tools.ietf.org/html/rfc1945.html|title=Hypertext Transfer Protocol -- HTTP/1.0|last=Nielsen|first=Henrik Frystyk|last2=Berners-Lee|first2=Tim|website=tools.ietf.org|language=en|access-date=2020-06-23|last3=Fielding|first3=Roy T.}}</ref> mendefinisikan metode GET, HEAD dan POST dan spesifikasi HTTP/1.1<ref name=":1" /> menambahkan lima metode baru: OPTIONS, PUT, DELETE, TRACE , dan CONNECT.
; HEAD:Metode HEAD meminta respons yang identik dengan permintaan GET, tetapi tanpa badan respons. Ini berguna untuk mengambil meta-informasi yang ditulis di header respons, tanpa harus mengangkut seluruh konten.
; GET: Meminta representasi sumber tertentu. Permintaan menggunakan GET (dan beberapa metode HTTP lain) "tidak boleh memiliki kepentingan melakukan tindakan selain [[pengaksesan data|pengaksesan]]". [[W3C]] telah menerbitkan prinsip panduan mengenai perbedaan ini dengan menyatakan, "desain [[aplikasi web]] harus mematuhi prinsip di atas, serta batasan sejenis."<ref>{{cite web|last=Jacobs|first=Ian|title=URIs, Addressability, and the use of HTTP GET and POST|url=http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist|work= Technical Architecture Group finding|publisher=W3C|accessdate=26 September 2010|year=2004}}</ref>
; POST:[[POST (HTTP)|Metode POST]] meminta server menerima entitas yang terlampir dalam permintaan sebagai bawahan baru sumber daya web yang diidentifikasi oleh URI. Data POSTed mungkin, misalnya, anotasi untuk sumber daya yang ada; pesan untuk papan buletin, newsgroup, milis, atau utas komentar; blok data yang merupakan hasil dari mengirimkan formulir web ke proses penanganan data; atau item untuk ditambahkan ke database.<ref name=":1" />
; PUT:Metode PUT meminta entitas terlampir disimpan di bawah [[Uniform Resource Identifier|URI]] yang disediakan. Jika URI mengacu pada sumber daya yang sudah ada, itu diubah; jika URI tidak menunjuk ke sumber daya yang ada, maka server dapat membuat sumber daya dengan URI itu.<ref name=":1" />
; DELETE:Metode DELETE menghapus sumber daya yang ditentukan.
; TRACE:Metode TRACE menggemakan permintaan yang diterima sehingga klien dapat melihat apa (jika ada) perubahan atau penambahan yang telah dilakukan oleh server perantara.
; OPTIONS:Metode OPTIONS mengembalikan metode HTTP yang didukung server untuk [[URL]] yang ditentukan. Ini dapat digunakan untuk memeriksa fungsionalitas server web dengan meminta '*' alih-alih sumber daya tertentu.
; CONNECT:<ref name=":1" /> Metode CONNECT mengubah koneksi permintaan ke [[Protokol Tunneling|terowongan TCP / IP]] transparan, biasanya untuk memfasilitasi komunikasi terenkripsi [[TLS|SSL]] (HTTPS) melalui proxy HTTP yang tidak terenkripsi.<ref>{{Cite web|url=https://www.kb.cert.org/vuls/id/150227|title="Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections".|last=|first=|date=|website=www.kb.cert.org|access-date=2020-06-23}}</ref> Lihat [[Terowongan HTTP#Metode HTTP CONNECT|metode HTTP CONNECT]].
; PATCH:Metode PATCH menerapkan modifikasi parsial ke sumber daya.<ref>{{cite web
| url = http://tools.ietf.org/html/rfc5789
| title = RFC 5789: PATCH Method for HTTP
| first1 = Lisa | last1 = Dusseault | first2 = James M. | last2 = Snell
}}</ref>
Semua server HTTP tujuan umum wajib menerapkan setidaknya metode GET dan HEAD, dan semua metode lain dianggap opsional oleh spesifikasi.<ref name=":1" />
===== Keamanan =====
Metode TRACE dapat digunakan sebagai bagian dari kelas serangan yang dikenal sebagai [[cross-site tracing]]; untuk alasan itu, saran keamanan umum adalah agar dinonaktifkan di konfigurasi server.<ref name="OWASP-XST">{{cite web|url=https://www.owasp.org/index.php/Cross_Site_Tracing|title=Cross Site Tracing|publisher=[[OWASP]]|accessdate=2016-06-22}}</ref> Microsoft [[IIS]] mendukung metode "TRACK", yang berperilaku sama, dan yang juga direkomendasikan untuk dinonaktifkan.<ref name="OWASP-XST" />
{| class="wikitable sortable" style="text-align: center; width: auto; table-layout: fixed;"
|+Keamanan dari metode HTTP
|-
!scope="col"| Metode HTTP
!scope="col"| RFC
!scope="col"| Permintaan memiliki body
!scope="col"| Respons memiliki body
!scope="col"| Aman
!scope="col"| Idempoten
!scope="col"| Cacheable
|-
!scope="row"| GET
| {{IETF RFC|7231}}
| {{Optional}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-
!scope="row"| HEAD
| {{IETF RFC|7231}}
| {{Optional}}
| {{No}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
|-
!scope="row"| POST
| {{IETF RFC|7231}}
| {{Yes}}
| {{Yes}}
| {{No}}
| {{No}}
| {{Yes}}
|-
!scope="row"| PUT
| {{IETF RFC|7231}}
| {{Yes}}
| {{Yes}}
| {{No}}
| {{Yes}}
| {{No}}
|-
!scope="row"| DELETE
| {{IETF RFC|7231}}
| {{Optional}}
| {{Yes}}
| {{No}}
| {{Yes}}
| {{No}}
|-
!scope="row"| CONNECT
| {{IETF RFC|7231}}
| {{Optional}}
| {{Yes}}
| {{No}}
| {{No}}
| {{No}}
|-
!scope="row"| OPTIONS
| {{IETF RFC|7231}}
| {{Optional}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{No}}
|-
!scope="row"| TRACE
| {{IETF RFC|7231}}
| {{No}}
| {{Yes}}
| {{Yes}}
| {{Yes}}
| {{No}}
|-
!scope="row"| PATCH
| {{IETF RFC|5789}}
| {{Yes}}
| {{Yes}}
| {{No}}
| {{No}}
| {{No}}
|}
=== Respon pesan ===
Pesan respons terdiri dari berikut ini:
* baris status yang mencakup [[Daftar kode status HTTP|kode status]] dan pesan alasan (e.g., ''HTTP/1.1 200 OK'', yang mengindikasikan bahwa permintaan klien berhasil)
* [[Daftar bidang header HTTP#Bidang respons|bidang header respons]] (mis., ''Content-Type: text/html'')
* Sebuah garis kosong
* Sebuah [[HTTP message body|message body]] opsional
Baris status dan bidang header lainnya harus diakhiri dengan <CR><LF>. Baris kosong harus terdiri dari hanya <CR><LF> dan tidak ada [[Karakter spasi|spasi putih]] lainnya.<ref name="ietf2616sec4" /> Persyaratan ketat ini untuk <CR><LF> adalah berelaksi dalam badan pesan untuk penggunaan konsisten dari linebreak sistem lain seperti <CR> atau <LF> saja.<ref>{{cite IETF|rfc=2616|sectionname=Canonicalization and Text Defaults|title=RFC 2616|section=3.7.1|idanchor=ietf}}</ref>
==== Kode status ====
{{See also|Daftar kode status HTTP}}Dalam HTTP/1.0 dan sejak itu, baris pertama dari respons HTTP disebut ''baris status'' dan termasuk ''kode status'' numerik (seperti "[[HTTP 404|404]]") dan frase ''alasan'' tekstual (seperti "Not Found"). Cara [[agen pengguna]] menangani respons bergantung terutama pada kode, dan yang kedua pada bidang header respons lainnya. Kode status khusus dapat digunakan, karena jika agen pengguna menemukan kode yang tidak dikenali, ia dapat menggunakan digit pertama dari kode untuk menentukan kelas umum dari respons.<ref>{{cite IETF|rfc=2616|sectionname=Status-Line|section=6.1|title=RFC 2616|page=39|idanchor=ietf}}</ref>
''Ungkapan alasan'' standar hanya rekomendasi, dan dapat diganti dengan "setara lokal" atas kebijakan [[pengembang web]]. Jika kode status menunjukkan masalah, agen pengguna mungkin menampilkan ''frasa alasan'' kepada pengguna untuk memberikan informasi lebih lanjut tentang sifat masalah. Standar juga memungkinkan agen pengguna untuk mencoba menafsirkan frasa alasan, meskipun ini mungkin tidak bijaksana karena standar secara eksplisit menentukan bahwa kode status dapat dibaca mesin dan ''frasa alasan'' dapat dibaca oleh manusia. Kode status HTTP terutama dibagi menjadi lima kelompok untuk penjelasan permintaan dan tanggapan yang lebih baik antara klien dan server seperti yang disebutkan:
* Informational <code>1XX</code>
* Berhasil <code>2XX</code>
* Pengalihan <code>3XX</code>
* Klien Error <code>4XX</code>
* Server Error <code>5XX</code>
== Koneksi terenkripsi ==
Cara paling populer untuk membangun koneksi HTTP terenkripsi adalah HTTPS.<ref>{{Cite journal|last=|first=|date=|title=Canavan, John (2001). Fundamentals of Networking Security. Norwood, MA: Artech House. pp. 82–83.|url=https://en.wiki-indonesia.club/wiki/Special:BookSources/9781580531764|journal=Wikipedia|language=en|volume=|issue=|pages=|doi=}}</ref> Dua metode lain untuk membuat koneksi HTTP terenkripsi juga ada: [[Secure Hypertext Transfer Protocol]], dan menggunakan [[header Upgrade HTTP/1.1]] untuk menentukan peningkatan ke TLS. Dukungan browser untuk keduanya, bagaimanapun, hampir tidak ada.<ref>{{Cite web|last=|first=|date=|title="Browser Security Handbook".|url=https://code.google.com/archive/p/browsersec/wikis/Part1.wiki|website=code.google.com|access-date=2020-09-05}}</ref><ref>{{Cite web|title=276813 - [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1|url=https://bugzilla.mozilla.org/show_bug.cgi?id=276813|website=bugzilla.mozilla.org|language=en|access-date=2020-09-05}}</ref>
== Contoh sesi ==
Di bawah ini adalah contoh percakapan antara klien HTTP dan server HTTP yang berjalan di [[www.example.com]], port 80.
=== Permintaan klien ===
<syntaxhighlight lang="http">
GET / HTTP/1.1
Host: www.example.com
</syntaxhighlight>Permintaan klien (terdiri dalam kasus ini dari garis permintaan dan hanya satu bidang tajuk) diikuti oleh garis kosong, sehingga permintaan berakhir dengan dua baris baru, masing-masing dalam bentuk [[carriage return]] diikuti oleh [[Garis baru|umpan baris]]. Bidang "Host" membedakan antara berbagai nama [[DNS]] yang berbagi [[alamat IP]] tunggal, yang memungkinkan [[hosting virtual]] berbasis nama. Sementara opsional dalam HTTP/1.0, itu wajib di HTTP/1.1. ("/" Berarti /index.html jika ada.)
=== Respon server ===
<syntaxhighlight lang="http">
HTTP/1.1 200 OK
Date: Mon, 23 May 2005 22:38:34 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 155
Last-Modified: Wed, 08 Jan 2003 23:11:55 GMT
Server: Apache/1.3.3.7 (Unix) (Red-Hat/Linux)
ETag: "3f80f-1b6-3e1cb03b"
Accept-Ranges: bytes
Connection: close
<html>
<head>
<title>An Example Page</title>
</head>
<body>
<p>Hello World, this is a very simple HTML document.</p>
</body>
</html>
</syntaxhighlight>Bidang header [[HTTP ETag|ETag]] (tag entitas) digunakan untuk menentukan apakah versi cache dari sumber daya yang diminta identik dengan versi sumber daya saat ini di server. ''Content-Type'' menentukan [[Tipe media|jenis media Internet]] dari data yang disampaikan oleh pesan HTTP, sementara ''Content-Length'' menunjukkan panjangnya dalam byte. [[Server web]] HTTP / 1.1 menerbitkan kemampuannya untuk menanggapi permintaan untuk rentang bita tertentu dari dokumen dengan mengatur bidang ''Accept-Ranges: bytes''. Ini berguna, jika klien hanya perlu memiliki porsi tertentu<ref>{{cite IETF|draft=draft-ietf-http-range-retrieval-00|title=Byte Range Retrieval Extension to HTTP|first1=Ari|last1=Luotonen|first2=John|last2=Franks|publisher=IETF|date=February 22, 1996}}</ref> dari sumber daya yang dikirim oleh server, yang disebut [[byte serving]]. Ketika ''Connection: close'' dikirim, itu berarti bahwa [[server web]] akan menutup koneksi [[TCP]] segera setelah transfer tanggapan ini.
Sebagian besar baris header adalah opsional. Ketika ''Content-Length'' menghilang panjang ditentukan dengan cara lain. Pengkodean transfer chunked menggunakan ukuran chunk 0 untuk menandai akhir konten. Pengodean ''identitas'' tanpa ''Content-Length'' membaca konten sampai soket ditutup.
''Content-Encoding'' seperti ''[[gzip]]'' dapat digunakan untuk mengompresi data yang dikirimkan.
== Protokol serupa ==
* [[Gopher (protokol)|Protokol Gopher]] adalah protokol pengiriman konten yang digantikan oleh HTTP pada awal 1990-an.
* Protokol [[SPDY]] adalah alternatif untuk HTTP yang dikembangkan di [[Google]], digantikan oleh [[HTTP/2]].
== Lihat pula ==
* [[Fiddler (perangkat lunak)]]
* [[Kompresi HTTP]]
* [[Daftar kode status HTTP]]
* [[Objek varian]]
* [[Temblok web]]
* [[WebSocket]]
* [[Wireshark]]
== Referensi ==
{{reflist}}
== Pranala luar ==
{{Commons category|Protokol Transfer Hiperteks}}
*"[https://www.w3.org/Protocols/History.html Change History for HTTP]". Sejarah teknis rinci HTTP.
*"[https://www.w3.org/Protocols/DesignIssues.html Design Issues for HTTP]". Masalah Desain oleh Berners-Lee ketika dia merancang protokol.
*[http://www.indowebspace.com Pembelian domain]
*"[https://www.w3.org/Protocols/Classic.html Classic HTTP Documents]".daftar dokumen klasik lainnya yang menceritakan sejarah protokol awal
*[https://www.w3.org/Protocols/HTTP/AsImplemented.html HTTP 0.9 – Sebagaimana Diterapkan pada 1991]{{Authority control}}
[[Kategori:Protokol Internet]]
[[Kategori:Protokol Transfer Hiperteks]]
[[Kategori:World Wide Web]]
[[Kategori:Protokol lapisan aplikasi]]
[[Kategori:Standar Konsorsium World Wide Web]]
[[Kategori:Protokol jaringan]]
| 