Wikipedia

Protokol Transfer Hiperteks

sistem pertukaran pesan antar sistem komputer
(Dialihkan dari CONNECT (HTTP))

Protokol Transfer Hiperteks (bahasa Inggris: Hypertext Transfer Protocol, disingkat HTTP) adalah protokol pada lapisan aplikasi untuk sistem informasi hypermedia yang terdistribusi dan kolaboratif.[1] 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.

Protokol Transfer Hiperteks
Standar internasionalRFC 1945 HTTP/1.0 (1996)

RFC 2616 HTTP/1.1 (1999)
RFC 7540 HTTP/2 (2015)
RFC 7541 Kompresi Header (2, 2015)
RFC 7230 Pesan sintaks dan Routing (1.1, 2014)
RFC 7231 Semantik dan Konten (1.1, 2014)
RFC 7232 Permintaan Bersyarat (1.1, 2014)
RFC 7233 Rentang Permintaan (1.1, 2014)
RFC 7234 Caching (1.1, 2014)

RFC 7235 Autentikasi (1.1, 2014)
Dikembangkan olehMulanya CERN; IETF, W3C
Diperkenalkan1991; 33 tahun lalu (1991)

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[2] dan server web utama melalui Transport Layer Security (TLS) menggunakan ekstensi Application-Layer Protocol Negotiation (ALPN)[3] di mana diperlukan TLS 1.2 atau yang lebih baru.[4]

HTTP/3 adalah penerus yang diusulkan untuk HTTP/2,[5] yang sudah digunakan di web, menggunakan 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,[6] dan dapat diaktifkan di versi stabil Chrome dan Firefox.[7]

Gambaran teknikal

sunting

HTTP berfungsi sebagai protokol permintaan-respons dalam model komputasi klien-server. Peramban web, misalnya, mungkin klien dan aplikasi yang berjalan di komputer yang meng-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 cache web yang mengirimkan konten atas nama 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 HTTP diidentifikasi dan ditempatkan di jaringan oleh Uniform Resource Locators (URL), menggunakan skema http dan https 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

sunting
 
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.[8] Respons dari server selalu berupa halaman HTML.[9]

Versi HTTP terdokumentasi pertama adalah 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.[10] RFC 1945 secara resmi memperkenalkan dan mengakui HTTP V1.0 pada tahun 1996.

Pada tahun 2007, 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:

  • RFC 7230, HTTP/1.1: Sintaks dan Routing Pesan
  • 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: Autentikasi

HTTP/2 diterbitkan sebagai RFC 7540 pada Mei 2015.

Tahun Versi HTTP
1991 0.9
1996 1.0
1997 1.1
2015 2.0
2018 3.0

Sesi HTTP

sunting

Sesi HTTP adalah urutan transaksi respons-permintaan jaringan. Klien HTTP memulai permintaan dengan membuat koneksi Transmission Control Protocol (TCP) ke 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.[1]

Koneksi persisten

sunting

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 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 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

sunting

HTTP adalah stateless protocol. Stateless protocol tidak memerlukan server HTTP untuk menyimpan informasi atau status tentang setiap pengguna selama beberapa permintaan. Namun, beberapa aplikasi web menerapkan independen atau sesi sisi server semenggunakan misalnya cookie HTTP atau variabel tersembunyi dalam formulir web.

Autentikasi HTTP

sunting

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.[11]

Alam autentikasi

sunting

Spesifikasi Otentikasi HTTP juga menyediakan konstruksi sewenang-wenang, spesifik implementasi untuk membagi lebih lanjut sumber daya yang umum untuk 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.[11] bocor

Format pesan

sunting

Klien mengirim permintaan ke server dan server mengirim tanggapan.

Permintaan pesan

sunting
 
Permintaan HTTP 1.1 dibuat menggunakan telnet. Pesan permintaan, bagian tajuk 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 /images/logo.png dari server)
  • bidang tajuk permintaan (mis., Bahasa Terima: id)
  • garis kosong
  • 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 spasi putih lainnya.[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[12]

Metode permintaan

sunting

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[13] mendefinisikan metode GET, HEAD dan POST dan spesifikasi HTTP/1.1[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". W3C telah menerbitkan prinsip panduan mengenai perbedaan ini dengan menyatakan, "desain aplikasi web harus mematuhi prinsip di atas, serta batasan sejenis."[14]
POST
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.[1]
PUT
Metode PUT meminta entitas terlampir disimpan di bawah 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.[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
[1] Metode CONNECT mengubah koneksi permintaan ke terowongan TCP / IP transparan, biasanya untuk memfasilitasi komunikasi terenkripsi SSL (HTTPS) melalui proxy HTTP yang tidak terenkripsi.[15] Lihat metode HTTP CONNECT.
PATCH
Metode PATCH menerapkan modifikasi parsial ke sumber daya.[16]

Semua server HTTP tujuan umum wajib menerapkan setidaknya metode GET dan HEAD, dan semua metode lain dianggap opsional oleh spesifikasi.[1]

Keamanan
sunting

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.[17] Microsoft IIS mendukung metode "TRACK", yang berperilaku sama, dan yang juga direkomendasikan untuk dinonaktifkan.[17]

Keamanan dari metode HTTP
Metode HTTP RFC Permintaan memiliki body Respons memiliki body Aman Idempoten Cacheable
GET RFC 7231 Optional Ya Ya Ya Ya
HEAD RFC 7231 Optional Tidak Ya Ya Ya
POST RFC 7231 Ya Ya Tidak Tidak Ya
PUT RFC 7231 Ya Ya Tidak Ya Tidak
DELETE RFC 7231 Optional Ya Tidak Ya Tidak
CONNECT RFC 7231 Optional Ya Tidak Tidak Tidak
OPTIONS RFC 7231 Optional Ya Ya Ya Tidak
TRACE RFC 7231 Tidak Ya Ya Ya Tidak
PATCH RFC 5789 Ya Ya Tidak Tidak Tidak

Respon pesan

sunting

Pesan respons terdiri dari berikut ini:

  • baris status yang mencakup kode status dan pesan alasan (e.g., HTTP/1.1 200 OK, yang mengindikasikan bahwa permintaan klien berhasil)
  • bidang header respons (mis., Content-Type: text/html)
  • Sebuah garis kosong
  • Sebuah 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 spasi putih lainnya.[18] Persyaratan ketat ini untuk <CR><LF> adalah berelaksi dalam badan pesan untuk penggunaan konsisten dari linebreak sistem lain seperti <CR> atau <LF> saja.[19]

Kode status

sunting
Lihat pula: 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 "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.[20]

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 1XX
  • Berhasil 2XX
  • Pengalihan 3XX
  • Klien Error 4XX
  • Server Error 5XX

Koneksi terenkripsi

sunting

Cara paling populer untuk membangun koneksi HTTP terenkripsi adalah HTTPS.[21] 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.[22][23]

Contoh sesi

sunting

Di bawah ini adalah contoh percakapan antara klien HTTP dan server HTTP yang berjalan di www.example.com, port 80.

Permintaan klien

sunting 
GET / HTTP/1.1
Host: www.example.com

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 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

sunting 
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>

Bidang header 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 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[24] 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

sunting
  • 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

sunting

Referensi

sunting
  1. ^ a b c d e f g h Leach, Paul J.; Berners-Lee, Tim; Mogul, Jeffrey C.; Masinter, Larry; Fielding, Roy T.; Gettys, James. "Hypertext Transfer Protocol -- HTTP/1.1". tools.ietf.org (dalam bahasa Inggris). Diakses tanggal 2020-06-23. 
  2. ^ "Can I use... Support tables for HTML5, CSS3, etc". caniuse.com. Diakses tanggal 2020-06-23. 
  3. ^ Friedl, Stephan; Langley, Adam; Popov, Andrey. "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension". tools.ietf.org (dalam bahasa Inggris). Diakses tanggal 2020-06-23. 
  4. ^ Belshe, M.; Peon, R.; Thomson, M. (2015-05-30). "Hypertext Transfer Protocol Version 2 (HTTP/2)". http2.github.io (dalam bahasa Inggris). Diarsipkan dari versi asli tanggal 2013-07-15. Diakses tanggal 2020-06-23. 
  5. ^ Bishop <mbishop@evequefou.be>, Mike. "Hypertext Transfer Protocol Version 3 (HTTP/3)". tools.ietf.org (dalam bahasa Inggris). Diakses tanggal 2020-06-23. 
  6. ^ Cimpanu, Catalin. "Cloudflare, Google Chrome, and Firefox add HTTP/3 support". ZDNet (dalam bahasa Inggris). Diakses tanggal 2020-06-23. 
  7. ^ "Firefox Nightly supports HTTP 3". Cloudflare Community (dalam bahasa Inggris). 2019-11-06. Diarsipkan dari versi asli tanggal 2020-06-06. Diakses tanggal 2020-06-23. 
  8. ^ Berners-Lee, Tim. "HyperText Transfer Protocol". World Wide Web Consortium. Diakses tanggal 31 August 2010. 
  9. ^ Tim Berners-Lee. "The Original HTTP as defined in 1991". World Wide Web Consortium. Diakses tanggal 24 July 2010. 
  10. ^ "HTTP Working Group". www.w3.org. Diakses tanggal 2020-06-23. 
  11. ^ a b Reschke, Julian F.; Fielding, Roy T. "Hypertext Transfer Protocol (HTTP/1.1): Authentication". tools.ietf.org (dalam bahasa Inggris). Diakses tanggal 2020-06-23. 
  12. ^ "Apache Week. HTTP/1.1". www.apacheweek.com. Diakses tanggal 2020-06-23. 
  13. ^ Nielsen, Henrik Frystyk; Berners-Lee, Tim; Fielding, Roy T. "Hypertext Transfer Protocol -- HTTP/1.0". tools.ietf.org (dalam bahasa Inggris). Diakses tanggal 2020-06-23. 
  14. ^ Jacobs, Ian (2004). "URIs, Addressability, and the use of HTTP GET and POST". Technical Architecture Group finding. W3C. Diakses tanggal 26 September 2010. 
  15. ^ ""Vulnerability Note VU#150227: HTTP proxy default configurations allow arbitrary TCP connections"". www.kb.cert.org. Diakses tanggal 2020-06-23. 
  16. ^ Dusseault, Lisa; Snell, James M. "RFC 5789: PATCH Method for HTTP". 
  17. ^ a b "Cross Site Tracing". OWASP. Diakses tanggal 2016-06-22. 
  18. ^ Kesalahan pengutipan: Tag <ref> tidak sah; tidak ditemukan teks untuk ref bernama ietf2616sec4
  19. ^ "Canonicalization and Text Defaults". RFC 2616. sec. 3.7.1. doi:10.17487/RFC2616. RFC 2616. https://tools.ietf.org/html/rfc2616#section-3.7.1. 
  20. ^ "Status-Line". RFC 2616. p. 39. sec. 6.1. doi:10.17487/RFC2616. RFC 2616. https://tools.ietf.org/html/rfc2616#section-6.1. 
  21. ^ "Canavan, John (2001). Fundamentals of Networking Security. Norwood, MA: Artech House. pp. 82–83". Wikipedia (dalam bahasa Inggris). 
  22. ^ ""Browser Security Handbook"". code.google.com. Diakses tanggal 2020-09-05. 
  23. ^ "276813 - [RFE] Support RFC 2817 / TLS Upgrade for HTTP 1.1". bugzilla.mozilla.org (dalam bahasa Inggris). Diakses tanggal 2020-09-05. 
  24. ^ Luotonen, Ari; Franks, John (February 22, 1996). Byte Range Retrieval Extension to HTTP. IETF. I-D draft-ietf-http-range-retrieval-00. https://tools.ietf.org/html/draft-ietf-http-range-retrieval-00. 

Pranala luar

sunting
 
Wikimedia Commons memiliki media mengenai Protokol Transfer Hiperteks.
Diperoleh dari "https://id.wikipedia.org/w/index.php?title=Protokol_Transfer_Hiperteks&oldid=26640586#Metode_permintaan"