‏چرا fetch به کدهای خطا نیاز داره

تو این مقاله اومده که استاندارد Fetch عمداً اطلاعات خطا رو دور می‌ندازه: وقتی یه fetch() به‌خاطر مشکل شبکه شکست می‌خوره، همهٔ حالت‌ها — خطای DNS، خطای دست‌دادن TLS، رد شدن اتصال، ریست‌شدن استریم توسط سرور، حلقهٔ ریدایرکت یا آفلاین‌بودن کلاینت — یه TypeError یکسان تولید می‌کنن که نه code داره، نه reason و نه هیچ متادیتای پروتکلی.

به گفتهٔ نویسنده تو مرورگر این کدربودن یه ویژگی امنیتی لازمه؛ اگه دلیل شکست یه درخواست cross-origin لو می‌رفت، می‌شد زیرساخت مقصد رو کاوش کرد: هاست resolve می‌شه؟ TLS تنظیم شده؟ فلان پورت بازه؟ ولی همین منطق باعث می‌شه سیگنال‌های معنادار HTTP/2 و HTTP/3 هم قربانی بشن.

HTTP/2 با فریم RST_STREAM و HTTP/3 با RESET_STREAM و STOP_SENDING کد خطای مشخص می‌فرستن. مهم‌ترینشون REFUSED_STREAM و معادل HTTP/3ـیش H3_REQUEST_REJECTED هست که طبق RFC 9113 یعنی سرور اصلاً درخواست رو پردازش نکرده و حتی متدهای غیرidempotent مثل POST رو می‌شه با خیال راحت دوباره فرستاد. تو fetch این تضمین از بین می‌ره، چون همون TypeError خطای DNS رو تحویل می‌گیرین.

پیشنهاد نویسنده که خودش تو TC39 ازش دفاع می‌کنه، اضافه‌کردن یه پراپرتی استاندارد code به Errorـه — تو همون آبجکت options که cause تو ES2022 بهش اضافه شد. این پروپوزال الان Stage 1ـه و برای رفتن به Stage 2.7 بررسی می‌شه. به گفتهٔ خودش اکوسیستم از قبل این الگو رو پذیرفته: نودجی‌اس بیش از ۲۰۰ کد مستندِ ERR_* داره و Deno و Bun و کتابخونه‌هایی مثل axios و Stripe و Prisma هم code رو روی خطاهاشون می‌ذارن.

اگه TypeError بتونه code حمل کنه، Fetch می‌تونه بدون اضافه‌کردن نوع خطای جدید یا تغییر مدل پرامیس، تاکسونومی‌ای مثل ERR_HTTP_REQUEST_REJECTED و ERR_HTTP_GOAWAY رو منتقل کنه و کدی که code رو چک نمی‌کنه اصلاً تغییری حس نمی‌کنه. نویسنده اضافه می‌کنه که کدهای سطح استریم امن‌ان، چون بعد از برقراری اتصال و به‌خواست خود سرور فرستاده می‌شن، ولی کدهای پیش از اتصال مثل خطای DNS یا TLS باید تو درخواست‌های cross-origin مخفی بمونن.

نکات کلیدی:

• استاندارد Fetch همهٔ خطاهای شبکه رو به یه TypeError بدون جزئیات تبدیل می‌کنه
• کدهای RST_STREAM در HTTP/2 و RESET_STREAM/STOP_SENDING در HTTP/3 معنای عملی دارن
• REFUSED_STREAM یعنی درخواست پردازش نشده و امنه دوباره فرستاده بشه
• پروپوزال TC39 برای پراپرتی code روی Error تو Stage 1ـه و دنبال Stage 2.7ـه
• کدهای پیش از اتصال مثل DNS و TLS باید تو درخواست‌های cross-origin مخفی بمونن