مرجع کدهای وضعیت HTTP رایگان

برای درخواست‌های دارای Expect: 100-continue استفاده می‌شود. سرور تایید می‌کند که آماده دریافت متن است قبل از اینکه مشتری آن را ارسال کند. به ندرت در برنامه‌های وب مدرن دیده می‌شود.

اغلب برای ارتقاء WebSocket استفاده می‌شود — مشتری درخواست Upgrade: websocket می‌کند و سرور با 101 پاسخ می‌دهد تا پروتکل را تبدیل کند.

پاسخ واسطه‌ای WebDAV برای جلوگیری از انقضای مهلت مشتری در حین عملیات طولانی. منسوخ شده — سرورهای مدرن نباید آن را ارسال کنند.

به سرورها امکان می‌دهد سرآیندهای Link (preload/preconnect) را بفرستند در حالی که پاسخ نهایی هنوز آماده می‌شود، تا مرورگرها بتوانند زودتر شروع به واکشی دارایی‌های حیاتی کنند.

پاسخ موفقیت استاندارد. معنی به روش HTTP بستگی دارد: GET → منبع برگردانده شد، POST/PUT → عمل تکمیل شد.

معمول پس از POST. پاسخ باید سرصحفه Location را شامل شود که به URL منبع جدید اشاره می‌کند.

برای عملیات غیرهم‌زمان — سرور کار را در صف قرار می‌دهد. مشتری باید نقطه پایانی وضعیت را بررسی کند یا بعداً بازگردد.

درخواست موفق شد، اما واسطه‌ای (مانند کش یا پروکسی تبدیل‌کننده) بار را از سرور مبدا تغییر داد — برای مثال، تصاویر را دوباره فشرده‌سازی کرد. کمیاب در عمل.

اغلب برای عملیات DELETE یا به‌روزرسانی‌های PUT که نیازی به برگرداندن متن ندارند استفاده می‌شود. مشتری نباید از صفحه فعلی خارج شود.

مانند 204، هیچ متنی برگردانده نمی‌شود — اما مشتری علاوه بر این گفته می‌شود تا فرم یا دید را بازنشانی کند که درخواست را تولید کرد (مثلاً فیلدهای فرم را برای ورود بعدی پاک کنید).

پاسخ به درخواست Range. پخش‌کننده‌های ویدیو و مدیران دانلود از آن برای ازسرگیری دانلودهای قطع‌شده یا پخش جریانی فایل‌های بزرگ استفاده می‌کنند.

WebDAV: متن XML نتیجه چندین عملیات فرعی را به‌طور مستقل گزارش می‌کند — به عنوان مثال انتقال دسته‌ای جایی که برخی آیتم‌ها موفق و برخی ناموفق بودند.

WebDAV: در پاسخ‌های 207 Multi-Status استفاده می‌شود تا وقتی اتصال‌ها (bindings) حلقه ایجاد می‌کنند، اعضای همان مجموعه بارها فهرست نشوند.

کدگذاری دلتا: سرور به‌جای منبع کامل، تفاوت را نسبت به نسخه قبلی برمی‌گرداند و پهنای باند صرفه‌جویی می‌کند. بسیار به‌ندرت پیاده‌سازی می‌شود.

سرور گزینه‌های متعددی را ارائه می‌دهد (مثلاً فرمت‌ها یا زبان‌های مختلف) و مشتری باید یکی را انتخاب کند. به ندرت استفاده می‌شود، زیرا مذاکره محتوای خودکار معمولاً این را رفع می‌کند.

برای تغییرات URL دائمی استفاده کنید — موتورهای جستجو نمایه خود را به‌روزرسانی می‌کنند. اقتدار SEO به URL جدید منتقل می‌شود.

نشان می‌دهد که تغییر مسیر دائمی نیست. کش کردن کمتر تهاجمی از 301 است. برای چیزهایی مانند 'ورود لازم است، تغییر مسیر به /login' استفاده کنید.

بعد از ارسال POST — پاسخ می‌گوید 'POST شما کار کرد، این URL را برای نتیجه ببینید'. مرورگرها همیشه URL جدید را GET می‌کنند.

پاسخ به درخواست مشروط (با سرآیندهای If-None-Match یا If-Modified-Since). پهنای باند را صرفه‌جویی می‌کند — هیچ بدنه‌ای برگردانده نمی‌شود.

اگر اصلی POST بود، تغییر مسیر نیز از POST استفاده می‌کند. جایگزین مدرن برای 302 زمانی که حفظ روش مهم است.

جایگزین مدرن برای 301 زمانی که می‌خواهید درخواست‌های POST پس از تغییر مسیر به POST باقی بمانند.

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

کلاینت باید اطلاعات احراز هویت (سرآیند Authorization، کوکی، توکن) را ارسال کند. «Unauthorized» نام‌گذاری نادرستی است — در واقع یعنی «احراز هویت نشده».

در اصل برای پرداخت‌های دیجیتالی در نظر گرفته‌شده بود. استفاده مدرن: API‌ها گاهی 402 را بازمی‌گردانند زمانی که کاربر سهمیه پرداختی خود را فراتر رفته است.

متفاوت از 401 — کاربر وارد شده است، اما حسابش برای این منبع مجوز ندارد. منطق نقش/مجوزها را بررسی کنید.

یا URL اشتباه است، منبع حذف شده یا هرگز وجود نداشت. سرورها گاهی 404 را بازمی‌گردانند تا پنهان کنند که 403 دقیق‌تر خواهد بود.

برای مثال، درخواست GET به نقطه‌پایانی که فقط POST را می‌پذیرد. پاسخ باید سرآیند Allow را شامل شود که روش‌های معتبر را فهرست می‌کند.

کلاینت نوع محتوا، زبان یا رمزگذاری‌ای را درخواست کرده است (از طریق Accept، Accept-Language، Accept-Encoding) که سرور نمی‌تواند برآورده کند. بسیاری از سرورها از مذاکره دقیق صرف‌نظر می‌کنند و به جای آن پاسخ پیش‌فرضی برمی‌گردانند.

شبیه 401، اما توسط پروکسی صادر می‌شود: کلاینت باید اعتبارنامه Proxy-Authorization را ارسال کند. در شبکه‌های سازمانی با پروکسی‌های احراز هویت دیده می‌شود.

کلاینت برای ارسال بدنه درخواست بیش از حد طول کشید یا اتصال را بیکار نگه داشت. درخواست را دوباره امتحان کنید.

معمولاً برای تضادهای ویرایش همزمان یا ایجاد منابع تکراری بازگردانده می‌شود (مثلاً ایجاد کاربری با ایمیلی که قبلاً وجود دارد).

قویتر از 404 — سرور به طور صریح می‌داند منبع قبلاً وجود داشته اما به طور دائمی حذف شده است. موتورهای جستجو از شاخص خارج خواهند کرد.

درخواست رد شد زیرا سرآیند Content-Length نداشت و سرور بدنه‌هایی با اندازه نامعلوم را نمی‌پذیرد. سرآیند را اضافه کنید و دوباره تلاش کنید.

وقتی سرآیندهای شرطی مانند If-Match یا If-Unmodified-Since ناموفق باشند برگردانده می‌شود — معمولاً قفل خوش‌بینانه: کس دیگری منبع را از زمان نسخه شما تغییر داده است. دوباره واکشی کنید و تلاش کنید.

برای بارگذاری فایل‌های بزرگ رایج است. تنظیمات سرور (nginx، apache) حداکثر اندازه بدنه را تعیین می‌کند. تنظیمات سرور را بررسی کنید.

معمولاً ناشی از رشته‌های پرس‌وجوی بسیار طولانی است (مثلاً رمزگذاری داده‌ها در GET). به بدنه POST روی بیاورید یا اگر کنترل سرور را دارید حد آن را افزایش دهید.

مثلاً ارسال application/xml به سروری که فقط application/json می‌پذیرد. سرآیند Content-Type را درست تنظیم کنید.

سرآیند Range بخشی را درخواست می‌کند که فایل ندارد — مثلاً ادامه دانلود از بعد از انتهای فایل. پاسخ باید شامل Content-Range با اندازه واقعی باشد.

زمانی ارسال می‌شود که سرور Expect: 100-continue را پشتیبانی نکند. برخی کلاینت‌ها به‌طور پیش‌فرض این سرآیند را در POSTهای بزرگ ارسال می‌کنند؛ غیرفعال کردن آن معمولاً خطا را حل می‌کند.

یک شوخی اول آوریل از سال 1998 (RFC 2324). برخی APIهای واقعی از آن برای شوخی یا علامت‌گذاری نقاط پایانی منسوخ استفاده می‌کنند. برای محیط عملیاتی مناسب نیست.

معمول با استفاده مجدد اتصال HTTP/2: درخواست به سروری رسید که برای نام میزبان هدف پیکربندی نشده است. کلاینت باید در اتصال جدید دوباره تلاش کند.

مثلاً JSON به درستی تجزیه شده ولی قسمت اجباری گم است یا مقدار قسمت خارج از محدوده است. معمول در پاسخ‌های اعتبارسنجی API REST.

WebDAV: منبع مبدأ یا مقصد توسط کلاینت دیگری قفل شده است، بنابراین عملیات نمی‌تواند انجام شود. منتظر رفع قفل باشید یا آن را با توکن مناسب شکسته کنید.

WebDAV: در زنجیره عملیات‌های وابسته، اقدام قبلی ناموفق بود، بنابراین این عملیات انجام نشد. برای علت ریشه به شکست قبلی نگاه کنید.

مربوط به TLS 1.3 0-RTT (داده زودهنگام): سرور خطر پردازش درخواستی را که ممکن است تکراری باشد نمی‌پذیرد. کلاینت باید بعد از تکمیل دست‌دهی دوباره تلاش کند.

سرور از پاسخ‌گویی به درخواست روی پروتکل فعلی امتناع می‌کند اما پس از ارتقا پاسخ می‌دهد — پاسخ شامل سرآیند Upgrade است که پروتکل موردنیاز را نام می‌برد.

سرور سرآیندهای شرطی (مانند If-Match) را الزامی می‌کند تا از تعارض‌های به‌روزرسانی گم‌شده جلوگیری کند. منبع را واکشی کنید، ETag آن را ثبت کنید و با If-Match دوباره ارسال کنید.

سرعت را کم کنید. پاسخ باید شامل سرآیند Retry-After باشد که زمان تلاش دوباره را نشان می‌دهد. در APIهایی که سهمیه درخواست دارند رایج است.

یا یک سرآیند یا مجموع اندازه سرآیندها از حد فراتر رفته است — بیشتر اوقات به‌دلیل کوکی‌های حجیم. کوکی‌ها را پاک کنید یا آنچه برنامه در آن‌ها ذخیره می‌کند کاهش دهید.

منبع به دلایل قانونی مسدود است — سانسور، احکام دادگاه یا مقررات منطقه‌ای. عدد اشاره‌ای به رمان Fahrenheit 451 است.

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

مثلاً سرور روش HTTP را تشخیص نمی‌دهد. نادر در عمل — بیشتر اوقات 405 را خواهید دید.

در معماری میکروسرویس رایج است. توزیع‌کننده بار یا پروکسی معکوس شما از سرویس پشتیبان پاسخ نامعتبری دریافت کرد.

یا برای تعمیر و نگهداری از کار افتاده یا بیش از حد پرباز است. پاسخ باید شامل سرآیند Retry-After باشد. اغلب هنگام استقرار برگردانده می‌شود.

سرویس پشتیبان به‌اندازه کافی سریع پاسخ نداد. سلامت سرویس بالادستی و تنظیمات timeout را بررسی کنید.

نسخه HTTP اصلی درخواست توسط سرور پشتیبانی نمی‌شود. تقریباً هرگز با کلاینت‌های جدید دیده نمی‌شود.

مذاکره محتوای شفاف در حلقه به پایان رسید: گونه انتخاب‌شده خود برای مذاکره پیکربندی شده است. نشان‌دهنده خطای پیکربندی سرور است.

در اصل مخصوص WebDAV است اما گاهی سرورهای عمومی هم از آن استفاده می‌کنند. یعنی سرور به‌دلیل محدودیت‌های ذخیره‌سازی نمی‌تواند درخواست را ذخیره کند.

WebDAV: پردازش درخواست Depth: infinity در حلقه وارد شد (مثلاً اتصالات دایره‌ای). عملیات متوقف شد.

از چارچوب منسوخ HTTP Extension Framework: سرور قبل از برآورده کردن درخواست به اطلاعات بیشتری نیاز دارد. عملاً در وب امروز استفاده نمی‌شود.

توسط پورتال‌های ورود (captive portal) در وای‌فای هتل/فرودگاه استفاده می‌شود تا نشان دهد کاربر باید پیش از دسترسی به سایت‌های خارجی وارد شبکه شود.