Lihat sumber Protokol Transfer Hiperteks

[[File:HTTP_logo.svg|thumb|right|280px|HTTP logo]]

'''Protokol Transfer Hiperteks''' (, disingkat '''HTTP''') adalah [[protokol aplikasi|protokol pada lapisan aplikasi]] untuk [[sistem informasi]] hypermedia yang terdistribusi dan kolaboratif.<ref>Paul J. Leach. [https://tools.ietf.org/html/rfc2616.html Hypertext Transfer Protocol -- HTTP/1.1]. ''tools.ietf.org''.</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 2030 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>[https://caniuse.com/#search=http2 Can I use... Support tables for HTML5, CSS3, etc]. ''caniuse.com''.</ref> dan server web utama melalui [[Transport Layer Security]] (TLS) menggunakan ekstensi [[Application-Layer Protocol Negotiation]] (ALPN)<ref>Stephan Friedl. [https://tools.ietf.org/html/rfc7301.html Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension]. ''tools.ietf.org''.</ref> di mana diperlukan [[Transport Layer Security|TLS 1.2]] atau yang lebih baru.<ref>M. Belshe. [https://http2.github.io/http2-spec/#TLSUsage Hypertext Transfer Protocol Version 2 (HTTP/2)]. ''http2.github.io''. 2015-05-30.</ref>

[[HTTP/3]] adalah penerus yang diusulkan untuk HTTP/2,<ref>Mike Bishop. [https://tools.ietf.org/html/draft-ietf-quic-http-22.html Hypertext Transfer Protocol Version 3 (HTTP/3)]. ''tools.ietf.org''.</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>Catalin Cimpanu. [https://www.zdnet.com/article/cloudflare-google-chrome-and-firefox-add-http3-support/ Cloudflare, Google Chrome, and Firefox add HTTP/3 support]. ''ZDNet''.</ref> dan dapat diaktifkan di versi stabil Chrome dan [[Firefox]].<ref>[https://community.cloudflare.com/t/firefox-nightly-supports-http-3/127778 Firefox Nightly supports HTTP 3]. ''Cloudflare Community''. 2019-11-06.</ref>

== Gambaran teknikal ==
HTTP berfungsi sebagai protokol [[permintaan-respon]]s 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 ==
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>Tim Berners-Lee. [https://www.w3.org/History/19921103-hypertext/hypertext/WWW/Protocols/HTTP.html HyperText Transfer Protocol]. World Wide Web Consortium.</ref> Respons dari server selalu berupa halaman HTML.<ref>Tim Berners-Lee. [https://www.w3.org/Protocols/HTTP/AsImplemented.html The Original HTTP as defined in 1991]. World Wide Web Consortium.</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>[https://www.w3.org/Arena/webworld/httpwgcharter.html HTTP Working Group]. ''www.w3.org''.</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:

* , ''HTTP/1.1: Sintaks dan Routing Pesan''
* , ''HTTP/1.1: Semantik dan Konten''
* , ''HTTP/1.1: Permintaan Bersyarat''
* , ''HTTP/1.1: Rentang Permintaan''
* , ''HTTP/1.1: Caching''
* , ''HTTP/1.1: Autentikasi''

[[HTTP/2]] diterbitkan sebagai  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>Paul J. Leach. [https://tools.ietf.org/html/rfc2616.html Hypertext Transfer Protocol -- HTTP/1.1]. ''tools.ietf.org''.</ref>

=== 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>Julian F. Reschke. [https://tools.ietf.org/html/rfc7235.html Hypertext Transfer Protocol (HTTP/1.1): Authentication]. ''tools.ietf.org''.</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>Julian F. Reschke. [https://tools.ietf.org/html/rfc7235.html Hypertext Transfer Protocol (HTTP/1.1): Authentication]. ''tools.ietf.org''.</ref> bocor

== Format pesan ==
Klien mengirim '''permintaan''' ke server dan server mengirim '''tanggapan'''.

=== Permintaan pesan ===
Pesan permintaan terdiri dari:

* baris permintaan (mis., ''GET /images/logo.png HTTP / 1.1'', yang meminta sumber daya yang disebut  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>Paul J. Leach. [https://tools.ietf.org/html/rfc2616.html Hypertext Transfer Protocol -- HTTP/1.1]. ''tools.ietf.org''.</ref> 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>[http://www.apacheweek.com/features/http11.html Apache Week. HTTP/1.1]. ''www.apacheweek.com''.</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. Sering kali, sumber daya berhubungan dengan file atau output dari executable yang berada di server. Spesifikasi HTTP/1.0<ref>Henrik Frystyk Nielsen. [https://tools.ietf.org/html/rfc1945.html Hypertext Transfer Protocol -- HTTP/1.0]. ''tools.ietf.org''.</ref> mendefinisikan metode GET, HEAD dan POST dan spesifikasi HTTP/1.1<ref>Paul J. Leach. [https://tools.ietf.org/html/rfc2616.html Hypertext Transfer Protocol -- HTTP/1.1]. ''tools.ietf.org''.</ref> 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>Ian Jacobs. [http://www.w3.org/2001/tag/doc/whenToUseGet.html#checklist URIs, Addressability, and the use of HTTP GET and POST]. ''Technical Architecture Group finding''. W3C. 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>Paul J. Leach. [https://tools.ietf.org/html/rfc2616.html Hypertext Transfer Protocol -- HTTP/1.1]. ''tools.ietf.org''.</ref>
; 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>Paul J. Leach. [https://tools.ietf.org/html/rfc2616.html Hypertext Transfer Protocol -- HTTP/1.1]. ''tools.ietf.org''.</ref>
; 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>Paul J. Leach. [https://tools.ietf.org/html/rfc2616.html Hypertext Transfer Protocol -- HTTP/1.1]. ''tools.ietf.org''.</ref> 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>[https://www.kb.cert.org/vuls/id/150227 "Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections"]. ''www.kb.cert.org''.</ref> Lihat [[Terowongan HTTP#Metode HTTP CONNECT|metode HTTP CONNECT]].
; PATCH:Metode PATCH menerapkan modifikasi parsial ke sumber daya.<ref>Lisa Dusseault. [http://tools.ietf.org/html/rfc5789 RFC 5789: PATCH Method for HTTP].</ref>

Semua server HTTP tujuan umum wajib menerapkan setidaknya metode GET dan HEAD, dan semua metode lain dianggap opsional oleh spesifikasi.<ref>Paul J. Leach. [https://tools.ietf.org/html/rfc2616.html Hypertext Transfer Protocol -- HTTP/1.1]. ''tools.ietf.org''.</ref>

===== 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>[https://www.owasp.org/index.php/Cross_Site_Tracing Cross Site Tracing]. OWASP.</ref> Microsoft [[IIS]] mendukung metode "TRACK", yang berperilaku sama, dan yang juga direkomendasikan untuk dinonaktifkan.<ref>[https://www.owasp.org/index.php/Cross_Site_Tracing Cross Site Tracing]. OWASP.</ref>
{| 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
| 
| 
| 
| 
| 
| 
|-
!scope="row"| HEAD
| 
| 
| 
| 
| 
| 
|-
!scope="row"| POST
| 
| 
| 
| 
| 
| 
|-
!scope="row"| PUT
| 
| 
| 
| 
| 
| 
|-
!scope="row"| DELETE
| 
| 
| 
| 
| 
| 
|-
!scope="row"| CONNECT
| 
| 
| 
| 
| 
| 
|-
!scope="row"| OPTIONS
| 
| 
| 
| 
| 
| 
|-
!scope="row"| TRACE
| 
| 
| 
| 
| 
| 
|-
!scope="row"| PATCH
| 
| 
| 
| 
| 
| 
|}

=== 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>[https://id.wikipedia.org/w/index.php?title=Protokol+Transfer+Hiperteks&oldid=29509051 sumber pada Wikipedia bahasa Indonesia]</ref> Persyaratan ketat ini untuk <CR><LF> adalah berelaksi dalam badan pesan untuk penggunaan konsisten dari linebreak sistem lain seperti <CR> atau <LF> saja.<ref>''RFC 2616''.</ref>

==== Kode status ====
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 frasa ''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>''RFC 2616''. hlm. 39.</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>[https://en.wikipedia.org/wiki/Special:BookSources/9781580531764 Canavan, John (2001). Fundamentals of Networking Security. Norwood, MA: Artech House. pp. 82–83]. ''Wikipedia''.</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>[https://code.google.com/archive/p/browsersec/wikis/Part1.wiki "Browser Security Handbook"]. ''code.google.com''.</ref><ref>[https://bugzilla.mozilla.org/show_bug.cgi?id=276813 276813 - [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1]. ''bugzilla.mozilla.org''.</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>Ari Luotonen. ''Byte Range Retrieval Extension to HTTP''. IETF. 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]]

== Pranala luar ==
*"[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.
*"[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]

== Referensi ==
<references />

== Sumber dan atribusi ==

Konten artikel ini diadaptasi dari [https://id.wikipedia.org/w/index.php?title=Protokol+Transfer+Hiperteks&oldid=29509051 Wikipedia bahasa Indonesia], revisi 29509051 (2026-07-31T08:47:21Z), yang tersedia berdasarkan lisensi Creative Commons Atribusi-BerbagiSerupa (CC BY-SA). Gambar pada artikel ini bersumber dari Wikimedia Commons dan mengikuti ketentuan lisensi masing-masing berkas. Mohon gunakan konten dan media secara bijak serta sesuai dengan ketentuan lisensi yang berlaku.

<!-- WIKI_UNISSULA_PRESENTATION_V4 -->