Ketika webservers mengirim halaman, mengapa mereka tidak mengirim semua CSS, JS, dan gambar yang diperlukan tanpa diminta?

45

Ketika sebuah halaman web berisi satu file CSS dan sebuah gambar, mengapa browser dan server membuang waktu dengan rute tradisional yang menghabiskan waktu ini:

browser mengirimkan permintaan GET awal untuk halaman web dan menunggu respons server.
browser mengirimkan permintaan GET lain untuk file css dan menunggu respons server.
browser mengirimkan permintaan GET lain untuk file gambar dan menunggu respons server.

Kapan mereka bisa menggunakan rute singkat, langsung, dan hemat waktu ini?

Browser mengirimkan permintaan GET untuk halaman web.
Server web merespons dengan ( index.html diikuti oleh style.css dan image.jpg )

— Ahmed
sumber

2

Permintaan apa pun tidak dapat dibuat sampai halaman web diambil tentu saja. Setelah itu, permintaan dibuat secara berurutan saat HTML dibaca. Tetapi ini tidak berarti bahwa hanya satu permintaan yang dibuat pada satu waktu. Bahkan, beberapa permintaan dibuat tetapi kadang-kadang ada ketergantungan antara permintaan dan beberapa harus diselesaikan sebelum halaman dapat dicat dengan benar. Peramban kadang-kadang berhenti karena permintaan terpenuhi sebelum muncul untuk menangani tanggapan lain membuatnya tampak bahwa setiap permintaan ditangani satu per satu. Kenyataannya lebih pada sisi browser karena mereka cenderung intensif sumber daya.

— closetnoc

20

Saya terkejut tidak ada yang menyebutkan caching. Jika saya sudah memiliki file itu, saya tidak perlu mengirimkannya kepada saya.

— Corey Ogburn

2

Daftar ini bisa ratusan hal. Meskipun lebih pendek daripada mengirim file, itu masih jauh dari solusi optimal.

— Corey Ogburn

1

Sebenarnya, saya belum pernah mengunjungi halaman web yang memiliki lebih dari 100 sumber daya unik ..

— Ahmed

2

@AhmedElsoobky: browser tidak tahu sumber daya apa yang dapat dikirim sebagai header sumber daya yang di-cache tanpa terlebih dahulu mengambil halaman itu sendiri. Ini juga akan menjadi mimpi buruk privasi dan keamanan jika mengambil halaman memberitahu server bahwa saya memiliki halaman lain di-cache, yang mungkin dikendalikan oleh organisasi yang berbeda dari halaman asli (situs web multi-penyewa).

— Lie Ryan

63

Jawaban singkatnya adalah "Karena HTTP tidak dirancang untuk itu".

Tim Berners-Lee tidak merancang protokol jaringan yang efisien dan dapat dikembangkan. Satu tujuan desainnya adalah kesederhanaan. (Profesor kelas jaringan saya di perguruan tinggi mengatakan bahwa dia seharusnya menyerahkan pekerjaan kepada para profesional.) Masalah yang Anda garis besarkan hanyalah salah satu dari banyak masalah dengan protokol HTTP. Dalam bentuk aslinya:

Tidak ada versi protokol, hanya permintaan untuk sumber daya
Tidak ada header
Setiap permintaan memerlukan koneksi TCP baru
Tidak ada kompresi

Protokol kemudian direvisi untuk mengatasi banyak masalah ini:

Permintaan telah diversi, sekarang permintaan tampak seperti GET /foo.html HTTP/1.1
Header ditambahkan untuk informasi meta dengan permintaan dan respons
Koneksi diizinkan untuk digunakan kembali Connection: keep-alive
Respons terpotong diperkenalkan untuk memungkinkan koneksi untuk digunakan kembali bahkan ketika ukuran dokumen tidak diketahui sebelumnya.
Kompresi Gzip telah ditambahkan

Pada titik ini HTTP telah diambil sejauh mungkin tanpa merusak kompatibilitas.

Anda bukan orang pertama yang menyarankan bahwa halaman dan semua sumber dayanya harus didorong ke klien. Bahkan, Google merancang protokol yang dapat melakukan hal itu disebut SPDY .

Hari ini baik Chrome dan Firefox dapat menggunakan SPDY alih-alih HTTP ke server yang mendukungnya. Dari situs web SPDY, fitur utamanya dibandingkan dengan HTTP adalah:

SPDY memungkinkan klien dan server untuk mengompres header permintaan dan respons, yang mengurangi penggunaan bandwidth ketika header yang sama (misalnya cookie) dikirim berulang-ulang untuk beberapa permintaan.

SPDY memungkinkan beberapa permintaan, secara bersamaan multiplexing melalui satu koneksi, menghemat perjalanan bolak-balik antara klien dan server, dan mencegah sumber daya prioritas rendah dari memblokir permintaan prioritas tinggi.

SPDY memungkinkan server untuk secara aktif mendorong sumber daya ke klien yang ia tahu akan dibutuhkan oleh klien (mis. JavaScript dan file CSS) tanpa menunggu klien untuk memintanya, memungkinkan server untuk menggunakan bandwidth yang tidak digunakan secara efisien.

Jika Anda ingin melayani situs web Anda dengan SPDY untuk browser yang mendukungnya, Anda dapat melakukannya. Misalnya Apache memiliki mod_spdy .

SPDY telah menjadi dasar untuk HTTP versi 2 dengan teknologi server push.

— Stephen Ostermiller
sumber

2

Jawaban bagus dan terinformasi! Browser web bersifat serial dan permintaan dapat dibuat agak cepat. Sekali melihat file log akan menunjukkan bahwa permintaan untuk sumber daya dibuat agak cepat setelah HTML diuraikan. Itu adalah apa adanya. Bukan sistem yang buruk, hanya saja tidak efisien sebagai kode / sumber daya.

— closetnoc

6

Sekadar catatan, SPDY bukanlah cawan suci. Itu melakukan beberapa hal dengan baik, tetapi memperkenalkan masalah lain. Berikut adalah satu artikel yang mengandung beberapa poin yang berbicara tentang SPDY.

— Jost

3

Saya sangat merekomendasikan agar siapa pun yang tertarik dengan hal ini membaca kritik di tautan @Jost. Ini memberi Anda sedikit kerumitan yang terlibat dalam mencari tahu bagaimana melakukan hal yang sangat umum diimplementasikan tidak hanya lebih baik secara bertahap tetapi juga jauh lebih baik sehingga semua orang mulai menggunakannya . Sangat mudah untuk memikirkan perbaikan yang membuat segalanya menjadi lebih baik untuk sebagian besar kasus penggunaan. Untuk membuat segalanya lebih baik sedemikian rupa sehingga setiap orang mulai menggunakan protokol baru Anda karena jauh lebih baik sehingga sepadan dengan biaya perubahan adalah masalah lain sepenuhnya, dan tidak mudah dilakukan.

— msouth

11

dia seharusnya menyerahkan pekerjaan itu kepada para profesional : Jika dia melakukan itu, mereka akan membutuhkan waktu enam tahun untuk menghasilkan standar yang akan usang pada hari keluarnya, dan segera selusin standar yang bersaing akan muncul. Selain itu, apakah para profesional memerlukan izin dari seseorang? Mengapa mereka tidak melakukannya sendiri?

— Shantnu Tiwari

2

Terus terang tidak ada profesional yang memenuhi syarat saat itu. Tidak ada yang tahu bagaimana membangun web di seluruh dunia, karena tidak ada yang pernah membangunnya. Konsep hypermedia tidak ditemukan oleh Tim, ia memiliki pengalaman dengan berbagai sistem hypermedia area lokal sepuluh tahun sebelum ia menulis proposal untuk "Manajemen Informasi" untuk menyelesaikan masalah "kehilangan informasi" di CERN.

— Lie Ryan

14

Peramban web Anda tidak tahu tentang sumber daya tambahan hingga ia mengunduh laman web (HTML) dari server, yang berisi tautan ke sumber daya itu.

Anda mungkin bertanya-tanya, mengapa server tidak mem-parsing HTML-nya sendiri dan mengirim semua sumber daya tambahan ke browser web selama permintaan awal untuk halaman web? Itu karena sumber daya mungkin tersebar di beberapa server, dan peramban web mungkin tidak memerlukan semua sumber daya itu karena sudah ada beberapa dari mereka di-cache, atau mungkin tidak mendukungnya.

Browser web menyimpan cache sumber daya sehingga tidak perlu mengunduh sumber daya yang sama berulang-ulang dari server yang menampungnya. Saat menavigasi halaman berbeda di situs web yang semuanya menggunakan pustaka jQuery yang sama, Anda tidak ingin mengunduh pustaka itu setiap kali, hanya saja pertama kali.

Jadi ketika browser web mendapatkan halaman web dari server, ia memeriksa sumber daya tertaut apa yang sudah TIDAK dimiliki dalam cache, kemudian membuat permintaan HTTP tambahan untuk sumber daya tersebut. Cukup sederhana, sangat fleksibel dan dapat dikembangkan.

Peramban web biasanya dapat membuat dua permintaan HTTP secara paralel. Ini tidak seperti AJAX - keduanya adalah metode asinkron untuk memuat halaman web - memuat file asinkron dan memuat konten asinkron. Dengan tetap-hidup , kita dapat membuat beberapa permintaan menggunakan satu koneksi, dan dengan pipelining kita dapat membuat beberapa permintaan tanpa harus menunggu tanggapan. Kedua teknik ini sangat cepat karena sebagian besar overhead biasanya berasal dari membuka / menutup koneksi TCP:

berusaha agar hidup

perpipaan

Sedikit riwayat web ...

Halaman web dimulai sebagai email teks biasa, dengan sistem komputer yang direkayasa di sekitar gagasan ini, membentuk platform komunikasi yang agak bebas untuk semua; server web masih menjadi hak milik pada saat itu. Kemudian, lebih banyak lapisan ditambahkan ke "spesifikasi email" dalam bentuk tipe MIME tambahan, seperti gambar, gaya, skrip, dll. Lagi pula, MIME adalah kepanjangan dari Internet Mail Extension Multi-Purpose . Cepat atau lambat kami memiliki apa yang pada dasarnya komunikasi email multimedia, server web standar, dan halaman web.

HTTP mengharuskan data ditransmisikan dalam konteks pesan seperti email, meskipun data yang paling sering sebenarnya bukan email.

Sebagai teknologi seperti ini berkembang, itu perlu memungkinkan pengembang untuk secara progresif memasukkan fitur-fitur baru tanpa merusak perangkat lunak yang ada. Misalnya, ketika jenis MIME baru ditambahkan ke spesifikasi - katakanlah JPEG - akan membutuhkan waktu bagi server web dan browser web untuk mengimplementasikannya. Anda tidak hanya tiba-tiba memaksakan JPEG ke dalam spesifikasi dan mulai mengirimnya ke semua browser web, Anda mengizinkan browser web untuk meminta sumber daya yang didukungnya, yang membuat semua orang senang dan teknologi bergerak maju. Apakah pembaca layar membutuhkan semua JPEG di halaman web? Mungkin tidak. Haruskah Anda dipaksa untuk mengunduh banyak file Javascript jika perangkat Anda tidak mendukung Javascript? Mungkin tidak. Apakah Googlebot perlu mengunduh semua file Javascript Anda untuk mengindeks situs Anda dengan benar? Nggak.

Sumber: Saya telah mengembangkan server web berbasis acara seperti Node.js. Ini disebut Server Cepat .

Referensi:

Bacaan lebih lanjut:

— Perry
sumber

Sebenarnya, Kita bisa mengatasi semua masalah sampingan tersebut (hal-hal seperti: Cache, Content-Type header..etc), ada Workarounds untuk menyelesaikan masalah ini. Dan seperti yang saya sarankan di komentar pada posting di atas, Kita dapat menggunakan sesuatu seperti header ini> Cached-Resources: image.jpg; style.css; untuk memecahkan masalah caching .. (Jika Anda punya waktu, maka Anda dapat melihat komentar di atas ..)

— Ahmed

Ya, gagasan itu telah terlintas di benak saya sebelumnya, tetapi terlalu banyak overhead untuk HTTP dan itu tidak memecahkan fakta bahwa sumber daya dapat tersebar di beberapa server. Selain itu, saya tidak berpikir metode penghematan waktu yang Anda usulkan akan benar-benar menghemat waktu karena data akan dikirim sebagai aliran tidak peduli bagaimana Anda melihatnya, dan dengan tetap-hidup, 100 permintaan HTTP simultan pada dasarnya menjadi 1 permintaan. Teknologi dan kemampuan yang Anda usulkan tampaknya sudah ada. Lihat en.wikipedia.org/wiki/HTTP_persistent_connection

— perry

@perry: Apa pendapat Anda tentang gagasan alternatif https://untuk mengirim file-file besar yang didistribusikan secara publik yang perlu diautentikasi tetapi tidak dirahasiakan: sertakan dalam URL bagian-bagian tertentu dari header balasan yang sah, yang pada gilirannya dapat termasuk tanda tangan atau hash dari muatan data, dan sudahkah browser memvalidasi data yang diterima terhadap header? Desain seperti itu tidak hanya akan menyimpan beberapa langkah jabat tangan SSL, tetapi akan lebih penting lagi memungkinkan proxy caching. Dapatkan URL melalui tautan SSL, dan data dapat dimasukkan dari mana saja.

— supercat

11

Karena mereka tidak tahu sumber daya apa itu. Aset yang dibutuhkan halaman web dikodekan ke dalam HTML. Hanya setelah parser menentukan apa aset-aset itu, Anda dapat diminta oleh agen-pengguna.

Selain itu, begitu aset-aset itu diketahui, mereka perlu dilayani secara individual sehingga tajuk yang tepat (yaitu tipe konten) dapat dilayani sehingga agen-pengguna tahu bagaimana menanganinya.

— John Conde
sumber

2

Terutama jika Anda menggunakan sesuatu seperti require.js. Browser hanya menanyakan apa yang dibutuhkannya. Bayangkan harus memuat semuanya sekaligus ...

— Aran Mulholland

2

Ini adalah jawaban yang tepat, dan salah satu yang sebagian besar komentator tampaknya hilang - agar server dapat secara proaktif mengirim sumber daya, perlu mengetahui apa itu, yang berarti server harus mem-parsing HTML.

1

Tetapi pertanyaannya adalah mengapa server web tidak mengirim sumber daya, bukan mengapa klien tidak dapat meminta mereka pada saat yang sama. Sangat mudah untuk membayangkan dunia di mana server memiliki paket aset terkait yang semuanya dikirim bersama yang tidak bergantung pada parsing HTML untuk membangun paket.

— David Meister

@ DavidvidMeister Karena server tidak selalu tahu apa yang diinginkan klien - webcrawler untuk mesin pencari mungkin tidak peduli dengan CSS / JS, dan ada banyak sumber daya lain yang terhubung dalam dokumen di luar itu - tidak perlu mengirim keseluruhan RSS feed dalam paket ke browser web (sebagian besar konten mungkin sudah dalam HTML), sementara pembaca feed mungkin hanya menguraikan <head>elemen mencari tautan alternatif RSS untuk menemukan hal itu - klien dapat mengirim daftar apa yang menarik, tetapi kemudian perlu tahu apa yang tersedia dan kami kembali pada awalnya

— Zhaph - Ben Duguid

@ Zhaph-BenDuguid Saya berbicara tentang dunia alternatif, untuk menegaskan bahwa jawabannya sama dengan bagaimana protokol bekerja seperti yang lainnya. Selain itu, mungkin lebih cepat bagi server untuk mengirim semua data sekaligus bahkan jika itu tidak perlu. Pada dasarnya Anda memperdagangkan masalah latensi terhadap penggunaan bandwidth.

— David Meister

8

Karena, dalam contoh Anda, server web akan selalu mengirim CSS dan gambar terlepas dari apakah klien sudah memilikinya, sehingga sangat membuang bandwidth (dan dengan demikian membuat koneksi lebih lambat , bukannya lebih cepat dengan mengurangi latensi, yang mungkin merupakan niat Anda). Perhatikan bahwa file CSS, JavaScript, dan gambar biasanya dikirim dengan waktu kedaluwarsa yang sangat lama karena alasan itu (seperti ketika Anda perlu mengubahnya, Anda cukup mengubah nama file untuk memaksa salinan baru yang lagi-lagi akan di-cache untuk waktu yang lama).

Sekarang, Anda dapat mencoba mengatasi pemborosan bandwidth dengan mengatakan " OK, tetapi klien dapat mengindikasikan bahwa ia sudah memiliki beberapa sumber daya, sehingga server tidak akan mengirimnya lagi ". Sesuatu seperti:

GET /index.html HTTP/1.1
Host: www.example.com
If-None-Match: "686897696a7c876b7e"
Connection: Keep-Alive

GET /style.css HTTP/1.1
Host: www.example.com
If-None-Match: "70b26618ce2c246c71"

GET /image.png HTTP/1.1
Host: www.example.com
If-None-Match: "16d5b7c2e50e571a46"

Dan kemudian dapatkan hanya file yang tidak berubah yang dikirim melalui satu koneksi TCP (menggunakan pipelining HTTP melalui koneksi persisten). Dan coba tebak? Ini adalah cara yang sudah bekerja (Anda juga bisa menggunakan Jika-Diubah-Sejak bukannya Jika-Tidak-Match ).

Tetapi jika Anda benar-benar ingin mengurangi latensi dengan membuang banyak bandwidth (seperti dalam permintaan awal Anda), Anda dapat melakukannya hari ini menggunakan standar HTTP / 1.1 ketika merancang situs web Anda. Alasan kebanyakan orang tidak melakukannya adalah karena mereka tidak berpikir itu sepadan.

Untuk melakukannya, Anda tidak perlu memiliki CSS atau JavaScript dalam file terpisah, Anda dapat memasukkannya ke dalam file HTML utama dengan menggunakan <style>dan <script>tag (Anda mungkin bahkan tidak perlu melakukannya secara manual, mesin template Anda mungkin dapat melakukannya secara otomatis) . Anda bahkan dapat memasukkan gambar dalam file HTML menggunakan data URI , seperti ini:

<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />

Tentu saja, pengkodean base64 sedikit meningkatkan penggunaan bandwidth, tetapi jika Anda tidak peduli dengan bandwidth yang terbuang, itu seharusnya tidak menjadi masalah.

Sekarang, jika Anda benar-benar peduli, Anda bahkan dapat membuat skrip web Anda cukup pintar untuk mendapatkan yang terbaik dari kedua dunia: berdasarkan permintaan pertama (pengguna tidak memiliki cookie), kirim semuanya (CSS, JavaScript, gambar) yang disematkan hanya dalam satu HTML tunggal file seperti dijelaskan di atas, tambahkan tautan tautan = "prefetch" untuk salinan eksternal file, dan tambahkan cookie. Jika pengguna sudah memiliki cookie (mis. Dia telah mengunjungi sebelumnya), maka kirimkan dia hanya HTML biasa dengan <img src="example.jpg">, <link rel="stylesheet" type="text/css" href="style.css">dll.

Jadi pada kunjungan pertama browser akan meminta hanya satu file HTML dan mendapatkan dan menampilkan semuanya. Maka akan (saat idle) memuat gambar CSS, JS, eksternal yang ditentukan. Kali berikutnya pengguna mengunjungi, browser akan meminta dan hanya mendapatkan sumber daya yang diubah (mungkin hanya HTML baru).

Data gambar CSS + JS + tambahan hanya akan dikirim dua kali, bahkan jika Anda mengklik ratusan kali di situs web. Jauh lebih baik daripada ratusan kali seperti yang disarankan solusi Anda. Dan itu tidak akan pernah (bukan pada pertama kali, atau pada kali berikutnya) menggunakan lebih dari satu perjalanan pulang-pergi latensi yang meningkat.

Sekarang, jika itu terdengar seperti terlalu banyak pekerjaan, dan Anda tidak ingin menggunakan protokol lain seperti SPDY , sudah ada modul seperti mod_pagespeed untuk Apache, yang secara otomatis dapat melakukan beberapa pekerjaan itu untuk Anda (menggabungkan beberapa file CSS / JS menjadi satu, masukkan CSS kecil secara otomatis dan minimalkan, buat gambar placeholder kecil bergaris sambil menunggu dokumen asli dimuat, malas memuat gambar dll.) tanpa mengharuskan Anda memodifikasi satu baris halaman web Anda.

— Matija Nalis
sumber

3

Saya rasa ini adalah yang jawaban yang benar.

— el.pescado

7

HTTP2 didasarkan pada SPDY dan melakukan persis apa yang Anda sarankan:

Pada level tinggi, HTTP / 2:

biner, bukan tekstual

sepenuhnya multiplexing, bukannya dipesan dan diblokir

Karena itu dapat menggunakan satu koneksi untuk paralelisme

menggunakan kompresi tajuk untuk mengurangi overhead

memungkinkan server untuk "mendorong" respons secara proaktif ke dalam cache klien

Lebih banyak tersedia di HTTP 2 Faq

— MaBu
sumber

3

Karena tidak menganggap bahwa hal-hal ini sebenarnya diperlukan .

Protokol tidak mendefinisikan penanganan khusus untuk jenis file atau agen-pengguna tertentu. Itu tidak tahu perbedaan antara, katakanlah, file HTML dan gambar PNG. Untuk melakukan apa yang Anda minta, server Web harus mengidentifikasi jenis file, menguraikannya untuk mencari tahu file apa yang dirujuk, dan kemudian menentukan file lain yang benar-benar diperlukan, mengingat apa yang ingin Anda lakukan dengan file . Ada tiga masalah besar dengan ini.

Masalah pertama adalah bahwa tidak ada standar, cara kuat untuk mengidentifikasi tipe file di ujung server . HTTP mengelola melalui mekanisme Tipe-Konten, tetapi itu tidak membantu server, yang harus memikirkan hal ini sendiri (sebagian sehingga ia tahu apa yang harus dimasukkan ke dalam Tipe-Konten). Ekstensi nama file didukung secara luas, tetapi rapuh dan mudah dibodohi, terkadang untuk tujuan jahat. Metadata Filesystem kurang rapuh, tetapi kebanyakan sistem tidak mendukungnya dengan baik, sehingga server bahkan tidak repot. Mengendus konten (seperti yang filecoba dilakukan beberapa browser dan perintah Unix ) bisa menjadi kuat jika Anda bersedia membuatnya mahal, tetapi mengendus yang kuat terlalu mahal untuk praktis di sisi server, dan mengendus murah tidak cukup kuat.

Masalah kedua adalah parsing file itu mahal, secara komputasi . Ini terkait dengan yang pertama, karena Anda perlu mem-parsing file dalam banyak cara berbeda jika Anda ingin mengendus konten dengan kuat, tetapi itu juga berlaku setelah Anda mengidentifikasi jenis file, karena Anda perlu untuk mencari tahu apa referensi tersebut. Ini tidak terlalu buruk ketika Anda hanya melakukan beberapa file sekaligus, seperti browser, tetapi server Web harus menangani ratusan atau ribuan permintaan sekaligus. Ini bertambah, dan jika terlalu jauh, sebenarnya dapat memperlambat segalanya lebih dari beberapa permintaan. Jika Anda pernah mengunjungi tautan dari Slashdot atau situs serupa, hanya untuk mengetahui bahwa server sangat lambat karena penggunaan yang tinggi, Anda telah melihat prinsip ini sedang beraksi.

Masalah ketiga adalah bahwa server tidak memiliki cara untuk mengetahui apa yang ingin Anda lakukan dengan file tersebut . Browser mungkin memerlukan file yang direferensikan dalam HTML, tetapi mungkin tidak, tergantung pada konteks yang tepat di mana file sedang dieksekusi. Itu akan cukup rumit, tetapi ada lebih banyak di Web daripada hanya peramban: antara laba-laba, agregator umpan, dan penghancuran halaman, ada banyak jenis agen-pengguna yang tidak memerlukan file yang direferensikan dalam HTML : mereka hanya peduli tentang HTML itu sendiri. Mengirim file-file ini ke agen-pengguna seperti itu hanya akan membuang-buang bandwidth.

Intinya adalah bahwa mencari tahu dependensi ini di sisi server lebih banyak masalah daripada nilainya . Jadi alih-alih, mereka membiarkan klien mencari tahu apa yang dibutuhkan.

— Spooniest
sumber

Jika kita akan mengembangkan protokol baru atau untuk memperbaiki yang sudah ada, Kita dapat menangani semua masalah ini dengan satu atau lain cara! Dan server web akan mem-parsing file hanya untuk satu kali dan kemudian dapat mengklasifikasikannya tergantung pada aturan yang ditentukan sehingga dapat memprioritaskan file mana yang akan dikirim terlebih dahulu .. dll dan server web tidak harus tahu apa yang harus saya lakukan dengan file-file itu, Itu hanya harus tahu apa yang harus dikirim, Kapan harus dilakukan dan tergantung pada aturan mana .. (bot web dan spider bukan masalah, perilaku akan berbeda dengan mereka -mereka memiliki header agen-pengguna unik- ..)

— Ahmed

@AhmedElsobky: Apa yang Anda bicarakan terdengar lebih seperti implementasi spesifik daripada protokol jaringan. Tapi itu benar-benar harus tahu apa yang ingin Anda lakukan dengan file sebelum dapat menentukan apa yang harus dikirim: jika tidak, ia pasti akan mengirim file yang tidak diinginkan banyak pengguna. Anda tidak dapat mempercayai string Agen-Pengguna, jadi Anda tidak dapat menggunakannya untuk menentukan apa maksud pengguna.

— The Spooniest