وب مدرن، رابط کاربری و تجربه‌ی وب · فصل ۱ — مرورگر، سرور، رندر و معماری صفحه · 28
وقتی یک آدرس سایت را در مرورگر باز می‌کنیم چه اتفاقی می‌افتد؟
_Locale: fa-IR · Lesson: WEBF-001 · Public order: 28_
From URL to Page: What Happens When You Open a Web Address? — en-US
پیش‌نیازها
_Locale: fa-IR · Lesson: WEBF-001 · Public order: 28_
خروجی و artifact کاری
این درس برای ساختن رکورد مسیر پیمایش وب نسخه ۱ است: یک artifact تصمیم که مشاهده، فرض، محدودیت و evidence موردنیاز را از هم جدا می‌کند. هدف حفظ یک مدل قابل‌انتقال است، نه حفظ‌کردن نام ابزارها.
Given an unfamiliar web-navigation scenario, explain a bounded request/response and rendering flow, place each responsibility at browser/network/server boundaries, and state what the model does not prove.
مدل مرزی
واردکردن یک URL در ظاهر یک کار ساده است، اما مسئولیت میان چند مرز جابه‌جا می‌شود: تفسیر URL، نام‌یابی احتمالی، ساخت اتصال، تبادل HTTP، کشف منابع وابسته و رندر مرورگر. مدل مفید یک ردگیری اجباری و همیشگی از بسته‌های شبکه نیست؛ نقشه‌ای محدود است که می‌گوید هر مرحله ممکن است کجا انجام شود، مالک آن کیست و برای اثبات مسیر واقعی چه مشاهده‌ای لازم است.
در هر بخش سه برچسب نگه دارید: «مشاهده‌شده»، «استنباط محدود» و «نیازمند بررسی». اگر evidence در دسترس نیست، نتیجه را unknown ثبت کنید؛ نام ابزار یا pass شدن یک happy path جای evidence را نمی‌گیرد.
1. URL دستور پیمایش است، نه خود صفحه
مرورگر scheme، host، port، path، query و fragment را تفسیر می‌کند. fragment معمولاً در سمت کاربر مدیریت می‌شود و جزئی از request target ارسالی نیست. URL مقصد را معرفی می‌کند، اما تضمین نمی‌کند byteها دقیقاً از کجا برسند.
2. نام‌یابی شرطی است
ممکن است نشانی قابل استفاده از قبل در cache محلی یا یک واسط موجود باشد. مراجعه به resolver محتمل است، اما lookup تازه‌ی DNS قانون همیشگی نیست. در رکورد خود مشخص کنید نام‌یابی مشاهده شده، cached بوده یا نامعلوم است.
3. پاسخ ممکن است از مسیر واسط برسد
مرورگر می‌تواند connection را reuse کند، HTTP cache یا service worker را ببیند، redirect را دنبال کند یا پیش از origin به CDN و proxy برسد. پس ارتباط مستقیم با origin یک ادعای نیازمند evidence است.
4. یک document می‌تواند fetchهای متعدد بسازد
مرورگر پس از دریافت HTML آن را parse می‌کند و ممکن است stylesheet، script، font، image و moduleهای دیگری کشف کند. هر منبع می‌تواند cache، origin، priority و failure mode متفاوتی داشته باشد.
5. موفقیت پروتکل مساوی درستی محصول نیست
کد 200 یعنی request از دید HTTP پاسخ موفق گرفته است. این کد ثابت نمی‌کند داده‌ی درست نمایش یافته، script اجرا شده، accessibility مناسب است یا رابط کاربری requirement محصول را برآورده کرده است.
روش پنج‌مرحله‌ای
- URL را تجزیه کنید و state مخصوص مرورگر را از request target شبکه جدا نگه دارید.
- کارهای شرطی پیش از request را ثبت کنید: policy، cache، service worker، نام‌یابی، connection و وضعیت TLS.
- request اصلی و هر redirect را exchange جدا ثبت کنید و همه را در یک فلش فشرده نکنید.
- document response، parsing، منابع وابسته، اجرای script، layout، paint و updateهای بعدی را مسئولیت‌های مجزا ببینید.
- در پایان non-claimها را بنویسید؛ مشخص کنید بدون DevTools، log سرور، evidence cache یا check سطح application چه چیزی ثابت نمی‌شود.
مثال حل‌شده
کاربر https://docs.example.test/start#install را باز می‌کند. پاسخ اول 302 و مقصد آن /guide است. HTML مقصد از cache واسط می‌آید، یک stylesheet تازه fetch می‌شود و image از cache محلی استفاده می‌شود. fragment پس از آماده‌شدن document روی heading اثر می‌گذارد. توضیح قابل دفاع redirect، cache stateهای مشاهده‌شده و requestهای جدا را ثبت می‌کند؛ اما lookup تازه DNS یا ارسال HTML از origin را اختراع نمی‌کند. محدودیت DevTools نیز باید در رکورد بماند.
ماتریس تصمیم و evidence
| موضوع | مرز/مالک | evidence | تصمیم یا محدودیت |
|---|---|---|---|
| تفسیر URL | مرورگر | scheme/host/path/fragment تجزیه شد | fragment state سمت کاربر است |
| نام‌یابی | مرورگر/سیستم‌عامل/resolver | در این capture مشاهده نشد | ممکن است cached باشد |
| HTTP redirect | client و server پاسخ‌دهنده | 302 و سپس request دوم | هر hop جداست |
| document و منابع | cache/واسط/origin/مرورگر | evidence شبکه برای هر resource | منبع‌ها ممکن است متفاوت باشند |
| رندر | مرورگر | مشاهده DOM/style/layout/paint | درستی معنایی را ثابت نمی‌کند |
خطاهای محتمل و روش اصلاح
- فرض lookup تازه‌ی DNS برای هر پیمایش
- فرض ارتباط مستقیم همه‌ی requestها با origin
- یکی‌گرفتن status موفق HTTP با درستی محصول
برای هر مورد، ادعا را محدود کنید، یک counterexample بسازید و بنویسید کدام مشاهده می‌تواند آن را تأیید یا رد کند.
تمرین انتقال
سناریو را طوری تغییر دهید که یکی از فرض‌های مثال دیگر برقرار نباشد. بدون کپی‌کردن تصمیم قبلی، رکورد مسیر پیمایش وب نسخه ۱ را دوباره بسازید؛ سپس تفاوت decision rule و تفاوت دادهٔ ورودی را توضیح دهید.
این درس چه چیزی را ثابت نمی‌کند
این درس certification، تضمین production یا پوشش همه implementationها را ادعا نمی‌کند. نتیجه فقط در مرز سناریو، sourceهای تاریخ‌دار و observationهای ثبت‌شده معتبر است.
خودسنجی
- [ ] آیا مسئولیت‌ها را از نام framework یا tool جدا کرده‌ام؟
- [ ] آیا دست‌کم یک failure probe و نتیجه موردانتظار آن را نوشته‌ام؟
- [ ] آیا fact، inference و design choice از هم مشخص‌اند؟
- [ ] آیا non-claim و evidence گمشده را ثبت کرده‌ام؟
- [ ] آیا transfer را روی context تغییرکرده و بدون پاسخ آماده انجام داده‌ام؟
منابع و مرز تازگی
sourceها در 2026-09-19 طبق Bible منجمدشده مرور شده‌اند. تاریخ review_due یک trigger برای بازبینی نسخه‌ای است؛ هیچ بسته‌ای نباید درجا و بدون نسخه جدید تغییر کند.
- S-MDN-WEB — High-level client/server, DNS and HTTP navigation model. (https://developer.mozilla.org/en-US/docs/Learn_web_development/Getting_started/Web_standards/How_the_web_works; review: 2026-12-31)
- S-WHATWG-DOC — HTML Document and URL semantics; not a universal browser implementation trace. (https://html.spec.whatwg.org/multipage/dom.html; review: 2026-12-31)
ارزیابی
پاسخ‌نامه‌ی این درس در بسته‌ی آموزش وجود ندارد؛ خودت جواب بده و صادقانه علامت بزن. «نیاز به مرور» درس را به صف تکرار می‌فرستد.
WEBF-001-SUM1 retrieval
WEBF-001-SUM2 application
WEBF-001-SUM3 diagnosis
WEBF-001-SUM4 decision
WEBF-001-SUM5 transfer
ملاک‌های ارزیابی (rubric)
| Dimension | Critical | Sufficient evidence |
|---|---|---|
| boundary_accuracy | yes | Responsibilities in navigation journey are placed at the correct bounded layer/time/location and adjacent lessons are not absorbed. |
| evidence_and_uncertainty | yes | Current factual claims are source-bounded; conditional paths and unknowns are stated rather than guessed. |
| decision_quality | yes | The decision recorded in Web Navigation Journey Record v1 follows from the scenario constraints and states what would invalidate it. |
| transfer | no | The learner applies the same reasoning in a changed scenario without copying a fixed stack answer. |
A submission passes only when every critical dimension is sufficient and the learner states missing evidence honestly. AI suggestions are not observed evidence; the learner remains accountable for the final bounded judgment.
منابع و تازگی
مطالعهٔ موارد (case studies)
رسانه و اسلایدهای درس
فایل‌های آموزشی (دانلود)