HTTP چیست به زبان ساده؟ خطای 404، 500، کوکی و CORS

۴۰۴. ۵۰۰. ۴۰۳. یا اون پیام قرمز و طولانی که وسطش نوشته CORS. اگه با ایجنت‌ها (Agent) چیزی ساخته باشین، حتماً این‌ها رو دیدین. ولی هر کدوم از این عددها، یه جملهٔ کامله که سرور داره به شما می‌گه. فقط باید بلد باشین بخونینش. تا آخر همین ویدیو بهتون قول می‌دم: می‌بینین توی یه درخواست HTTP دقیقاً چی نوشته شده؛ همهٔ کدهای وضعیت رو بدون حفظ کردن می‌خونین؛ می‌فهمین سایت از کجا یادش می‌مونه شما کی هستین؛ می‌فهمین قفل کنار آدرس واقعاً یعنی چی، و چی نیست؛ خطای CORS رو از ریشه درست می‌کنین؛ و آخر ویدیو، یه ترفند نشونتون می‌دم که با یه کلیک، خودِ درخواستِ خراب رو برای ایجنت می‌نویسه. بریم که شروع کنیم!

توی قسمت قبل دیدیم یه وب‌اپ چطوری کار می‌کنه، و قول دادیم بریم سراغ HTTP: زبونی که مرورگر و سرور باهاش حرف می‌زنن. هر بار که کلاد کد (Claude Code)، کدکس (Codex) یا آنتی‌گرویتی (Antigravity: ابزار گوگل) یه صفحه، یه فرم یا یه اتصال به ای‌پی‌آی (API: راه وصل شدن برنامه‌ها) براتون می‌سازه، پشتش HTTP هست. و وقتی چیزی کار نمی‌کنه، جوابش تقریباً همیشه همین‌جا نوشته شده. توی این ویدیو قدم به قدم می‌ریم جلو: یه درخواست و یه پاسخ رو خط به خط می‌خونیم، بعد کدهای وضعیت، کوکی، کش، HTTPS، خطای CORS و اشتباه‌های رایج؛ و آخرش، یه خطای واقعی رو از مرورگر تا ایجنت دنبال می‌کنیم.

خب، HTTP چیه؟ HTTP یه قرارداده؛ قانون اینکه مرورگر و سرور چطوری با هم حرف بزنن. مخفف چهار کلمهٔ انگلیسیه، یعنی «قرارداد انتقال ابرمتن». ولی بیاین با یه تصویر ساده بفهمیمش، چون تا آخر ویدیو باهامون هست. هر درخواست HTTP مثل یه نامه‌ست. روی پاکت، آدرس گیرنده و چند تا یادداشت کوچیک؛ توی پاکت، گاهی خودِ نامه. مرورگر نامه رو می‌فرسته، سرور می‌خونه، و یه نامهٔ جواب برمی‌گردونه، با یه مُهر بالاش که می‌گه کار انجام شد یا نه. یادتونه گارسون قسمت ای‌پی‌آی؟ برگهٔ سفارشی که دستشه، با همین قانون نوشته می‌شه.

دو تا قانون هم داره. یک: همیشه مرورگر شروع می‌کنه؛ سرور تا نامه نگیره، چیزی نمی‌فرسته. دو: سرور هیچ نامه‌ای رو یادش نمی‌مونه؛ هر نامه براش تازه‌ست، انگار اولین باره شما رو می‌بینه. توی قدم کوکی دوباره به این می‌رسیم. و یه صفحه، فقط یه نامه نیست. برای خودِ صفحه، هر عکس، هر فونت و هر فایل، یه نامهٔ جدا می‌ره؛ گاهی صد تا یا بیشتر. توی مرورگر، بخش Network رو که قسمت قبل دیدیم باز کنین، و صفحه رو رفرش کنین: هر خط، یه نامه‌ست. یه درخواست HTTP واقعاً چه شکلیه؟ بیاین یکی از این نامه‌ها رو باز کنیم.

فرض کنین یه اپ لیست کارها روی کامپیوتر خودتون دارین، و صفحه فهرست کارها رو می‌خواد. نامه‌ای که مرورگر می‌فرسته، واقعاً همین چند خط متنه. خط اول، مهم‌ترین خطه: متد، مسیر، و نسخهٔ HTTP. اینجا GET، یعنی بگیر؛ و مسیر، /api/todos. بعد header ها میان؛ همون یادداشت‌های روی پاکت. هر خط یه اسم، یه دونقطه، و یه مقدار. اولیش Host هست: این نامه مال کدوم سایته؛ اینجا localhost، پورت سه‌هزار. بعد یه خط خالی، یعنی یادداشت‌ها تموم شد. و اگه نامه چیزی برای فرستادن داشته باشه، مثلاً یه کار جدید با POST، بعد از خط خالی میاد، به اسم بدنه.

نسخه‌های جدیدتر، HTTP دو و HTTP سه، همین نامه رو فشرده‌تر بسته‌بندی می‌کنن و چند تا رو با هم می‌فرستن، تا سایت سریع‌تر باز بشه. ولی محتوای نامه همونه، و انتخابش هم با مرورگر و سروره، نه شما. پس هر چی امروز یاد می‌گیرین، برای هر سه نسخه درسته. نامهٔ جواب هم همین شکلیه؛ فقط خط اولش فرق داره: نسخه، یه عدد سه‌رقمی، و یکی دو کلمه کنارش، مثلاً ۲۰۰، OK. این عدد همون مُهر بالای نامه‌ست، به اسم کد وضعیت. بعد header های جواب میان، و یکیش خیلی گره‌ها رو باز می‌کنه: Content-Type.

می‌گه چیزی که توی پاکته از چه نوعیه: یه صفحهٔ HTML، یه عکس، یا JSON. کد شما از روی همین می‌فهمه نامه رو چطوری بخونه. و یه خطای معروف که حتماً یه بار می‌بینینش: «unexpected token»، با یه علامت کوچیک‌تر. یعنی کد منتظر JSON بود، ولی یه صفحهٔ HTML گرفت؛ و اون علامت، اولین حرف همون صفحه‌ست. معمولاً یعنی آدرس درخواست اشتباهه، و سرور به جای جواب، یه صفحهٔ HTML فرستاده؛ مثلاً صفحهٔ «پیدا نشد»، یا صفحهٔ خطا. پس دنبال ایراد JSON نگردین؛ اول ببینین درخواست کجا رفته، و چه کدی گرفته.

header ها شاید به چشم نیان، ولی کلی کار می‌کنن. Host، یعنی نامه مال کدوم سایته. Content-Type، نوع چیزی که توی پاکته. Accept، اینکه مرورگر چه جوابی رو بلده بخونه. و User-Agent، که مرورگر خودش رو معرفی می‌کنه. و یکی که قسمت ای‌پی‌آی دیدیم: Authorization؛ کلید یا توکن (Token) شما، که نشون می‌ده کی داره درخواست می‌ده. قانون طلاییش اینه: کلید توی header، نه توی خودِ آدرس. آدرس توی تاریخچهٔ مرورگر می‌مونه، توی لاگ سرورها ثبت می‌شه، و هر کی اسکرین‌شاتش رو ببینه، کلید رو هم دیده.

پس اگه ایجنت کلید رو ته آدرس، بعد از علامت سؤال گذاشته، و اون سرویس اجازه می‌ده، ازش بخواین ببرتش توی header. دو تای دیگه رو هم جلوتر می‌بینیم: Location برای ریدایرکت، و کوکی برای اینکه سایت یادش بمونه شما کی هستین. کدهای وضعیت؛ همون مُهر بالای نامهٔ جواب. ده‌ها کد هست، ولی لازم نیست حتی یکیش رو حفظ کنین. فقط رقم اولش رو بخونین. با دو شروع بشه، یعنی «انجام شد». با سه، یعنی «اینجا نیست، برو اون‌جا». با چهار، یعنی «درخواست شما ایراد داره». با پنج، یعنی «سرور خودش به مشکل خورده».

یه دستهٔ یک هم هست، که فقط یه پیام وسط راهه، و تقریباً هیچ‌وقت نمی‌بینینش. پس اگه یه خطای چهارصد و خرده‌ای گرفتین، اول درخواست خودتون رو چک کنین: آدرس، کلید، و داده‌ای که فرستادین. اگه پونصد و خرده‌ای بود، باید رفت سراغ سرور. همین یه قانون، جواب سؤالیه که خیلی‌ها می‌پرسن: «تقصیر منه، یا سایت؟». و یه کد بامزه هم هست: ۴۱۸، یعنی «من یک قوری هستم»! از یه شوخی روز اول آوریل اومده، و حالا رسماً کنار گذاشته شده. ۲۰۰ یعنی همه‌چی درسته. دو تا کد دیگه هم توی این دسته زیاد می‌بینین: ۲۰۱، یعنی «ساخته شد»، مثلاً وقتی یه کار جدید ثبت می‌کنین؛ و ۲۰۴، یعنی «انجام شد، ولی چیزی برای برگردوندن ندارم»، مثلاً بعد از پاک کردن.

سیصدها ریدایرکت‌ان: سرور می‌گه «این آدرس عوض شده»، و توی یه header به اسم Location، آدرس جدید رو می‌ده. مرورگر هم خودش می‌ره اون‌جا. ۳۰۱ یعنی «برای همیشه»، و ۳۰۲ یعنی «فعلاً». و این فرق مهمه: مرورگر ۳۰۱ رو یادش نگه می‌داره. اگه یه ریدایرکت دائمی رو اشتباه بذارین، حتی بعد از درست کردنش، مرورگر خودتون ممکنه هنوز به جای اشتباه بره. پس موقع امتحان کردن، ریدایرکت موقت بذارین. و یه خطای معروف: «too many redirects». یعنی دو تا آدرس دارن همدیگه رو به هم پاس می‌دن؛ مثلاً داشبورد کاربر رو به صفحهٔ ورود می‌فرسته، و صفحهٔ ورود، چون فکر می‌کنه کاربر وارد شده، برش می‌گردونه به داشبورد.

همین‌طوری به ایجنت بگینش؛ کار رو براش خیلی راحت می‌کنه. حالا مهم‌ترین دسته برای ما: چهارصدها. سرور درخواست رو گرفته، ولی یه ایرادی توشه. ۴۰۰ یعنی درخواست خراب یا ناقصه؛ مثلاً یه فیلد لازم رو نفرستادین، یا JSON درست نوشته نشده. ۴۰۱ و ۴۰۳ رو قسمت ای‌پی‌آی دیدیم؛ با پاکت نامه این‌طوری می‌شن. ۴۰۱ یعنی «نمی‌دونم تو کی هستی»: کارت شناسایی همراه نامه نیست، یا باطله. ۴۰۳ یعنی «می‌دونم کی هستی، ولی اجازهٔ این کار رو نداری». ۴۰۴ یعنی این آدرس پیدا نشد. چرا تقصیر درخواسته؟ چون سرور سالمه؛ شما چیزی رو خواستین که وجود نداره.

امتحانش ساده‌ست: ته آدرس یه سایت یه چیز بی‌معنی بنویسین، و توی Network، ۴۰۴ رو ببینین. ۴۰۵ کمتر شناخته شده‌ست، ولی خیلی به کار میاد: آدرس درسته، ولی متدش نه؛ مثلاً با POST سراغ آدرسی رفتین که فقط GET قبول می‌کنه. و ۴۲۹: زیادی درخواست دادین؛ یه کم صبر کنین.

و پونصدها: درخواست شما رسیده، ولی سرور نتونسته درست جوابش رو بده. ۵۰۰ یعنی یه جای کد backend خطا داده. و نکتهٔ اصلی: مرورگر دلیلش رو نمی‌دونه. دلیل واقعی توی ترمینال (Terminal: جای تایپ دستور) یا لاگ backend نوشته شده. پس به ایجنت نگین «صفحه خطا می‌ده»؛ چند خط آخر ترمینال backend رو کپی کنین و بهش بدین. حتی اگه داده‌تون ایراد داشته، یه backend خوب باید با یه ۴۰۰ جواب بده، نه ۵۰۰. بقیه‌شون رو بیشتر وقتی اپ روی اینترنته می‌بینین. ۵۰۲ و ۵۰۴ یعنی یه سرور واسطه جلوی اپ شما، از اپ پشتش جواب بد گرفته، یا به موقع جوابی نگرفته؛ اغلب یعنی اپ خاموشه، یا خیلی کنده.

و ۵۰۳ یعنی سرور فعلاً در دسترس نیست؛ شلوغه، یا در حال تعمیره. یادتونه گفتیم سرور هیچ نامه‌ای رو یادش نمی‌مونه؟ پس چطوری وقتی وارد یه سایت می‌شین، توی صفحهٔ بعد هنوز وارد هستین؟ جوابش کوکیه. وقتی رمزتون رو درست می‌زنین، سرور توی جواب یه header به اسم Set-Cookie می‌فرسته: یه کد طولانی، مثل یه کارت عضویت. مرورگر کارت رو نگه می‌داره، و به هر نامهٔ بعدی برای همون سایت، خودش سنجاقش می‌کنه، توی یه header به اسم کوکی. سرور کارت رو می‌بینه، و می‌فهمه این همون کاربره.

برای همین کوکی ورود، به اندازهٔ رمزتون ارزش داره، و سه تا تنظیم داره: HttpOnly، که کد صفحه نتونه بخوندش؛ Secure، که فقط روی HTTPS بِره؛ و SameSite، که وقتی یه سایت دیگه درخواستی به سمت سایت شما راه می‌ندازه، کوکی همراهش نره. پس به ایجنت بگین: «کوکی ورود رو با این سه تا تنظیم بساز». و اون پنجرهٔ «پذیرش همه»؟ کوکی‌هایی که سایت برای کار کردن لازم داره، معمولاً ربطی به اون پنجره ندارن. «پذیرش همه» معمولاً یعنی اجازه به کوکی‌های آمار و تبلیغات، که گاهی مال شرکت‌های دیگه‌ان و شما رو بین سایت‌ها دنبال می‌کنن.

یه موقعیت آشنا: به ایجنت می‌گین رنگ دکمه رو عوض کن، می‌گه «انجام شد»، صفحه رو باز می‌کنین، و هیچی عوض نشده. خیلی وقت‌ها ایراد از ایجنت نیست؛ از کش هست. مرورگر، برای اینکه سایت‌ها سریع باز بشن، یه کپی از جواب‌ها رو نگه می‌داره؛ مثل کپی یه نامه توی کِشوی خودتون. اگه سرور با یه header به اسم Cache-Control گفته باشه این کپی هنوز تازه‌ست، دفعهٔ بعد اصلاً نامه نمی‌فرسته. گاهی هم می‌پرسه «نسخهٔ من هنوز همونه؟»، و سرور فقط می‌گه: ۳۰۴، یعنی «عوض نشده، از کپی خودت استفاده کن».

پس ۳۰۴ توی Network خطا نیست؛ سرعته. وقتی تغییری رو نمی‌بینین، اول یه بار بدون کش بارگذاری کنین: روی Windows، Ctrl و Shift و R؛ روی Mac، Command و Shift و R. یا توی Network، تیک Disable cache رو بزنین. اگه باز هم عوض نشده بود، اون موقع برین سراغ ایجنت. HTTPS، و اون قفل کنار آدرس؛ واقعاً یعنی چی؟ HTTPS همون HTTP هست، داخل یه لایهٔ امن به اسم TLS. SSL هم که شنیدین، اسم قدیمی همینه. HTTPS سه تا کار می‌کنه. یک: نامه رو قفل می‌کنه. کسی که وسط راهه، مثلاً روی وای‌فای یه کافه، فقط می‌بینه با کدوم سایت حرف می‌زنین، نه اینکه چی می‌گین.

دو: اگه کسی وسط راه نامه رو دستکاری کنه، معلوم می‌شه. سه: سایت یه کارت شناسایی داره، به اسم گواهی، که نشون می‌ده واقعاً صاحب همون دامنه‌ست. ولی قفل تضمین نمی‌کنه که خودِ سایت آدم درستی باشه. سایت‌های کلاهبرداری هم HTTPS دارن؛ تقریباً همه‌شون. برای همین Chrome از سال دو هزار و بیست و سه، قفل رو برداشت و یه آیکون تنظیمات جاش گذاشت، چون خیلی‌ها قفل رو با «این سایت امنه» اشتباه می‌گرفتن. پس قفل یعنی «راه امنه»، نه «مقصد». برای اپ خودتون: localhost روی HTTP ساده هست، و برای کار روی کامپیوتر خودتون اشکالی نداره؛ ولی اپی که روی اینترنته، باید HTTPS باشه.

و اگه یه صفحهٔ HTTPS از یه آدرس HTTP ساده چیزی بخواد، مرورگر جلوش رو می‌گیره. پس اگه بعد از بردن اپ روی اینترنت، یه درخواست یهو کار نکرد، اول ببینین آدرسش HTTPS هست یا نه.

و حالا خطایی که تقریباً هر وایب‌کدری یه بار بهش خورده: CORS. یه پیام قرمز و طولانی توی Console، که می‌گه درخواست شما به خاطر سیاست CORS مسدود شد. اول یه کلمه: origin؛ یعنی پروتکل، دامنه و پورت، با هم. اگه frontend روی localhost با یه پورته، و backend روی پورت سه‌هزار، از نظر مرورگر این‌ها دو تا origin جدان؛ انگار دو تا ساختمون. مرورگر مثل نگهبان ساختمونه. وقتی صفحه از یه origin دیگه چیزی می‌خواد، نگهبان جواب رو فقط وقتی به صفحه می‌ده که روی جواب نوشته باشه «این origin اجازه داره»، با یه header به اسم Access-Control-Allow-Origin.

برای بعضی درخواست‌ها، مثل فرستادن JSON، نگهبان حتی قبلش با متد OPTIONS اجازه می‌گیره. و چون این کار مرورگره، ترمینال و curl اصلاً CORS نمی‌شناسن؛ CORS از کاربرها محافظت می‌کنه، نه از سرور شما. راه درستش هم توی backend هست. به ایجنت بگین: «frontend روی این آدرسه؛ توی backend، فقط همین origin رو اجازه بده». یه تنظیم کوچیکه. و سه راه غلط که زیاد پیشنهاد می‌شه: خاموش کردن امنیت مرورگر یا یه افزونه، که فقط روی کامپیوتر خودتون جواب می‌ده؛ ستاره، یعنی اجازه به همه، که وقتی پای کوکی و ورود وسطه اصلاً قبول نمی‌شه؛ و no-cors، که آخر همون پیام قرمز پیشنهاد می‌شه، ولی فقط یه نامهٔ مُهروموم‌شده می‌ده که کدتون نمی‌تونه بازش کنه.

و اگه سرور مال شما نیست، مثلاً سرور یه سرویس دیگه؟ از backend خودتون صداش بزنین. بین دو تا سرور، CORS وجود نداره؛ و کلید ای‌پی‌آی هم روی سرور می‌مونه، همون‌جایی که قسمت ای‌پی‌آی گفتیم. سه تا اشتباه رایج، که توی کدهای ساخته‌شده با هوش مصنوعی زیاد دیده می‌شن. یک: فکر کردن اینکه fetch با ۴۰۴ یا ۵۰۰ خطا می‌ده. نمی‌ده. fetch فقط وقتی شکست می‌خوره که اصلاً به سرور نرسه. اگه کد response.ok رو چک نکنه، اپ با یه جواب خطا جوری رفتار می‌کنه که انگار همه‌چی درسته. پس از ایجنت بخواین: «بعد از هر درخواست، کد وضعیت رو چک کن، و خطا رو به کاربر نشون بده».

دو: فرستادن JSON بدون Content-Type. اگه header نگه توی پاکت JSON هست، خیلی از backend ها بدنه رو باز نمی‌کنن، و داده خالی می‌رسه. و سه: دو بار کلیک. هر POST یه چیز تازه می‌سازه؛ اگه کاربر دو بار «ثبت سفارش» رو بزنه، ممکنه دو تا سفارش ثبت بشه. از ایجنت بخواین دکمه تا رسیدن جواب غیرفعال بمونه، و backend هم سفارش تکراری رو قبول نکنه. و حالا، قولی که اول ویدیو دادم: یه خطای واقعی، از مرورگر تا ایجنت. با F12 یا کلیک راست و Inspect، برین توی Network. تیک Preserve log رو بزنین که با رفرش پاک نشه، و فیلتر رو بذارین روی fetch، تا فقط درخواست‌های اپ رو ببینین.

حالا کاری که خراب می‌شه رو دوباره انجام بدین. یه خط قرمز میاد. روش کلیک کنین: توی Headers، آدرس و متد و کد وضعیت؛ توی Payload، چیزی که فرستادین؛ توی Response، جوابی که برگشته. اگه ۵۰۰ بود، ترمینال backend رو هم ببینین؛ اگه CORS بود، Console رو. حالا به کلاد کد، کدکس یا آنتی‌گرویتی بگین: «این درخواست، با این متد و این آدرس، این کد رو گرفت. انتظار داشتم این بشه. جوابش این بود، و ترمینال backend این رو نوشته». با همین چهار جمله، ایجنت دیگه حدس نمی‌زنه.

و ترفند آخر: روی همون خط قرمز کلیک راست کنین، Copy، و بعد Copy as cURL. مرورگر خودِ اون درخواست رو، با همهٔ header هاش، به شکل یه دستور ترمینال کپی می‌کنه. اون رو به ایجنت بدین، تا همون درخواست رو توی ترمینال اجرا کنه و خطا رو خودش ببینه. فقط حواستون باشه: کوکی و کلید شما هم توشه. قبل از فرستادن، مقدارشون رو پاک کنین، یا با یه کلید آزمایشی عوضشون کنین. پس بیاین مرور کنیم. HTTP قانون نامه‌نگاری مرورگر و سروره. هر درخواست یه نامه‌ست: خط اول متد و آدرس، بعد header ها، بعد بدنه.

هر جواب یه مُهر داره، و فقط رقم اولش مهمه: دو انجام شد، سه برو اون‌جا، چهار ایراد از درخواست، پنج از سرور. کوکی کارتیه که مرورگر به هر نامه سنجاق می‌کنه، و کش، کپی توی کِشوی شما. قفل یعنی راه امنه، نه مقصد. CORS کار مرورگره، و راه درستش توی backend. و وقتی چیزی خراب شد، به جای «کار نمی‌کنه»، خودِ نامه رو به ایجنت نشون بدین. اگه این ویدیو به کارت اومد، لایک کن تا یادت نرفته. سؤالی داری؟ همین الان توی کامنت‌ها بپرس. یادت نره سابسکرایب کنی، و برای دوستات هم بفرست که اونا هم یاد بگیرن.

توی قسمت بعدی مفاهیم پایه، می‌ریم سراغ JSON و داده: همون چیزی که توی خیلی از این نامه‌ها نوشته می‌شه. می‌بینمتون.