Ngobrolin HTTP
Ringkasan Episode
Bantu KoreksiTopik ini muncul dari kejadian nyata: sebuah situs yang baru dipasang selalu dialihkan ke HTTPS, padahal tidak ada pengaturan Nginx apa pun yang menyuruhnya. Penyebabnya ternyata domain berakhiran .dev yang memang memaksakan HTTPS di tingkat browser. Dari situ obrolannya melebar ke HTTP itu sendiri, sekaligus keheranan bahwa hal sedasar ini jarang benar-benar diajarkan di kampus. Sejarahnya ditelusuri dari HTTP 0.9 yang luar biasa sederhana: hanya ada GET, tidak ada header, tidak ada status code, tidak ada penanganan galat. Server menjawab dengan HTML, lalu koneksinya langsung ditutup. Saat itu belum ada browser sama sekali — permintaan dikirim lewat Telnet, perkakas serbaguna yang bisa berbicara dengan protokol apa pun lewat port yang sesuai, dari SMTP di port 25 sampai IMAP. Protokolnya sendiri lahir di CERN dan berjalan di atas TCP, sementara HTTP/3 belakangan pindah ke UDP. HTTP 1.0 dan 1.1 menambahkan hampir semua yang kita kenal: nomor versi, status code, tipe konten yang diminta dan diberikan, kompresi gzip, caching, unggahan berkas, dan keep-alive agar koneksinya tidak langsung ditutup. Yang menarik justru pengamatan di sela-selanya — membangun protokol seperti ini bukan soal menulis kode melainkan menyusun RFC dan mengambil keputusan lebih dulu, karena semua pihak harus sepakat sebelum ada yang mengimplementasikan. Ada pula saran keamanan kecil tapi praktis: jangan bocorkan identitas web server di header respons. Ditutup dengan kenyataan bahwa banyak situs besar sudah berjalan di HTTP/2 bahkan HTTP/3 di balik Cloudflare tanpa kita sadari.
Poin-poin Utama
- •Domain berakhiran .dev memaksakan HTTPS di tingkat browser, sehingga situs bisa selalu dialihkan tanpa pengaturan Nginx apa pun
- •HTTP 0.9 luar biasa sederhana: hanya GET, tanpa header, tanpa status code, dan koneksinya langsung ditutup setelah dijawab
- •Saat itu belum ada browser — permintaan dikirim lewat Telnet, yang bisa berbicara dengan protokol apa pun lewat port yang sesuai seperti SMTP di port 25
- •Protokolnya lahir di CERN dan berjalan di atas TCP, sementara HTTP/3 belakangan pindah ke UDP
- •HTTP 1.0 dan 1.1 menambahkan status code, tipe konten, kompresi gzip, caching, unggahan berkas, dan keep-alive
- •Membangun protokol semacam ini bukan soal menulis kode melainkan menyusun RFC lebih dulu, karena semua pihak harus sepakat sebelum ada yang mengimplementasikan
- •Saran keamanan kecil tapi praktis: jangan bocorkan identitas web server di header respons, atau sekalian isi dengan yang mengecoh
Hai, hai, hai. Selamat malam.
Halo semuanya, gimana kabarnya?
Loh, kok cuman berdua? Satu lagi mana?
Menyusul, menyusul.
Menyusul ya, Eka akan segera menyusul, tenang aja.
Kita masih formasi lengkap malam hari ini. Seperti biasa, hari ini adalah hari Selasa,
jadi saatnya kita untuk ngobrolin.
Ngobrolin, wey.
Setelah minggu lalu kita tidak live, malam hari ini kita live lagi.
Minggu lalu itu bahasan tentang Wasm kita rekam di hari Sabtu ya.
Eka menuju luar kota.
Luar negeri.
Luar kota dulu.
Oh iya luar kota dulu, betul-betul.
Ngurusin visa ya, ngurusin visa.
Ups, gak boleh disebutin ya.
Spoiler, ini spoiler.
Sekarang Eka aja dimana.
Mudah-mudahan setelah waktu Eka nya balik, nanti kita dapat banyak ilmu baru.
Oh iya, harus dong.
Mudah-mudahan di sana juga bisa live. Gak bisa ya, susah ya.
Just itu di sana bisa kali.
Pagi?
Pagi.
Lagi kegiatan kali, mungkin sehari sebelum acara atau setelah acara.
Kebayang sih, ah udah biarin aja.
Biar Eka nya nanti, biar banyak dapat insight yang baru.
Iya, pertama kali ya.
Kita Eka nya nanti malah ngomongin Eka, loh live lagi.
Sengaja, sengaja sih.
Lihat transkrip lengkap (2181 segmen lagi)
Oke, sebelum kita lebih gosipin teman-teman yang lain.
Gimana kabarnya teman-teman semuanya?
Boleh dong, absen-absen dulu di kolom komentar buat yang sudah hadir.
Sambil menunggu.
Oh iya, kabar-kabarnya gimana, ada masalah apa di kantor?
Jangan masalah politik ya, masalah teknis.
Mungkin lagi ngadepin masalah, mungkin HTTP status yang membingungkan, misalkan.
Atau cerita-cerita juga dong dari 48 episode.
49 episode nya kita, apa yang sudah teman-teman lakukan?
Apa yang sudah teman-teman pernah uji coba?
Atau mungkin sudah implementasi langsung di production apa?
Cerita-cerita dong, jadi kita bisa bahas nanti.
Betul, betul.
Kisah sukses.
Kisah sukses, iya saya juga ngalamin tuh kan biasanya setiap Senin itu live streaming.
Beberapa bulan yang lalu itu, belajar bareng-bareng ini TypeScript.
Terus tiba-tiba ada yang message katanya dia implementasi TypeScript di kantor migrasi.
Wah senang banget gitu.
Gara-gara habis belajar, terus dia implementasi di kantor dan sukses gitu, kita senang banget gitu ya.
Jadi kalau teman-teman punya pengalaman gitu ya, wah gara-gara nonton ini saya jadi implementasi apa ya?
Performance ya, pakai apa, layout shiftnya jadi lebih bagus gara-gara insight dari beberapa episode yang lalu misalkan.
Iya.
Boleh ya, bagi-bagi cerita ya.
Kita pernah bahas tentang font, web component, image, service worker, autentikasi.
Banyak ya.
Fugu, nah kalau ada Fugu, nah kita pernah undang lagi itu bintang Talmu Superstar, Fugu.
Mas Tomas.
Mas Tomas.
Ada accessibility.
Accessibility.
SVG, Core Web Vital, module bundler, saya bacanya ini, kita pernah bahas ini ya gitu ya.
Iya, ternyata udah banyak juga ya.
Akhir itu web assembly yang lalu, nah ada ya bisa teman-teman sharing-sharing apa gitu.
Biar kita senang mendengar cerita-cerita teman-teman.
Uy, Audi, Audi ini penonton setia nih ya.
Pengen ajukan JavaScript sebabnya bahasa awal di kampus biara anak-anak baru belajar cara debug.
Apa hubungannya belajar JavaScript dengan cara debug?
Memang bahasa lain nggak ada debug.
Mungkin pakai debugger itu kali ya.
Lebih gampang ya pakai debugger ini ya.
Saya setuju sih JavaScript di awal kuliah, setuju sih, setuju banget gitu.
Karena kan barrier itu entry-nya lebih landai kan.
Bukan yang jadi, jadi ini, ini.
Oke kok kita jadi ngelatur ya?
Dua ini ya, ada dua kiblat lah ya.
Kan ada yang suka memulai dengan sesuatu yang sulit dulu.
Setelah itu belajarannya jadi gampang.
Ada yang mungkin overwhelmed.
Jadi dia harus belajar yang ringan-ringan dulu.
Nanti step by step, gradually naik ke level berikutnya.
Karena JavaScript itu tidak data, bukan type strict.
Bukan, dynamics.
Jadi nggak strict, typing data type-nya nggak strict.
Jadinya migrasi yang sudah data type-nya yang strict nanti bakal pusing.
Iya, mungkin ya, mungkin konsiderasinya adalah
karena ada mata kuliah yang berhubungan dengan tipe data dan struktur data.
Kalau ngomongin tipe data di JavaScript kayaknya nggak begitu relevan.
Karena kita bisa ngapain aja itu.
Jadi pakai type script itu pun kena dipaksa.
Iya betul.
Nah ini dia sudah datang.
Apa itu type script?
Kita lagi bahas ini.
Tadi kita bahas kamu loh.
Dari Audi.
Pengen JavaScript supaya bisa di awal kuliah, di awal kampus.
Dan ada dua opini.
Ada yang pengen belajar yang sulit dulu, belajar type language yang strict.
Ada yang seperti Audi, pengennya yang ringan dulu.
Jadi biar data entry-nya lebih rendah.
Tapi sebenarnya ngaduh ke apa sih, approach-nya nggak sih?
Kayak functional programming, object oriented.
Kalau dikasih JavaScript dulu, terus nanti pas belajar C++ atau Python,
apa, pusing nggak?
Setuju, setuju.
Itu insight yang menarik.
Karena JavaScript itu, sorry itu Shay, bahasanya banci.
Bisa kemana aja.
Mau functional, bisa.
Mau OOP, bisa.
Bisa dia.
Multi-purpose.
Karena sejarahnya emang harus flexible.
Emang harus flexible.
Jadi kalau dipetakan ke mata kuliah itu agak sulit.
Karena functional programming belum diajarkan sampai sejauh ini,
selama ini yang saya tahu belum diajarkan di kampus.
Kampus itu baru sampai di prosedural sama OOP.
Cuma orang kuliah itu sebenarnya luas banget nggak sih?
Maksud saya kan dunia IT gitu atau computer science itu kan banyak banget.
Orang web buat doang aja bisa macem-macem banget.
Apalagi computer science kan.
Atau ini yang lebih spicy.
Nggak spicy sih cuma perspektif lain.
Dikasih sejarahnya sama kayak prinsip-prinsip umumnya.
Kayak satu semester lah gitu.
Nggak usah coding dulu.
Tapi ya mungkin kayak binary, prinsip-prinsipnya.
Jadi kayak control flow, kondisional atau apa.
Terus habis itu penjurusan deh.
Jadi ada jurusan apa ya.
Pengelompokan entah apalah nggak tahu.
Ada yang mau larinya ke JavaScript, TypeScript.
Ya udah JavaScript duluan.
Pengelompokan jurusan satunya nih.
Ya kayak mulai dari Titan, C++.
Terus apalah infra atau networking.
Nggak ada yang mau.
Masih berhubungan juga nanti ke data store.
Kalau misalnya dia masih pakai relasional, itu kan strict.
Type nya itu kan harus strict ya.
Kalau pakai relasional kan.
Kalau pakai yang object relasional, ORM, beda lagi kan.
Yang dipopulerkan MongoDB dan Firebase.
Mungkin ya kalau uno SQL, ya itu bisa dipelajari sambil jalan sih.
Maksudnya kayaknya lebih sensible kalau bahasa pengantar awalnya itu Python.
Karena kan awalnya kita dijarin shadow code kan.
Dari shadow code ke Python kan udah deket kan.
Dekat sekali kan. Nggak juga.
Dan Python lebih jati diri.
Dari aliran C++.
Beda.
Kan kalau ngomongin bahasa pemograma itu sama kayak ngomongin agama.
Nggak abis-abis.
Di kiri dan kanan.
Tujuan nya satu dong.
Tujuan nya sama padahal ya.
Cuman udah sama agama ya.
Bisa lebih banyak sekaligus.
Ya dibandingkan dia pasti kayaknya Python lebih punya jati diri.
Dia udah OP gitu kan.
Nggak setengah-setengah gitu.
Dan bahasanya juga bahasa Inggris.
Maksudnya secara sintaksnya.
Tapi ya balik lagi tergantung.
Menurut saya sih selama olimpiade komputer.
Masih menggunakan paskal C++.
Itu di kampus nggak bakal berhenti melakukan itu.
Karena dari SMP SMA itu udah olimpiade komputernya kan bahasanya itu kan.
Iya.
Jadi yang inggris dibunuhnya sebenarnya sebelum itu.
Iya sebelum itu.
Cuma kelebihan/kekurangan nggak kuliah yang berhubungan sama IT.
Bisa langsung.
Nggak bisa C++ dan Python ya.
Udah nulis JavaScript sama TypeScript.
Sekarang kalau udah teranjur kerja sebagai webdev atau bikin agensi.
Masa ada orang yang segitu isengnya bisa Python nggak?
Cuma akhirnya sempat belajar sendiri Python sedikit.
Cuma pengen tahu aja kalau suatu hari kepepet harus bisa.
Bisa bakal bisa atau nggak.
Jadi cuma declare variable-nya begini.
Kalau bikin loop gini.
Kondisional gini.
Operasinya kira-kira gini.
Ya udah, abis itu nggak lanjut.
Cuma kalau kapan-kapan entah kenapa kepepet harus bisa, ya udahlah.
Nanti dipikir lagi.
Oke, mantap. Terima kasih Audi.
Gara-gara Audi kita jadi ngelantur ke mana-mana.
Anyway malam hari ini kita membahas tentang salah satu topik fundamental ya.
Basic, sangat dasar sekali.
Nah ini juga harus tahu ya.
Orang tulis ya jahil nggak ya ini?
Nggak, saya dulu nggak dapet.
Nggak.
Dulu nggak sampai bikin server ya.
Kalau bootcamp apa ya?
Misalnya kayak ya web dev jelas.
Terus dev ops ya harus ngerti kan nih.
Betul.
Minimal harus tahu jalur, alur dari request.
Ketika si user ketik domain itu si server-nya ngapain?
Kan standarnya kan request terus diproses jadi response kan baliknya.
Itu minimal gitu.
Tapi kayaknya dulu waktu pelajar pomograman web di kampus nggak diajarin HTTP.
Iya, HTTP protocol secara protocol diajarin ya.
HTTP, FTP, SMTP.
Itu diajarin.
Yang 7 oc layer kan?
Nah itu diajarin.
Tapi cara bikinnya, cara gimana caranya apa ya?
Gimana caranya kita melempar request dan melempar balik response itu nggak sampai sedetil itu sih.
Jadi hanya cara pakai saja.
Pakai telnet lah atau tools semacamnya.
Dulu sih kalau di kampus diajarin itu.
Nggak tahu nih, temen-temen yang kuliah mungkin bisa kasih pendapat.
Kuliah jaman now sudah ada topik tentang HTTP, lebih detail atau hanya kulitnya saja?
HTTP kepanjangannya apa ya?
Hypertext Transfer Protocol.
Lulus interview, oh nggak ya?
Emang ada yang nanya gitu ya?
Sebutkan kepanjangan HTTP, pakai pilihan lagi.
A, B, C, D.
Hypertext sih gampang ditebak, transfer-nya doang sih yang agak sulit.
Kalau P-nya protocol, ok lah itu juga bisa ditebak.
Ali, siapa tahu ada...
Ada yang belum tahu.
Nge-freeze.
Atau TP-nya gagal.
Atau TP-nya response-nya gagal.
Oke, aman.
Acek.
Kalau sekarang kan itunya pakai P.
Kalau nge-chat kan P.
Ping.
Itu P itu artinya apa ya?
Bisa pa, bisa ping, bisa punten.
Masa sih?
Bukan poi atau hoi gitu, poi.
Ini gara-gara BBM dulu, Blackberry Messenger.
Biasanya nge-ping-ping kan.
Dulu kalau BBM kan sejarahnya beneran ada feature ping kan ya?
Iya, kalau WhatsApp nggak ada, jangan ditambah-tambah fiturnya.
Jadi manual.
Oke, anyway.
Jadi kita malam hari ini akan membahas agak sedikit lebih detail tentang HTTP.
Dan tentunya HTTPS ya.
Dan kenapa penting, HTTPS itu penting.
Dan kenapa HTTPS mulai ditinggalkan, dalam dana kutip.
Kemudian kita lihat juga sejarahnya.
Jadi kita mulai dari sejarahnya. Tadi kita udah bahas tentang kepanjangannya.
Hypertext Transfer Protocol.
Kita mesti sign in dulu deh, itu sign in medium.
Coba deh, scroll ke bawah.
Kenapa? Harus sign up?
Enggak? Oh iya bener.
Oh tidak, berarti kita bukanya pakai incognito.
Sedikit cerita dulu, kenapa kita bisa bahas HTTP?
Mas Riza bingung.
Lo, kok website yang dibikinnya nggak bisa pakai HTTP ya?
Harus HTTPS.
Ada mau bikin demo aplikasi, demo in, deploy.
Tapi juga diplonya pakai SSL Certificate kan.
Jadi sebelum pakai SSL kan pakai HTTP dulu.
Begitu dibuka di browser yang modern, itu pada redirect semua ke HTTPS.
Gimana cara disable-nya juga udah dicobain disable.
Pakai flag apa, flag apa, nggak ngaruh.
Ternyata domain yang saya gunakan itu .dev.
Dan kalau .dev katanya itu otomatis redirect.
Padahal di Nginx saya nggak ada itu.
Enforce.
Enforce. Gitu, makanya langsung yuk kita bahas HTTP ini penting nih kayaknya.
Ya pas balik pas ceritanya udah selesai.
Oh iya dong. Kan udah tahu ceritanya selama weekend kemarin.
Ini ada nih, saya lupa entah saya yang bolos atau nggak ada di kampus.
Pantesan belum lulus, kamu kuliah dimana?
Nggak ada belajar HTTP ya. Oh kita harus nanyain ini ya, Pak Dika kali ya.
Pak Dika, kalau beliau mungkin ngajarin, nggak mungkin resminya nggak diajarin.
Tapi dia bikin video sendiri-sendirian.
Jadi menurutnya Pak Dika.
Betul, ada materi atau ada bahan ajar nggak buat HTTP.
Kalau nggak ada berarti ya.
Kalau Pak Dika saya yakin pasti ngajarin sih.
Cuman itu ada masuk ke kurikulum atau nggaknya yang pengen kita tahu ya.
Kurikulum default.
Gitu.
Nah, jadi HTTP ini lahir di tahun?
Nggak tahu kan.
Ini pertanyaan interview nih. 1991 ya.
Ya pas ada internet, ada website, harus ada protokolnya kan.
Dan itu saat itu masih pakai TCP ya saat itu ya.
Kalau sekarang apa?
Pokoknya masih one line doang.
Tapi kalau HTTP 3 beda lagi.
Oh UDP ya dia udah UDP ya?
Iya.
Koneksi pertamanya.
Bedanya TCP sama UDP?
Nanti kita bahas.
Nanti kita bahas, oke.
Jadi tadi udah tahu kepanjangannya HTTP adalah Hypertext Transfer Protocol dikembangkan oleh web developer ini.
Team Benar Steam, the real web developer.
Jadi dia yang bikin web.
Satu orang loh itu bukan satu team.
Bukan 3 orang ini, satu orang ya.
Namanya sih 3.
Tapi ini adalah satu sosok orang.
Dikembangkan di Labs namanya CERN.
Terus ini sekitar 8-9 sampai 9-1.
Mungkin teman-teman yang nonton belum pada lahir.
Terus HTTP adalah, oh iya, Eka udah?
Kita mah udah.
Kita mah udah.
Kita mah tua.
Kok kita?
HTTP Functions Request Response Protocol in the Client Server Computing Model.
Jadi kliennya adalah browser.
Servernya adalah web server.
Web server.
Tapi jaman itu belum ada browser ya.
Jaman itu belum ada browser, jadi kita request-nya pakai telnet.
Oh pakai telnet.
Belum ada churl juga.
Belum ada churl.
Jadi pakai telnet.
SSR.
SSR protocol juga.
Sejenis telnet lah jaman itu entah apa.
Iya. Protokol telnet itu adalah protokol klien untuk segala jenis protokol.
Klien untuk segala jenis protokol.
Dia interface doang.
Jadi mau kirim apa gitu.
Jadi kayak, kalau sekarang itu analoginya kayak apa ya?
Kayak Postman.
Tapi bukan hanya buat HTTP.
Bisa buat SSH.
Bisa buat FTP.
Bisa buat SMTP.
Pokoknya semua protokol yang ada di jaringan.
Apapun yang bisa dikirim dia cuma nyampein ya.
Iya dia pakai port.
Servernya mau terima atau enggak?
Lebih tepatnya dia IO interface.
IO interface, ya.
HTTP ini umumnya jalan di port 80 ya.
Jadi kalau teman-teman misalkan medium.com.280.
Yaitu adalah HTTP.
Kalau HTTPS 4 ke 3 kan.
Jadi nggak kelihatan di sini karena defaultnya.
Kecuali kalau misalkan localhost 3000.
Nah itu udah buatan sendiri kan.
Itu bebas ya dari kita.
Di atas 1000 sekian saya lupa.
Di bawah 1000 itu sudah diambil.
Sudah punya OS.
Oh nggak bisa dipakai ya?
Gak bisa.
Kalau kalau dipakai berantem.
Maksudnya kadang bakal ada yang pakai.
Kalau dipakai nanti ada aplikasi yang bakal gagal.
Yes.
Nah kita mulai dari HTTP 0.9.
One line protocol.
Jadi hanya ada satu baris.
Nah ini contoh Telnet tadi kita udah bahas ya.
Jadi Telnet ini adalah command line.
Yang bisa kita panggil seperti ini.
Kemudian kita kasih domainnya atau IP address-nya.
Alamat apapun ya. Mau domain, IP address.
Bisa IP, bisa TLD.
Bisa localhost juga.
Jaman motto dibikin ini kayaknya belum ada domain juga deh.
Belum ada DNS kalau nggak salah.
Belum ada.
Jadi masih pakai IP address.
Pake IP address, kemudian portnya.
Nah berhubungan HTTP adalah port 80.
Ya kita pakai port 80 di sini.
Terus berhasil connect.
Hand shaking istilahnya.
Salam kenal gitu ya. Salaman.
Terus abis itu kita bisa kirim request.
Requestnya jenisnya apa?
Ada get, post, put, update, delete?
Nggak.
Baru get doang tuh.
Kalau ini ya. Karena 0.9.
Terus kita mau request apanya?
Mau request halaman apa?
Kita minta page ya.
Kalau dulu kan istilahnya dokumen ya.
Kita mau request dokumen apa?
Itu. Udah tuh abis itu dari si ininya di response lah oleh si server dengan tech HTML.
Udah abis itu harus login ya.
Mediumnya.
Punya akun medium.
Ada sih.
Nah pindah, pindah window dulu.
Pindah window loginnya.
Sambil lihat ini.
Apa ya Samy?
Sambil lihat contoh dokumennya aja apa?
Boleh.
Kan apapun yang di web itu harus berdasarkan standar ya.
Spesifikasi.
Sambil share screen.
Udah share belum?
Sudah.
Nah ini yang HTTP 1.
Nah.
Ya kalau baca sebenarnya bosan sih.
Cuma dokumen yang jadi standar kira-kira bentuknya gini.
Jadi kalau temen-temen pengen lihat.
Sampai sekarang semua udah masih terdokumentasi rapih di website-nya.
Tadi IETF ini kan disebut juga ya di artikel tadi.
Abstratnya, tujuannya, terminologi.
Ya wah ini spesifikasinya begini ya.
Apa itu connection?
Jadi kalau, biar nggak rancu kan.
Message itu apa.
Bahkan request-response yang menarik aja sih.
Sampai sekarang banget kan kita juga masih pakai request-response ya.
Di web API itu di browser ada request object, ada response object.
Dan sekarang udah extended.
Sekarang kan ada worker ya.
Worker juga bisa ada kegiatan lah, ada manipulasi.
Misalnya kalau pakai service worker nih kita bisa manipulasi response ya.
Misalnya aslinya kan aslinya lagi offline.
Response-nya 404.
Bisa kita manipulasi.
Jadi 200 kita balikin jenis data yang kita setting sendiri.
Tapi itu semua sebenarnya kan berdasarkan prinsip request dan response object dari suatu HTTP request kan.
Sama HTTP response.
Ternyata ini udah dari tahun 90-an.
Resource, entity, blablabla.
Udah? Udah login?
Login menggunakan Twitter? Gak.
Ada yang bisa login.
Satu-satunya akan pakai Twitter soalnya.
Tapi tidak berhasil.
Bentar, coba dulu.
Oh, atau buka yang ini aja nih.
Buka yang kedua, buka yang kedua.
Yang ini.
Wait, gue stop sharing.
Yang dimana ya?
Online protocol. Tadi kita udah bahas telnet.
Terus kita get.
Hanya ada satu dulu ya.
Hanya bisa ngambil dokumen.
Sebutannya dokumen ya halaman itu.
Halaman HTML.
Terus ini adalah response-nya.
Response-nya dalam bentuk HTML.
Single line.
Ini kan port 80.
Kalau dia nanti...
Contohnya teman-teman mau...
Connect ke SMTP.
Nah itu nanti 4.
SMTP berapa?
443.
443 bukannya SSL?
Bukannya salah.
Bukan.
Bukannya SSL.
Sorry, sebelum gue salah ngomong.
Cari dulu, cari dulu.
SMTP port 25 atau 587.
Ah, 25.
Yang benar itu.
Kalau yang gue inget 143 itu IMAP.
IMAP.
Iya, IMAP juga.
Pop 3 110 995.
Kenapa saya sebut ini?
Intinya pakai Telnet.
Kalau kita connect ke SMTP.
Nah kita gunakan portnya 25.
Nanti muncul itu pesannya.
Hello, eh hello.
Kaya gitu.
ACK, something ya.
Nah ini.
Zoom in dikit deh.
Nah, mantap.
From this humble beginnings
in 1991,
HTTP took a life on its own
and evolved rapidly over coming years.
Let's quickly recap features of
HTTP 0.9.
Client server
Request Response Protocol.
ASCII protocol
running over TCP/IP.
Designed to transfer
hypertext document.
Dokumen HTML.
Sama ini tadi simpel banget kan.
Comma get.
Terus ga ada response error, ga ada header.
Headernya aja ga ada ya.
Ya udah dikasih aja langsung.
Dikasih aja HTML.
Begitu sudah terima response, langsung close.
Ga ada keep alive.
Ga ada web socket, ga ada macem-macem.
Jadi, sekali kirim,
selesai, bye bye.
Nanti kalau mau minta lagi, request lagi.
Buka lagi.
Kemudian masuk ke 1.0.
Ini di tahun 91-95.
Ini ya, ya digunakannya ya.
Ini adalah
Cooperation of HTML.
Ya, sudah mulai ada browser.
HTML specification.
A new breed of software
known as web browser.
Jadi web browser lahir
itu di tahun sekitar 91-95.
The emergence and quick growth
of the consumer-oriented
public internet infrastructure.
Jadi, kalau dulu internet itu
digunakan di kalangan terbatas.
Akademis ya biasanya.
Apa di kampus-kampus, militer.
Militer, yang terutama militer ya.
Pemerintahan.
Pemerintahan negara sana.
Mungkin, kayaknya kalau di kita belum ada deh.
Kita belum ada.
Amerika, Inggris.
Nah, teman-teman, mungkin bisa share juga
pengalaman berinternet pertama itu
kapan dan melakukan apa
di internet.
Kalau saya dulu email.
Gak tau bunyi modem.
Gak tau bunyi modem.
Telekom net instant ya.
Eh, nyebutin Merk ya.
Eh Merk.
Sebenernya dari tadi kepikiran itu
cuma nahan diri sih jinggulnya keci banget.
Sampai sekarang masih afal.
08.0.9.
Cukup, cukup, cukup.
Bip.
Dan ketika kita menggunakan internet
tiba-tiba, Mak, kita angkat telepon.
Ini suara apa, Wai?
Tiba-tiba tadi hand telponnya
langsung membengkak.
Membengkak, iya.
Padahal buat chatting doang ya.
Anyway, jadi
di tahun 91-95
mulai muncul satu software baru
yang namanya web browser
yang bisa mengkonsumsi
HTTP. Kita bisa request dari
HTTP, gak hanya dari Telnet lagi.
Ada klien baru
namanya web browser.
Web browser inilah yang bertugas
untuk
mentranslasi
HTML
menjadi dokumen yang bisa kita baca
oleh manusia, gitu ya. Kalo sebelumnya
agak susah ya
ngeliat tag-tag gitu ya.
Kan user kirim response
melalui web browser.
Jadi kita tinggal ngetik
URL atau IP yang mau
dituju, enter. Nah kan
si browser-nya menyampaikan
HTTP request itu tadi. Terus
terima response berupa misalnya
dokumen HTML.
Dia merender HTTP response
jadi UI.
Apa? Dirender di DOM.
Iya.
Nah, di HTTP 1
sekarang sudah mulai
nambah. Kalo tadi kan
hanya ada satu baris. Hanya ada satu baris
request dan response.
Eh, gak ya. Request. Hanya ada satu baris
request. Kalo sekarang
request-nya ada banyak nih. Yang pertama adalah
get.
Kemudian ini adalah dokumen yang kita
inginkan. Ini ada
versi dari HTTP-nya.
Yang masih dipakai sampai sekarang. Sekarang 1.1
yang default ya.
Kemudian ada user agent-nya.
Dan kemudian
iya.
Kemudian dia, kita harus
mendefinisikan kita ingin dokumen
apa yang mau kita terima.
Atau yang mau kita
kirim. Sorry, yang mau kita kirim.
Eh, kalo get
yang kita terima dong.
Ya, terima. Yang kita terima.
Ya, accept. Misalkan
saya mau dokumennya dalam bentuk HTML
atau text ya. Dalam hal ini ya.
TXT berarti. Atau
saya mau semua gitu ya. Mau apapun
tipenya terserah. Bebas.
Ya, atau mau tipenya JSON,
XML, dll. Itu urusan kita.
Kemudian dibalas
oleh server dengan
versi HTTP-nya.
Status code-nya.
Kemudian ini
short.
Status code. Ya, status code-nya.
Status code dengan bahasa
ya, oke. Terus
not found
dan lain-lain ya. Content type-nya
yang harusnya
sesuai sama ini. Karena ini bisa
terima semua. Dia terima apapun.
Ukuran
kontennya.
Atau ukuran dokumennya.
Kemudian
expire ini untuk
caching ya.
Caching.
Lalu, terakhir
dokumennya dimodifikasi
kapan? Dan ada
server-nya di sini.
Boleh ada, boleh enggak. Kan ini
metadata information kan.
Kalau di
OAS itu
sebaiknya jangan ada informasi apapun
di sini yang berhubungan dengan
web server ya.
Ya.
Demi keamanan.
Demi keamanan. Jadi teman-teman boleh pakai ini
tapi di aneh-anehin aja. Misalkan
Tomcat gitu. Padahal pakainya
WordPress gitu kan.
Biar bingung. Silahkan.
Silahkan
berkreasi. Nah, kemudian setelah itu
baru respons-nya di sini.
Berhubungi ini text, ya dia plain text aja ya.
Kalau HTML, berarti dia isinya HTML.
Kalau XML, dia XML. Kalau JSON, dia JSON.
Kemudian udah. Balik lagi.
Begitu selesai dikirimkan,
connection-nya mati.
Gitu. Nah, itu TTP
1.
In addition to media type negotiation
RFC, RFC apa?
Request for...
Itu tadi yang kita lihat tadi. Apa?
Connection.
For comment.
Comment kayaknya.
Iya.
Itu yang untuk bikin standard RFC.
Oh iya. RFC.
Jadi ini udah mulai ada
kompleksitas. Udah mulai ada fitur-fitur
yang aneh-aneh ya.
Seperti encoding. Kita bisa ngirimin
data, file, video, dan lain-lain.
Sekarang ya.
Character set support itu
Compression ya.
Compression, iya compression.
Mau pakai gezit,
broadly, dan lain-lain.
Multi part ini tadi upload.
Upload file, autoritasi,
caching, proxy behavior,
dan lain-lain. Ini udah
1.0 ini udah lumayan modern ya.
Yang sekarang digunakan.
Bisa dilihat tuh contoh di dokumennya.
Kalau mau liat
di private chat.
Contoh contohnya.
RFC tadi ya?
Yang bawah.
Ini ya?
71.
Iya.
Itu yang pertama kali.
Jadi kalau misalnya mungkin
kalau kita yang belum pelajarin dari sini kan
suka bingungan. Kayaknya tiba-tiba banyak banget.
Ada apa aja sih?
Dari mana, siapa yang nentuin,
terus kadang kita
salah kopas atau gimana tuh dari
misalnya
accept, ketuker,
sama content encoding.
Terus, ini
kenapa, kapan pakai yang
oh, allow,
accept, kapan pakai
masing-masing itu. Nah,
ini definisinya semua
ada di sini.
Atau siapa tau yang telah temen-temen
ada yang mau bikin
browser.
Terus bikin
protokol sendiri.
Bukan, ini
ini dasarnya semua.
Iya.
Bayangkan ya,
developer yang bikin
ini,
bukan, apa, kerjaannya
itu bukan cuma encoding selesai,
tapi harus bikin ini, atau bikin ini dulu
baru dia encoding-nya.
Dokumentasi sebanyak ini ya.
Kalau ininya belum fix,
nanti dia encoding, nanti dia encoding, ternyata
maksudnya bukan itu. Terus pada
marah-marah, kalau bukan ini, itu sama.
Yang bikin si, ini ya,
Omban Leslie juga ya.
Itu ada author dari atas.
Iya, ini ya. Dan teman-temannya, Paul ya.
Timnya beliau.
Jadi, encoding itu bukan cuma
bikin kode.
Dokumentasi juga.
Gampang. Yang susah ini.
Bikin kode, ya,
baru sepersekian persen
dari pekerjaan kita.
Dokumentasi sama, apa,
nentuin sih, bikin
keputusan. Jadi kayak seberapa
scope-nya seberapa, masalah
apa yang mau dipecahin, terus kita mau
kenapa buat mencapai
tujuan atau masalah yang
kita pecahin.
Kalau Tim Bernersley, ya udah
terbiasa.
Terbiasa melakukan itu. Nah,
ini ada pertanyaan
dari Riza Minudin.
"Bisa kirim
dalam bentuk JSON nggak?" Bisa.
Ini kan kita bisa kirim,
kita mau ngirim data.
Kalau ngirim data, pakai pos ya, bukan pakai get ya.
Kalau get itu untuk minta
request, minta data.
Kalau kirim pakai JSON, bisa.
Sama aja.
Jadi,
jawabannya bisa sekali.
Karena itu yang kita lakukan
sekarang, kalau bikin
application JSON.
Iya, nerima JSON,
ngirimin juga JSON, ngirimin
dalam bentuk form gitu kan, bentuknya JSON kan.
Kita kirimin bodinya.
Oke, kita masuk ke yang
kita gunakan sekarang adalah HTTP versi
1, yang akan datang kita gunakan
versi 2 ya. Loncatnya lumayan tinggi ya.
Dari 0,9, 1.0,
1.1, terus nanti loncat ke 2 ya.
Itu ada ceritanya nggak ya?
Bukannya sudah di 2 sekarang ya?
Oh, sudah di 2 ya? Sekarang 2?
Sekarang 2 ya?
Iya, kita akan loncat ke 3 soon.
Tiga tuh malah
sebetulnya, diam-diam.
Browser tuh udah support,
nggak, gue sudah pernah implementasi
aja, pakai quick.
Anyway, nanti kita lanjut.
Oke, seru nih.
Oke, mantap.
Mana dia? Nah, ini ya. Kita bisa
lihat di headers-nya di sini ya.
Ada nggak, HTTP versi
ininya? Ini sudah, ini bahkan
sudah, ini,
ini udah HTTP 3 ini.
Udah 3 ya? Udah itu H3,
dia terus, dia terus itu H3.
Itu H3.
H3 itu sudah, sudah
HTTP 3.
Ya, buka ini aja deh,
rizafahmi.com.
Oh iya, boleh deh.
Ini masih HTTP 2?
Iya.
Mana dia?
Network.
Refresh lagi.
Refresh. Fail.
No internet?
Karena ada ininya kali,
ada settingannya untuk
pulang.
Abis cek.
Abis kemaren tuh, wassup.
H3 juga.
Iya, berarti di belakang
clock-faire ini ya.
Di belakang clock-faire.
Iya kan ada cewek soalnya.
Yes, ketahuan kan?
Buka EKA 2II.
Coba juga.
Oke, oke, oke.
Saya percaya, saya percaya.
Sekarang sudah HTTP 2
dan menuju 3 ya.
Berarti
saya ketinggalan.
Masih HTTP 1.1.
Oke, ini,
HTTP 1.1 ini
lifecycle.
Masa hidupnya lumayan lama ya.
Mana dia?
Into standard world release
RFC 2616.
Jadi yang
HTTP 1 itu
di-release
HTTP 1.1
di-release di tahun 97.
Kemudian ada perubahan juga
tapi nggak naik ya versinya ya.
Harusnya naik ya.
Minor ya.
Nah, sekarang
udah semakin tambah panjang.
Jadi ini masih sama.
Ini hidup yang kita punya kan ya?
Yang kita kenal sekarang ya.
Ada house-nya, ada user agent-nya,
ada menerima apa saja.
Termasuk tadi
kalau mau JSON kita bisa juga.
Ada encoding-nya, Gzip
dan lain-lain. Ada
apa tadi?
UTF dan lain-lain tuh.
Bahasa ya.
Charset, charset.
Ini dia, ISO. Ada cookies.
Dan kemudian respons-nya juga bertambah.
Kita pernah bahas cookies.
Kita sudah pernah bahas cookies.
Apa yang belum kita bahas coba?
Kita belum bahas URL.
Nah, teman-teman punya ide apa yang
kita belum bahas bisa kirim ke
bit.ly/ngobrolingweb.
Nah, ini bisa
teman-teman bisa coba.
Teman-teman bisa coba HTTP,
request HTTP itu kayak gini ya.
Coba.
Oke. Terus respons-nya juga
masih mirip-mirip dengan
request ya. Jadi ada versi,
ada status, ada
server-nya apa.
Keep Alive. Nah, Keep Alive ini yang tadi
belum support, sekarang udah bisa.
Keep Alive itu berarti
gimana tuh?
Keep Alive itu connection
jadi...
Enggak putus ya setelah menerima.
Jadi untuk koneksi
antar dari si
browser ke server,
dia gak di-close.
Gak di-close. Dia akan
mendengarkan terus.
Karena untuk...
Kan kalau kita buka misalnya
gini, web server itu punya thread.
Punya pull thread.
Pull of threads ya. Kalo engine
X itu kan ada setting-nya
itu ada children.
Dia pake thread dan satu thread itu bisa
menghandle berapa koneksi.
Nah, kalau misalnya diputus,
dia berarti kan harus booting ulang
koneksinya.
Kan ada panjang lagi.
Ada session-nya lagi.
Jadi kalau misalnya pake Keep Alive itu
akan ada handshake-nya.
Kalau Keep Alive itu, dia akan
dengerin dulu. Sampai
tergantung si web server mau kasih berapa lama.
Kalau dia gak dengerin lagi,
dia di-close, putus.
Hmm, sampai berapa lama
sampai ininya...
Tergantung si web server punya...
Ada time out-nya juga ya.
Ada time out-nya.
Nah, Keep Alive
ini adalah cikal bakal dari
pertanyaan dari
Riza lagi.
Websocket.
Jadi versi
tradisionalnya
dari Websocket adalah Keep Alive ini.
Yang sebelumnya kan
request, response, selesai.
Request, response, selesai.
Terus ternyata ada kebutuhan untuk
wah, saya butuh ini nih.
Chat app misalkan. Keep Alive.
Terus Keep Alive udah gak
bisa apa ya, kurang
flexible, akhirnya muncul
Websocket. Websocket itu
HTTP juga,
tapi dia tetap, jadi kayak dia bikin
jalur sendiri yang tidak akan
tertutup. Akan terbuka
terus sampai kita yang tutup.
Dan semacam event-base ya?
Betul. Apa?
Bisa terima event, jadi
kayak semacam event listener, tapi
client ke server.
Kita belum pernah bahas ya?
Kita belum pernah bahas tentang
Websocket. Ide yang bagus.
Terima kasih ide-nya.
Langsung kita tulis.
Oke, kita lanjut dulu.
Di sini, udah jelas ya, yang ini
udah hampir-hampir sama, terus di sini
isi dokumennya. Ini
apa lagi nih?
Oh, dua kali dia.
Satu, dua, tiga, empat, lima, enam, ini apa enam?
Inform, support, that connection...
Kalau satu-satu itu
dia bisa request.
Oh, bisa request.
Multiple ini ya?
Iya, iya.
Kalau dua, bisa
duplex ya?
Multiplex.
Duplex, duplex. Duplex cuma dua ya.
Kalau...
Kalau dia terreflex, kayu.
Kalau
HTTP2,
dia
yang paling utamanya itu adalah
kirimnya satu.
Misalnya,
ini kan kalau HTTP1 dia,
kalau dia mau minta
file itu, dia harus
kirim satu, balik,
dan nanti habis itu minta lagi
beberapa. Misalnya
CSS-nya, Fabricon-nya, JS-nya,
dia akan request secara waterfall.
Dia akan minta terus.
Kalau HTTP3,
eh, sorry, HTTP2,
bisa sekali
kirim, bisa satu kali
kirim, nanti dari server kirim
push, bisa
push data.
Gak perlu request, perlu request
tetap.
Kalau HTTP2, push.
Push ya, bisa push ya.
Satu jalur itu,
dia pakai satu jalur yang sama.
Tapi harus handshake dulu, kan?
Iya, kan pertama kan handshake
sudah terjadi.
Iya. Baru kemudian,
baru dia bisa kirimin data, kan?
Itu perbedaan
signifikan antara 1.1 ke 2, kan?
Waduh, bingung.
1.1 emang udah bisa itu?
Udah bisa
multiplex?
Udah bisa push?
Gimana kalau kita scroll
ke bagian HTTP2?
Iya, ternyata udah ada jawabannya.
HTTP2 improving
transport performance.
Jadi, ini fokusnya ke performance.
Multiplexing itu hanya ada
di HTTP2.
Iya, HTTP1 belum ada, kan?
Yes.
Yang awalnya dimulai dari
one line protocol di HTTP
0.9. Sekarang
sudah berevolusi dengan cepat
menjadi generic hypermedia
transport setelah
beberapa dekade
selanjutnya.
Apa nih?
Nah, bentar.
Ini apa? Ada
poin menarik juga sih.
Apa? Hypermedia ini.
Tadinya kan beda banget, kan?
Yang 0.9 ya?
Tadinya hanya dokumen.
Dokumen, kita nggak bisa minta
apapun. Nah, ini jadi generic
hypermedia.
Nah, ini nyambungnya ke
pertanyaan tentang JSON
tadi tuh. Kita jadi bisa
minta jenis
itu, apa? Jenis file
macem-macem, kan? -Apapun.
-Coba share screen dulu.
Share tab.
Nah, ini nih kita
bisa meminta dan
mengirim macem-macem
teks pun, kan?
Apa? Selain teks plain,
itu sebenarnya banyak banget.
-Ada FPF, ada
DOC.
-Nah, kalau yang tadi
ditanyain kan, JSON ya?
-Jasen pun ada
JSON-LD. Ada JSON-P
kalau nggak salah ya. Tapi di sini ada nggak JSON-P?
Nggak ada ya? -Kayaknya itu bakal
masuk ini juga deh. Karena
ini kan, apa?
Ini tuh kayak udah predefined.
Jadi ini
IANA. Apa?
Ada official registry-nya namanya
IANA. Official
main text-nya udah ada
daftar tersendiri.
Ya, nanti kalau bisa ngeliat aja sendiri.
Tapi yang jelas, opsinya macem-macem banget.
Jadi ini kan sebenarnya
essentially semua kan text-nya.
Tapi kita bisa kayak
menspesifikasikan
text-nya tuh jenis apa.
-Ya.
Nah, HTTP/2 ini
lumayan
apa ya, orang aware
dengan versi-versi HTTP ini
salah satunya gara-gara
gRPC. Karena
gRPC menggunakan HTTP/2
yang bisa datanya di-push gitu kan
itu memungkinkan gara-gara si HTTP/2
gitu. Sebelumnya tuh
ya kita harus request dulu kan.
Nggak bisa si server
sekonyong-konyong mengirimkan data ke kita
gitu. Jadi kita harus request
baru ada tadi.
Belum pernah ya.
G-RPC itu versi
sederhananya.
G-RPC itu kan remote procedural call.
Kalau G-RPC itu remote procedural call
yang dibuat oleh Google.
-Oh.
-Nggak tahu, nggak tahu.
Itu menjadi Mr. E.G.
itu apa? Yang jelas ya dari
tim Google sih.
Jadi ya semacam
inilah sejenis
protokol untuk mengirimkan dan
menerima data. Sama seperti
GraphQL, RCPI menggunakan
JSON atau XML.
-Oh, geinya itu general
purpose.
-Ada yang bilang gitu, ada yang bilang Google.
Jadi ada banyak versi belakangnya.
-Versiandaan.
-Versiandaan.
-Ya, jadi dia ngirimin bukan ngirimin
teks. Kalau misalkan RCPI
kan dia ngirimin teks JSON atau
XML gitu kan.
Kalau G-RPC
dia ngirimin binary.
-Stream. Oh.
-Binary, bisa di-stream juga.
Jadi katanya lebih performance-nya
lebih bagus.
Nah, si G-RPC
kalau dikonsumsi di web, dia menggunakan
HTTP2 gitu.
Makanya banyak orang yang ngah
sekarang, wah, HTTP sekarang versi 2 ya.
Kalau dulu kan nggak peduli ya, mau versi
berapa gitu ya. Kecuali yang bikin web server
ya, dia bisa tahu kan. Kalau kita yang menggunakan
kayaknya nggak, nggak ngah kan.
Ini versi berapa gitu ya.
-Karena dulu cuma satu, ya udah.
Kalau cuma satu kan by default.
-Nggak ada pilihan. Apalagi
si web browser
juga, kalau udah dia dukung
1.1, ya udah. Yang
versi lain nggak bisa. Dia backward
compatible kan, harusnya ya.
Kita masih bisa
pakai HTTP versi 0.9
nggak?
-0.9, nggak tahu. Tapi kalau
satu, harusnya kan
kan prinsipnya sama.
Cuma ada yang
kayak hinder-hinder-nya aja.
-Tergantung server-nya sih ya? Pasti
bisa ya? -Iya. Kalau server-nya
bisa ya, ya coba aja
itu cari engine
X atau apa C masa lalu, fork-nya.
-Ini ada pertanyaan dari Rafki.
-Teknikulnya bisa kecuali server-nya mau nolak.
-Oh iya, benar-benar.
Ini ada pertanyaan dari Rafki.
HTTP 2 ditulis pakai Go kah?
Kita tidak tahu. Kayaknya nggak deh.
-HTP 2 itu standard, bukan
ditulis pakai apa.
Jadi tergantung web server-nya
ditulis pakai apa.
Kalau web server-nya
misalnya web application server-nya
Go, ya pakai Go.
Kalau engine X ya pakai
saya nggak tahu, engine pakai C++.
-Jadi protocol
ini adalah
apa ya, kesepakatan
bersama, dokumen kesepakatan
bersama, bahwa kalau saya kirimin
ini, saya dapetin ini.
Implementasinya bebas.
Mau pakai C, C++,
Golang, mau pakai Rust, bebas.
-Express, contohnya Express nih
teman-teman pakai Express.
Di dalam Express itu sendiri
dia akan implementasi satu library yang
HTTP library.
Jadi
HTTP library ini
yang sudah ditulis oleh teman-teman itu
menggunakan standard
HTTP 2.
Berdasarkan standard
HTTP.
-Betul.
-Apa sih library
HTTP di NPM?
-HTP?
-Ya, HTTP.
-Di Node.js ada built-in
module namanya
HTTP sama HTTPS.
-Beda ya HTTP server
sama HTTP client ya.
-Beda.
-HTP client itu adalah
untuk mengkonsumsi.
-Mengirim dan menerima.
-Mengirim dan menerima.
-Mengirim dan menerima.
-Oh ternyata di Node.js sudah ada
built-in. -Sudah ada built-in.
Kalau Express dia pakai
yang lain lagi kayaknya. Eh, pakai HTTP
kalau nggak salah.
-Kaya dia pakai HTTP deh.
-Iya, dia raper di atasnya
Node.js.
Kalau
HTTP client
itu temen-temen biasa
pakai
Postman, Axios,
Churl ya
yang tradisional.
HTTP banyak ya.
Itu client. Jadi kita bisa
menggunakan itu. Insomnya
sama seperti browser.
-Kalau di PHP 5 dulu
HTTP get content.
-Ok.
PHP juga ada PHP Churl kan?
-Iya, tapi kalau
call-nya nggak ada, kalau nggak di install
kan bisa. -Oh iya, kalau nggak di install, nggak bisa.
-Itu kan
PHP extension.
-Extension. Ya.
-Kalau by core-nya dia
HTTP get content. -Get content.
Iya, iya, iya.
-Nah, kayaknya kalau di dunia HP itu
apa sih, ada misalnya kayak library
kayak Gazelle atau semacamnya
di Laravel itu kan sebenarnya meng-extend
itu ya, si apa? Yang
PHP. -Curl.
Ya, tergantung.
Kalau dia, dia
di dalamnya sudah ada curl, dia pakai curl.
Tergantung.
Dia bisa
nge-detect apa yang di install.
-Nah, kalau WebRTC,
WebRTC itu apa?
HTTP berapa? Beda lagi ya.
Itu protokol bukan sih? -Beda teknologi.
Beda teknologi ya.
-Tapi dia berjalan di atas
HTTP 2?
-Sebelum saya bisa
ngomong, saya baca dulu ya.
-Dia punya protokol.
-Ya, kita belum pilih partisi juga sih.
-Iya, betul.
Itu protokol sendiri.
-Protokol sendiri?
Tapi menggunakan,
di atas protokol HTTP, kan?
-Iya. -Jelas.
-Per-to-peer dia, per-to-peer.
Ya, baca dulu.
Saya pernah pakai,
tapi nggak pernah baca mendalam,
kalau nggak ditanya begini ya.
-GRPC karena menggunakan Go
bisa jadi.
Namanya Go.
Google Lang.
-Go Lang juga bisa disebut
Google Lang. -Iya, Google Lang, kan?
-Kalau percayaannya, maksudnya
kalau resminya ya nggak, namanya Go.
-Tapi kenyataannya faktanya
memang dikembangkan di Google, kan?
Itu ya nggak salah juga.
-Nah, logonya tuh,
binatangnya ternyata namanya Gofer.
Tau kan itu yang kaya Tupai.
Tadinya kira itu Tupai
atau Brang-Brang atau apa.
Ternyata bukan. Itu namanya Gofer.
-Basa Indonesia-nya apa?
-Iya nggak penting. Ya nggak ada, nggak tahu.
Apa ya? -Oh, nggak tahu ya?
Binatang bahasa Indonesia-nya.
Binatang apa? Itu Gofer.
-Oh, tikus tanah.
-Tikus tanah.
-Tikus tanah itu yang kaya gimana?
-Iya itu yang kaya logonya Go.
-Oh, bulunya warna biru gitu.
Wah, keren banget.
Heimster kali itu.
-Kaya lebih kayak
Tupai Brang-Brang gitu loh.
-Brang-Brang ya? Iya, iya, iya.
-Tadinya kira yang Brang-Brang. Bukan.
Brang-Brang kan Otter bahasa Inggrisnya.
Ini namanya Gofer. Ya, mungkin nggak ada di Indonesia.
-Saudaranya lah.
-Kok jadi
ngomongin logo kita ya.
Ini masih
berusaha jawab ya. -I'm back to WebRTC.
WebRTC itu nggak pakai satu set protocol.
Dia pakai beberapa sets
of protocol.
Karena untuk streamnya sendiri itu
bukan HTTP. Karena HTTP
nggak bisa stream.
Setau saya. -Belum bisa stream ya.
-Jadi kalau untuk streamnya
dia pakai yang berbeda.
-Good question. Saya
perlu baca lagi.
-WebRTC itu
luas banget ya ternyata.
Maksudnya WebRTC itu
satu kategorisasi yang berisi
banyak banget API.
Jadi kayak bahkan yang, apa itu?
Kamera, media stream.
Itu aja, itu sebenarnya bagian
dari WebRTC.
Media device punya
semua yang terkait media
capture,
kamera, mikrofon.
Itu ternyata bagian dari
WebRTC.
-WebRTC tidak menggunakan
HTTP, tapi dia menggunakan
TCP.
HTTP menggunakan TCP sih.
Tapi bukan
berarti WebRTC menggunakan
HTTPS.
-Ini ada yang ketinggalan ya pertanyaannya.
Terima kasih ya
Rafki tadi pertanyaan tentang WebRTC
jadi kita bisa jadikan bahan
topik sendiri ya.
Tadi kita sempat bahas WebSocket.
Jadi implementasi socket itu
bukan request setiap detik, bukan.
Itu
tradisional. Versi modernnya
adalah dia buka jalur khusus
yang tidak tertutup.
Jadi bisa saling kirim data
antara server sama klien.
Nah, kita tadi ini baru
sampai ngomongin HTTP.
Belum ke HTTPS.
-Padahal ide ini
topik ini gara-gara HTTPS ya.
-Gara-gara HTTPS.
Yang mana nih?
Guideline HTTPS.
-Yang overview aja dulu yang
paling pendek tuh. HPB
NGCO.
Jadi intinya kan
HTTPS adalah
HTTPS ditambah
TLS.
Nah, itu sebenarnya apa?
Kalau dilihat ke atasnya itu
artikel tentang TLS sih sebetulnya.
-TLS itu apa kepanjangannya?
Nah, ini 7 layer ya.
Transport layer security.
Oke, terus
silahkan baca sendiri.
-Mengamankan, menyediakan
satu layer keamanan.
-Nah, untuk HTTPS sendiri
ini...
-Kaya lagu Halloween gitu ya.
-Lagu Halloween.
Kita nggak tahu.
Kita nggak merayakan Halloween.
Bukan, bukan OC layer.
Ini transport layer security.
Beda sama, sedikit beda sama
OC layer ya. OC layer juga 7.
1, 2, 3, 4, 5, 6.
Ini cuma 6.
OC layer itu network ya. Transport ya.
Unencrypted communication via...
Gimana?
-Ingat jaman dulu mau punya HTTPS itu mahal.
Oh iya.
Harus bayar.
Kalau sekarang ada yang gratis.
Gampang.
Unencrypted communication via HTTP
and other protocols
great rates, number of privacy, security
and integrity vulnerabilities.
Such actions
are susceptible
to interception, manipulation, and impersonation.
Jadi intinya adalah...
-Saya mau di-ticket di tengah-tengah ya.
-HTTP itu kan...
-In the middle attack.
-Plan text kan. Plan text tiba-tiba
di tengah-tengah ada yang
ngambil request kita
atau response kita, intercept
kemudian dia tambahin
sesuatu
masuklah virus ke server kita
atau masuklah virus ke laptop kita.
-Atau penting yang dikirim bisa di...
-Diambil juga, di-copy bukan diambil ya.
Password apalah...
-Kalau situs kita
pakai HTTPS saja
password yang lewat itu
di networknya.
Yang pegang network, yang pegang
access point atau wifi atau router
itu bisa lihat datanya lewat pelanjang.
-Kaya datanya, text biasa.
-Iya, lewat pelanjang, datanya text.
-Saya sering main-main begitu dulu.
Saya suka, oh passwordnya ini.
Jaman dulu
yang kalau
teman-teman
pernah merasakan,
itu ngenet
yang banyak aja. Dulu ada
wifi.id, yang sebut
merek gitu. Wifi apa gitu.
Wih, ada wifi gitu.
Gitu-gitu dibuka
situsnya, terus ada iklan muncul
dan iklan itu punya dia, gitu.
Muncul di
di-footer. Saya kadang
meskipun yang saya bukan pakai
public wifi, saya pakaiin di rumah.
Itu loh.
Ini situs saya, kenapa
ada iklannya?
Saya nggak pasang iklan ini, padahal
oh, ternyata
ternyata
koneksi saya di intercept
dan dia menginjekkan JavaScriptnya
ke HTML
saya, dan iklannya
muncul.
-Iya, kalau cuma iklan.
Kalau tracking pixel atau semacamnya
ya udah. -Oh, ada juga tracking
pixel banyak.
Suka-sukanya masukin apa.
-Jadi hati-hati, kalau
ada wifi gratis, ya
waspada saja, waspada.
-Selalu gunakan
VPN. -Iya. Jangan
buka website yang macam-macam
seperti bank.
-Macam.com
-Bukan. Banking.
Banking e-bank.
Buat transaksi, ada
username, password, dan lain-lain
di public wifi
karena yang punya router
bisa melihat juga. Ada kemungkinan
dia bisa melihat, gitu ya.
Makanya selalu siap-siap
dia VPN.
-Karena belum tentu
kita, Mas. Pasti bisa melihat sih.
-Iya, pasti.
Antara plain text
atau yang encrypted, kan?
Jadi ya, tergantung
kita gimana. -Bisa lihat
kalau dah encrypted, gak apa-apa.
Bentuknya kurang-kurangnya.
-HTTPS ini
melakukan itu. Jadi
mereka tidak lagi
mengirimkan data dalam bentuk
plain text yang bisa dibaca oleh
mata manusia, tapi
ini dalam bentuk enkripsi, ya?
Dia enkripsi, ya?
-Kalau teman-teman ingin
bereksperimen, silahkan
pasang sendiri, misalnya routernya,
terus bikin browser, apa,
HTTP sendiri di rumah, lokal hot,
liatlah data yang lewat, itu
bisa pakai Wireshark.
-Wireshark. -Ya, itu saya pakai
dulu. Saya suka pakai, terus liat data
yang lewat. Wireshark.
-Wireshark.
-Semua.
-Nah, apa hubungannya
HTTPS sama
Coarse? Nah, ini bisa jadi topik
sendiri juga ini. Banyak ya topik
malam ini ya.
Coarse, cross origin, resource.
-Resource,
apa, script, eh.
-Bukan. -Case-nya apa sih?
-Wah, gak lulus interview.
-Cross origin
resource sharing.
-Resource sharing.
-Ada hubungannya gak? -Ini kita bahas
saat kripsasi Sandbox.
-Oh iya, kripsasi Sandbox.
-Oh iya, kita bahas origin.
-Pertanyaannya ada hubungan
dengan HTTPS?
-Nggak.
-Tidak secara langsung?
-Iya, sama-sama
berkaitan security ya.
-Sama-sama security, tapi
ya, hubungannya, ya, satu
kategori ya, tapi tidak ada
hubungan secara langsung. Karena
HTTPS juga bisa
gitu.
-Rekonsider adalah bagian dari
HTTPS.
-HTTP ya, gak harus HTTPS.
-Iya, HTTPS, bukan gak harus HTTPS.
Jadi, yang dilakukan HTTPS
adalah protect integrity of the website,
protect the privacy and
security of user, enable
powerful features on the web, contohnya
offline experience,
user optin,
apa lagi,
dan lain-lain.
Jadi, ya itu ya, sederhananya adalah
data kita sudah tidak bisa dibaca
oleh mata manusia,
harus butuh apa ya,
butuh effort lah untuk
mendeskripsi
bahasa Indonesia-nya, baliknya
apa? Decrypt ya?
-Decrypsi. -Decrypsi
datanya supaya bisa dibaca.
Ya, itu posibel juga, cuman
lebih sulit lah, gitu.
Terus gak segampang itu
menyusupin ke respons-nya juga.
-Iya. -Bisa jelaskan bagaimana
cara kerjanya gak?
-Kerjanya HTTPS? -Apa bisa begitu?
-Iya. -Ini? Bukan?
-Aduh, itu TLS nih. -Itu CLS nih.
-Doh ya. -Yang itu?
-Bagaimana data
di Encrypt itu pakai
certificate private key dan public key.
-Oke.
Gak ada ya. -Iya gak, kalau kita generate
generate
-GWP, bukan. -Jangan pakai
Less Encrypt kan,
kalau installnya sekarang udah gampang banget ya.
-Gampang banget. -Sertboard install
jadi. -Malah kita gak usah ngapain-ngapain,
biasanya kalau pakai hosting modern
kan pasti hampir pasti include lah.
-Udah, hampir pasti include.
-Mustahil pakai firebox hosting atau
kompetitor apapun lah yang modern.
-Betul. -Gitu.
-Atau kalau manual
pakai apa? Pakai Cloudflare
juga sudah ada kan?
-Atau
coba generate
self generate SSL.
-SSL sendiri.
-Bisa juga
self generate.
-Self generate.
-Nanti
itu nanti harus allow sendiri ya.
Allow browsernya
kayak trust gitu.
-Paling sederhana, di localhost aja
di localhost, bisa kok.
Localhost dibikin HTTPS, gimana caranya.
-Ada.
-Jadi kita ada private key
dan public key.
-Tapi jadi gak belajar.
-Hah.
-Dari private key dan public key itu
public key
public key-nya ini
akan dibaca oleh
browser.
-Server. -Server.
-Yang akan dipublish ke
akan dikirimkan, bisa di request
oleh si
browser itu namanya nanti
SSL HMC.
Jadi dia baca public key-nya,
dia terima
public key-nya, terus waktu
nanti data
mau dikirimkan, dia
semua data yang
mau dikirimkan ke server
itu akan di hash
menggunakan public key.
Anguritmenya banyak, saya gak tahu,
ada beberapa
berbagai jenis.
Dan di-encrypt,
terus data yang di-encrypt
akan dikirimkan ke server.
Nah, data yang di server,
saat diterima,
sebelum dia didecrypt,
sorry, untuk mendecryptnya
itu, dia akan ada
proses validasi. -Dicucukin sama private key ya?
-Yes, jadi dari
private key, yang itu dia
kan ada
challenge, ada hash-nya juga,
ada challenge hash-nya itu akan
validasi dengan private key,
eh, cocok ini digenerin oleh public key-nya
sendiri, barulah
bisa di decrypt.
Begitulah, sekirah-kirah
cara bekerjanya, private key
dan public key.
Sama, itu
mirip-mirip kok semua
cara kerjanya SSL
handshake itu sama kayak cara kerjanya
SSL.
Ingat gak, kalau SSL itu kan kita kalau jenis SSL
lagi, ada IDRSA,
ada, sekarang masih jaman
IDRSA PUP,
publica.
Tapi, anyway,
RSA yang biasa tanpa .PUB
ada yang PUB.
Nah, kalau biasa di server kita
taro yang authorized key,
itu kan PUB-nya doang, jangan
private key. Nanti
waktu dia handshake itu kita
dari si klien akan
connect ke server,
dan data yang dikirimkan
bisa diauthorized.
Oke, ini benar dari private key
yang...
hasil hasilnya itu bisa
di decrypt oleh
public key, dan itu
akan bisa nyambung, itu yang namanya
handshake. Sama.
Ini pasti
temen-temen sering
kejadian kalau mau
pull request,
mau kirim data ke
GitHub, ya.
Kalau nggak mau masukin user yang password
pakai HTTP, pakai SSH,
itu harus generate keygen
nya dulu kan. Abis itu
di copy-paste lah di GitHub-nya,
apa RSA PUP-nya.
Kita masukin
di account settings sama
di lokal kita ya?
Iya.
Dan public key,
public key-nya itu unik untuk
seluruh user yang ada
di dunia.
Nggak ada yang sama.
Nggak bakal ada yang sama?
Bisa jadi sama, tetapi
kecil banget kemungkinannya.
Kecil-kecil-kecil-kecil banget.
Tapi
so far nggak akan
bisa sama. Misalnya temen-temen coba aja
punya 2 account GitHub,
masukin aja public key yang dari
user A, masukin di user B
nggak akan bisa.
Iya. Sekarang GitHub
udah harus
provider authentication ya.
Tidak bisa hanya email.
Harus pakai
ini ya. Apa namanya?
Yang harus masukin dari
external device
atau apa-apa.
Pakai paski dong.
Pakai paski dong.
Pengen tau paski,
nanti datang ke Tok saya.
Loh, di Malaysia.
Di Malaysia.
Di Malaysia.
Hmm.
Oke.
Sudah.
Selesai, dimateri kita?
HTTP 3? Belum.
HTTP 3 mau dibahas?
Yang mana? Ada nggak?
Ada, ada, ada.
Coba bahas ya.
HTTP 3.
Kita masukkan.
Jadi, HTTP 3 ini
sendiri belum
fully supported ya.
Jadi, teman-teman.
Dan HTTP 3
ini sendiri ada beberapa
standard. Sorry, ada
substandardnya. Jadi, ada yang
bisa streaming, bisa
push, ada bisa
UDP segala macam. Ada
kode-kode-nya, dan saya pusing sendiri
kalau mau menjelaskan yang satu-satu.
Yang membedakan
antara hati...
main-main different,
main ingredients-nya yang membedakan
antara HTTP 2 dan
3. Itu
adalah di HTTP 3
instead of menggunakan
TCP, dia menggunakan UDP.
Yang artinya jauh lebih...
Yang UDP itu...
Jauh lebih cepat?
User Datagram Protocol dia
nggak ada aceka-acekaan.
Tidak ada handshake?
Ada handshake, tapi dia nggak aceka.
Oh iya. Ini kan, bedanya
TCP sama UDP.
Kalau TCP, dia memastikan datanya
nyampe. Kalau UDP, nggak peduli, kan?
Betul, betul.
Jadi, kita kirimin data, seram menyampe
munggak terserah, gitu kan? Bebas.
Broadcast, kayak broadcast data, gitu.
Kalau TCP, setelah handshake,
dia kirimin data, dia
tungguin dulu. Bisa buka
ini-nya saya, dari link-nya saya
yang tentang UDP.
Dia tungguin dulu, sampai...
yang glossary
yes, glossary UDP.
Sampai datanya berhasil dikirim
atau datanya error, kan?
Kalau TCP/IP, kan?
Ada diagram yang sedikit di bawah.
Jadi, ada status-nya. Nah, ini dia.
Kalau UDP, hanya
request-response saja.
Betul. Jadi,
sync, sync-aceka, aceka.
Jadi, dia nanya
kalau TCP itu, buka
koneksi dong. Oke.
Dua terima nggak? Oke, gue terima.
Dia kirim lagi. Oke, siap.
Oke, kita sudah. Pasti ini.
Sudah selesai.
Barulah kirimkan data-nya. Jadi, ada
round-robin di sini. Minimal.
Jadi, setiap kali kita request,
ada round-robin.
Round-robin atau salah? Bukan apalah.
Bahasanya itu. Bolak-balik lah.
Beberapa kali ya.
Kalau di UDP, request,
langsung kasih semua. Nah.
Ini buat lu semua. Bodo amat.
Nggak ada status error, nggak ada status
oke, dan lain-lain ya.
Jadi, secara...
Tapi, ini jadi lebih cepat.
Ya.
Jadi, jatahannya
koneksinya jauh lebih...
Ya, dua kali lebih cepat lah ya.
Ya, karena dia nggak perlu bolak-balik kan.
Tapi, reliable nggak?
Kalau TCP kan, terkenal-nya
reliable kan?
Oke, sedikit
ini ya, sedikit
fallback, dia ada fallback-nya begini.
Kalau saat ini
standard-nya tuh.
TCP, HTTPS 3
wajib menggunakan HTTPS.
Masih di atas HTTPS ya.
Menggunakan, sorry, SSL-TLS.
SSL-TLS ya.
Harus menggunakan SSL-TLS
karena UDP itu kan
kemudian lagi secara data
dia nggak peduli, jadi makanya harus di-encrypt.
Nah, jadi
saya pakai HTTPS 2
Push yang tadi.
Namun, secara
asetektur atau konsep
kalau si HTTPS 3 ini
masih ada fallback ke HTTPS 2.
Jadi, first request
dari si server
ya, dia, si klien
kan nggak tahu nih
kalau si server itu bisa HTTPS 3
atau tidak.
Ya, dia masih tetap menggunakan HTTPS 2.
Si browser pertama kali
dia ngedetek, oke
dia request HTTPS biasa
HTTPS 2.
Terus si server itu
baliknya kasih tahu
eh, gue support HTTPS 3.
Di header yang tadi kita lihat itu kan?
Iya, coba mas Riza
buka di network type-nya tadi.
Buka aja ini.
Di refresh.
Oke.
Ke bagian dock-nya aja di atas.
Ya.
Turun sedikit.
Di header-nya, response.
Oke.
Dia ngasih tahu
alternate service.
Dia ngasih tahu, saya punya H3.
Di port 3.
Nah, disinilah
browser switch.
Menggunakan
HTTPS 3.
HTTPS 3 ini
dulunya
HTTPS 2 on
quick protocol.
Quick itu.
Sebenarnya sebelumnya itu.
Jadi belum ada nama HTTPS 3
masih kayak HTTPS 2
plus quick.
Artinya HTTPS 2
on top of UDP, that's it
sebenarnya. Terus tapi
akhirnya dijadikan the next standard
menjadi HTTPS 3.
Kemulanya, dia lebih cepat
aja, lebih cepat mengirimkan data
untuk
yang lain saya
nggak banyak.
Bahkan Nginx sendiri
belum. Nginx
sendiri itu, terakhir ya
tahun lalu, itu
untuk support
HTTPS 3 aja, dia masih
experimental.
Tapi saya udah
ada docker image-nya.
Sudah ada docker image-nya untuk bisa
HTTPS 3.
Ini salah satu
keunggulannya juga kali ya. Quick ini
didesign untuk mobile heavy
internet usage.
Kalau kita pakai mobile phone.
Behavior orang tuh udah
behavior orang yang access internet
udah beda banget, antara sekarang sama tahun 90
dulu. Betul.
Kalau dulu kan pasti di desktop kan,
atau di laptop lah. Di desktop dan
pasti di kantor kan dulu.
Sekarang gue baru internet di rumah.
Sekarang di tangan. Sekarang gue baru
ingat perumpamaan kenapa
butuh HTTPS 3. Untung Mas Rizal
sebutin. Jadi
di mobile itu, kita kan ada
tower. Tower A sama
tower B. Tower A sama
tower B. Terang-terang gue terlalu lewat.
Tower A sama tower B.
Anggap kita lagi naik kereta api.
Kita waktu saat request
saat request itu kita lebih dekat
ke tower A. Tetapi waktu
kita response ternyata
kita lebih dekat
ke tower B.
Si nya handphone kita itu
sudah switch ke tower B.
Nah, jadi
kalau kita tadi
pakai proses TCP, dia
bingung nih. Gagal.
ACK-ACK nya itu jadi
lambat. Jadi terlalu
bisa kayak kita kok lambat banget
lembut gitu kalau dalam kereta yang
lagi melaju gitu ya. Sedangkan
kalau pakai dissolve nya
pakai quick ini. Jadi gak peduli
tower mana source untuk
internetnya. Dia gak perlu
ACK-ACKan. Jadi tinggal kirim
ya, diterima.
Itu kenapa adanya
quick.
Ada
apa kayak
case.
Penjelasannya gitu.
Penjelasannya pakai comic.
Katar belakang.
Kalau dulu HTTP
digunakan oleh
orang-orang yang less portable
atau device yang
less portable seperti laptop ataupun
PC, sekarang sudah tidak
lagi. Bahkan kita
kalau sekarang ke gedung aja
access pointnya bisa
aja kita gak tahu kan si
device kita ambil access point yang mana.
Yes.
Jadi itu
apa-apa, si HTTP 3 ini
dikembangkan berdasarkan kebutuhan.
Kebutuhan perubahan behavior
kita sebagai user.
Roundtrip
bahasanya itu
ada di sini kan.
Roundtrip itu kayaknya pertandingan
karakter.
Roundtrip itu kayak bergantian
gitu. Roundtrip itu kayak bergantian.
Informaturnakan biasanya babak penyisihan
gitu loh.
Ya, biasanya kalau tiebreak itu ada
roundtrip. Yes.
Terus
faster. Ya, connection
establishment karena gak perlu
ACK-ACKan.
Iya, zero roundtrip sama
descriptionnya udah lebih comprehensive.
Jadi lebih soliti.
Ya,
ini adalah
huge upgrade from HTTP 2.
Help mitigate
the risk of attacks.
Itu dia HTTP 3. Tapi
belum semua
aplikasi menggunakan
HTTP 3. Bahkan
masih ada yang menggunakan HTTP 1.
Tadi ada tulisannya dimana ya? Nah ini.
After
bukan ya.
Express udah HTTP 3 belum ya?
Kayaknya belum. Masih 2 sih.
Oh ada nih isunya dari
tahun 2021. Siapa tau teman-teman?
Ini dia nih.
Nah, kalau mau lihat website yang
masih pakai HTTP 1 tuh
coba ya buka deh.
Di private chat.
Okay.
Wah, ini yang punya
protokol ya? Ini halaman web pertama.
Iya. Ini adalah
halaman web pertama.
Buka DevTools.
Bisa kita lihat di kiri ada itu-nya.
Kiri atas. Not secure.
Ada warning-nya. Not secure.
Kiri mana? Kiri atas.
Di jaman itu belum ada HTTPS.
Oh, HTTPS apa? HTTPS 1?
HTTPS dan HTTPS 1.
Belum ada HTTPS jelas.
Terus ini kan keliatannya masih HTTPS 1 ya?
Coba aja, reload.
Accept.
Tapi response-nya normal-normal aja.
Nggak ada versiannya ya?
Oh iya, HTTPS 1 kan belum ada
versi kan?
Masuk HTTPS 1 baru kan?
Ini 0.9 nih.
Ini 1 keliatannya deh.
1 ya?
Udah ada ya?
Coba lihat row-nya, Mas.
Row.
Udah ada response-nya, Mas.
Cuma tadi kan ada alt.
response-nya diklik row.
Itu satu-satu.
Oh iya, satu-satu.
Kan udah ada response-nya, Mas.
Tapi belum ada.
Oh, nggak perlu.
Formal spaces nggak perlu.
Lihat ini-nya.
Itu kan ini standarnya tuh.
Harus begitu. Standarnya harus
urutannya begitu tuh.
HTTPS 1-1, 200, OK.
Kan kita bahas lagi.
Itu standar itu.
Nggak boleh dirubah-rubah.
Dan kita belum bahas tentang status-quot ya.
Teman-teman udah tahu ya harusnya status-quot ya.
100 informasi.
Oke, siap.
Teaser buat episode berikutnya.
OK, HTTPS status-quot.
Yang dinosaurus apa ya?
Dinosaurus.
Nggak ada dinosaurus.
Ada 419.
Lucu-lucu ya, lucu-lucu ya.
Ada jokes-jokes-nya juga ya.
Oke, siap-siap.
Boleh, boleh, boleh.
Siapa yang bikin
best API server
kalau gagal,
pokoknya kirim 200, tapi status-nya
status-status error.
Status error.
Saya pernah ngalamin beneran dong, salah.
Terus dimerahin.
Karena itu menaruh ke
SEO kan.
Saya paling benci sama developer
yang bikin begitu.
Ya Elna, kalau gagal
kenapa dibikin 200?
Ya, jadi buat
teman-teman, warning ya.
Anak-anak bikin nih, kalau bikin
recipe I, hatikan status-quotnya.
Itu karena belum ngerti aja sih.
Sebentar, kalau GraphQL
bukannya di 200 semua ya, walaupun error ya?
Nggak ya?
Kayaknya ya.
Kalau error, ya error.
Dengan status-quot 200?
Dengan status-quot 500?
Kayaknya
memes yang mengembalikan 200 itu
gara-gara GraphQL deh.
Kayaknya ya, nggak tahu juga.
Teman-teman, ada yang pernah menggunakan
GraphQL?
Nah, makanya ini cocok buat satu episode lagi, kan?
Iya, bisa, bisa, bisa.
GraphQL, status-quot.
Ada ini GraphQL over HPTP.
Iya, dia nggak suka.
Suka-sukanya.
Kayaknya status-quot aslinya
di body response-nya
atau gimana gitu.
Iya, status-quot in GraphQL.
Nah, ini ada nantilah
buat kita nanti ya.
Oke, baiklah buat episode berikutnya.
Berarti bahasan kita
tentang HTTPS dan HTTPS
kita cukupkan sampai di sini.
Ada pertanyaan yang belum terjawab? Nggak ada ya?
Mudah-mudahan sudah terjawab semua?
Pasti kan aplikasi kalian sudah harus pakai HTTPS ya?
Iya, itu
sudah keharusan, karena
jadi kebalik sekarang.
Kalau mau akses HTTPS itu susah.
Kalau dulu. Apalagi
sertifikatnya gratis, kan?
Kalian bisa datang ke webinar-webinar
gratis sertifikat.
Bukan itu ya.
Kalian bisa
pakai lesson creep.
Pakain gratisan, lesson creep.
Kalau untuk butuhan khusus
ya silahkan bikin sendiri,
atau kalau pengen ini sendiri belajar.
Setelah datang, setelah datang
sudah bisa wildcard belum sih?
Sudah bisa ya? Apa itu?
Setelah datang sudah bisa wildcard belum?
Wildcard subdomain.
Wildcard.
Dulu sih... Tetap per origin, kan?
Per origin.
Sertifikat itu per origin, kan?
Sudah bisa. Setelah datang,
zaman saya sering pakai
itu belum bisa wildcard.
Wildcard itu artinya kayak...
Ya, semua
subdomain didatarkan di satu domain.
Jadi cuma pakai satu
sertifikat
untuk semua subdomain.
Ya.
Sekarang sudah bisa, kok.
Sudah bisa wildcard. Tuh, lebih keren.
Mantap, mantap.
Oke, kalau begitu
terima kasih banyak semuanya yang sudah
menemani, yang sudah ikutan diskusi juga.
Jangan lupa
yang mau nanya
kasih saran, kasih topik, bisa ke
bit.ly/ngobrolinwait
Kita
udahan dulu malam hari ini, ketemu lagi
minggu depan
di hari Selasa dengan topik yang berbeda.
Sampai jumpa, bye-bye.
Bye.
Deskripsi asli dari YouTube
Yuk mari kita diskusi dan ngobrol ngalor-ngidul tentang dunia web. Agar tetap up-to-date dengan teknologi web terkini. Topik, tautan dan pertanyaan menarik bisa dilayangkan ke https://bit.ly/ngobrolinweb Kunjungi https://ngobrol.in untuk catatan, tautan dan informasi topik lainnya.
Episode Terkait
9 Agu 2023
Ngobrolin URL
Episode ini bagian dari niat baru mereka: menyelipkan topik yang benar-benar mendasar setidaknya sebulan sekali, alih-al...
2 Okt 2024
Ngobrolin Drama Trademark & Open Source
Episode ini membahas drama perseteruan antara Matt Mullenweg (co-founder WordPress) dengan WP Engine, sebuah perusahaan ...
26 Agu 2026
Modern Web UI
Episode ini berangkat dari satu keluhan yang sangat spesifik: web UI jadi berantakan begitu fitur LLM ditempelkan ke apl...
Suka episode ini?
Episode baru setiap Selasa malam. Dengarkan lewat YouTube, Spotify, atau feed podcast favoritmu.
Memuat komentar dari GitHub Discussions...
Jika komentar tidak muncul karena ekstensi privasi / adblocker, kamu bisa berdiskusi langsung di GitHub Discussions .