| کد وضعیت Http |
معنای کد وضعیت |
| 100 |
مشتری باید به ارسال درخواست ادامه دهد. این پاسخ موقت برای اطلاعرسانی به مشتری است که بخشی از درخواست او توسط سرور دریافت و هنوز رد نشده است. مشتری باید به ارسال باقیمانده درخواست ادامه دهد یا اگر درخواست کامل شده، این پاسخ را نادیده بگیرد. سرور باید پس از تکمیل درخواست، یک پاسخ نهایی به مشتری ارسال کند. |
| 101 |
سرور درخواست مشتری را درک کرده و از طریق هدر پیام Upgrade به مشتری اطلاع میدهد که برای اتمام این درخواست از پروتکل متفاوتی استفاده کند. پس از ارسال این پاسخ و خط خالی آخر، سرور به پروتکلهایی که در هدر Upgrade تعریف شدهاند، سوئیچ خواهد کرد. چنین اقداماتی تنها در صورتی باید اتخاذ شود که انتقال به پروتکل جدید مزایای بیشتری داشته باشد، به عنوان مثال، سوئیچ به نسخه جدید HTTP نسبت به نسخه قبلی یا سوئیچ به یک پروتکل زمان واقعی و همگام برای ارسال منابع با ویژگیهای مشابه. |
| 102 |
کدی که توسط WebDAV (RFC 2518) گسترش یافته و نشاندهنده ادامه پردازش درخواست است. |
| 200 |
درخواست با موفقیت انجام شده و پاسخ مورد نظر یا سرآیند دادهها در این پاسخ برگردانده خواهد شد. |
| 201 |
درخواست قبلاً انجام شده است و یک منبع جدید بر اساس نیازهای درخواست ایجاد شده و URI آن در هدر Location برگردانده شده است. اگر منبع مورد نیاز به موقع ایجاد نشود، باید '202 Accepted' برگردانده شود. |
| 202 |
سرور درخواست را قبول کرده اما هنوز پردازش نکرده است. همانطور که ممکن است رد شود، در نهایت این درخواست ممکن است که انجام نشود یا انجام شود. در موارد عملیات غیرهمزمان، آسانترین روش ارسال این کد وضعیت است. هدف پاسخهایی که کد 202 را برمیگردانند، اجازه دادن به سرور برای پذیرش درخواستهای سایر فرآیندها (مانند عملیاتی که فقط یک بار در روز انجام میشود) است، بدون اینکه مشتری نیاز داشته باشد تا زمانی که پردازش دستهای تکمیل نشده، با سرور در ارتباط بماند. پاسخهایی که پذیرش درخواستهای پردازش شده را به همراه 202 برمیگردانند، باید اطلاعاتی را که وضعیت فعلی پردازش را نشان میدهد در بر داشته باشند، بهعلاوه یک اشارهگر به ناظر وضعیت پردازش یا پیشبینی وضعیت، تا کاربر بتواند تخمین بزند آیا عملیات کامل شدهاست یا نه. |
| 203 |
سرور درخواست را با موفقیت پردازش کرده، اما متاداده هدرهای برگردانده شده در مجموعه معتبر سرور اصلی نیست، بلکه از یک کپی محلی یا شخص سوم است. اطلاعات فعلی ممکن است زیرمجموعه یا فراگسترهای از نسخه اصلی باشد. به عنوان مثال، اطلاعات متادیتا شامل منبع ممکن است باعث شود که سرور اصلی از وجود اطلاعات فرابیش مطلع شود. استفاده از این کد وضعیت الزامی نیست و تنها در مواردی که پاسخ باید 200 OK باشد، اگر از این کد وضعیت استفاده نشود، مناسب است. |
| 204 |
سرور درخواست را با موفقیت پردازش کرده، اما نیازی به برگرداندن محتویات خاصی ندارد و میخواهد اطلاعات متادیتای بهروزشده را برگرداند. پاسخ ممکن است متادیتای جدید یا بهروزرسانیشده را از طریق هدرهای محتوایی صادر کند. اگر این هدرهای اطلاعات وجود داشته باشند، باید با متغیرهای درخواست شده مرتبط باشند. اگر مشتری مرورگر باشد، باید مرورگر کاربر صفحه ارسالکننده این درخواست را حفظ کند، بدون اینکه هیچ تغییر دیداری در مستندات ایجاد شود، حتی اگر به معیارهای خاصی که باید به دادههای بهروزرسانیشده نسبت داده شوند، باید در نمای جستجوی مطلب مرورگر کاربر لحاظ شوند. از آنجایی که پاسخ 204 اجازه نمیدهد که هیچ بدنه پیامی شامل شود، همیشه به یک خط خالی پس از هدرهای پیام خاتمه مییابد. |
| 205 |
سرور درخواست را با موفقیت پردازش کرده و هیچ محتوا را برنگردانده است. اما برخلاف پاسخ 204، پاسخهایی که این کد وضعیت را برمیگردانند، نیاز دارند تا درخواستکننده دیدگاه مستندات را بازنشانی کند. این پاسخ عمدتاً در پذیرش اطلاعات ورودی کاربر استفاده میشود تا بلافاصله فرم را بازنشانی کند و کاربر بتواند به آسانی یک ورودی جدید شروع کند. مانند 204، این پاسخ نیز اجازه ندارد که شامل هیچ بدنه پیامی باشد و به اولین خط خالی پس از هدر پایان مییابد. |
| 206 |
سرور با موفقیت یک درخواست GET جزئی را پردازش کردهاست. بهطور معمول، ابزارهای دانلود HTTP مانند FlashGet یا 迅雷 از این نوع پاسخها برای ادامه دانلود از محل قطع استفاده میکنند یا یک سند بزرگ را به بخشهای دانلودی تقسیم میکنند تا بهطور همزمان دانلود شوند. این درخواست باید هدرهای Range را شامل شود تا نشان دهد که دامنه محتوا که مشتری تمایل دارد دریافت کند، چه چیزی است و ممکن است شامل If-Range باشد تا به عنوان شرایط درخواست عمل کند. پاسخ باید شامل هدرهای زیر باشد: Content-Range برای نشان دادن دامنهای که از این پاسخ برگردانده شده است؛ اگر Content-Type چندبهتری باشد، هر بخشی باید شامل هدر Content-Range برای نشان دادن دامنه محتوا آن بخش باشد. اگر پاسخ شامل Content-Lengthباشد، باید مقدار آن با عدد واقعی مربوط به دامنه محتوا برگردانده شده، مطابقت داشته باشد. Date، ETag و/یا Content-Location، اگر درخواست باید بهطور معمول یک پاسخ 200 برگرداند. Expires، Cache-Control، و/یا Vary، در صورت وجود و عدم برابری دیگر متغیرهای پاسخهای قبلی. در صورت اینکه درخواست استفاده از if-range بهعنوان اعتبار قوی باشد، این پاسخ نباید دیگر هدرهای محتوایی داشته باشد؛ اگر درخواست که از if-range بهعنوان اعتبار ضعیف استفاده کرد، این پاسخ نباید دیگر هدرهای محتوایی داشته باشد؛ این کار جلوگیری میکند از عدم تطابق بین محتویات کش و هدرهای بهروزرسانیشده محتوا. در غیر این صورت، این پاسخ باید شامل تمامی هدرهای محتوایی باشد که انتظار میرود در پاسخ 200 بهطور معمول برگردانده شود. اگر ETag یا Last-Modified هدر نتوانند بهطور دقیق مطابقت داشته باشند، کش مشتری نباید از محتویات 206 برگردانده شده با محتویات قبلاً کش شده ترکیب کند. هیچ کشی که هدرهای Range و Content-Range را پشتیبانی نمیکند، نمیتواند محتوای 206 را کش کند. |
| 207 |
کدی که توسط WebDAV (RFC 2518) گسترش یافته است و نشاندهنده وجود یک پیام XML در بدنه پیام و ممکن است بر اساس تعداد درخواستهای فرعی قبلی، شامل مجموعهای از کدهای پاسخ مستقل باشد. |
| 300 |
منبع درخواستی دارای یک سری بازخورد انتخابی است که هر کدام دارای آدرس خاص و اطلاعات تجاری خود است. کاربر یا مرورگر میتوانند یکی از آدرسهای مورد نظر را برای هدایت انتخاب کنند. مگر اینکه این درخواست یک HEAD باشد، این پاسخ باید شامل یک موجودی اطلاعات و آدرس از منابع باشد تا کاربر یا مرورگر از آن انتخاب کنند. فرمت موجودی به وسیله نوع محتوای معین میشود؛ مرورگر ممکن است به طور خودکار انتخاب درستی انجام دهد، البته RFC 2616 استانداردی برای این نوع انتخاب خودکار تعیین نکرده است. اگر سرور خود گزینههای بازخورد بهعنوان اولویت داشته باشد، در Location باید URI این بازخورد مشخص شود؛ مرورگر ممکن است این مقدار Location را به عنوان آدرس هدایت خودکار در نظر بگیرد. علاوه بر این، مگر اینکه بهطور خاص مشخص شده باشد، این پاسخ نیز قابل کش است. |
| 301 |
منبع درخواستی به طور دائمی به موقعیت جدیدی منتقل شده است و هر گونه اشاره در آینده به این منبع باید از یکی از URIهایی که با این پاسخ ارائه شده، استفاده کند. در صورت امکان، مشتری که قابلیت ویرایش لینک دارد، باید به طور خودکار آدرس درخواست شده را به آدرسی که از سرور دریافت شده است، ویرایش کند. مگر اینکه بهطور خاص مشخص شده باشد، این پاسخ نیز قابل کش است. URI جدید باید در هدر Location بازگردانده شود. مگر اینکه این درخواست یک HEAD باشد، موجودی پاسخ باید شامل یک Hyperlink به URI جدید و یک توضیح مختصر باشد. اگر این درخواست GET یا HEAD نباشد، پس مرورگر باید از انجام هدایت خودکار خودداری کند، مگر اینکه تأیید пользователя را دریافت کند، زیرا شرایط درخواست ممکن است تغییر کند. توجه: برای مرورگرهایی که از پروتکل HTTP/1.0 استفاده میکنند، در صورتی که درخواست POST منجر به پاسخ 301 شود، درخواست هدایت بعدی به روش GET انجام میشود. |
| 302 |
منبع درخواستی اکنون به طور موقت از URI متفاوتی پاسخ میدهد. از آنجایی که این هدایت موقتی است، مشتری باید به ارسال درخواستهای بعدی به آدرس قبلی ادامه دهد. تنها در حالتهایی که در Cache-Control یا Expires مشخص شده، این پاسخ قابل کش است. URI جدید موقتی باید در هدر Location بازگردانده شود. مگر اینکه این درخواست یک HEAD باشد، موجودی پاسخ باید شامل یک Hyperlink به URI جدید و یک توضیح مختصر باشد. اگر این درخواست GET یا HEAD نباشد، مرورگر باید از انجام هدایت خودداری کند، مگر اینکه تأیید تأمین کننده را دریافت کند، چرا که شرایط درخواست ممکن است تغییر کند. توجه: اگرچه RFC 1945 و RFC 2068 مجاز به تغییر روش درخواست به هنگام هدایت نیستند، بسیاری از مرورگرهای موجود پاسخ 302 را بهعنوان 303 در نظر میگیرند و از روش GET برای دسترسی به URIای که در Location تعریف شده استفاده میکنند و روش قبلی را نادیده میگیرند. کدهای وضعیت 303 و 307 اضافه شدهاند تا درخواستهای مشتری را در خصوص واکنش سرور مشخص کنند. |
| 303 |
پاسخی که به درخواست جاری مربوط میشود میتواند در URI دیگری یافت شود و مشتری باید از روش GET برای دسترسی به این منبع استفاده کند. وجود این روش عمدتاً به اجازه میدهد تا خروجی درخواست POST که از طریق اسکریپت فعال میشود به یک منبع جدید هدایت شود. این URI جدید یک مرجع جایگزینی برای منبع اصلی نیست. در ضمن، پاسخ 303 نمیتواند کش شود، البته ممکن است درخواست (هدایت) دوم کش شود. URI جدید باید در هدر Location بازگردانده شود. مگر اینکه این درخواست یک HEAD باشد، موجودی پاسخ باید شامل یک Hyperlink به URI جدید و یک توضیح مختصر باشد. توجه: بسیاری از مرورگرهای قدیمیتر HTTP/1.1 نمیتوانند وضعیت 303 را به درستی درک کنند. اگر بخواهید تعامل با این مرورگرها را در نظر بگیرید، وضعیت 302 باید کفایت کند، زیرا بیشتر مرورگرها روش اول را در خصوص وضعیت 302 به صورت همانگونه که از مقررات خواسته شده، بهرهبرداری میکنند. |
| 304 |
اگر مشتری یک درخواست GET مشروط ارسال کند و این درخواست مجاز باشد، و محتویات مستندات (از آخرین بازدید یا براساس شرایط درخواست) تغییر نکرده است، آنگاه سرور باید این کد وضعیت را برگرداند. پاسخ 304 اجازه نمیدهد که هیچ بدنه پیامی شامل شود و بنابراین همیشه با اولین خط خالی بعد از هدرهای پیام خاتمه مییابد. این پاسخ باید شامل هدرهای زیر باشد: Date، مگر اینکه این سرور هیچ ساعتی نداشته باشد. اگر سروری که ساعتی ندارد، علیرغم رعایت این قوانین، هدر Date را به پاسخ اضافه کند، ممکن است مکانیزم کش طبق قواعد RFC 2068 به درستی کار کند. ETag و/یا Content-Location، اگر درخواست دقیقاً همانگونه بوده باشد که باید 200 پاسخ دهد. Expires، Cache-Control، و/یا Vary، در صورتی که مقادیر ممکن است با مقادیر دیگر پاسخهای قبلی متفاوت باشد. اگر این پاسخ به درخواست استفاده از اعتبار قوی مرتبط باشد، این پاسخ نباید شامل سایر هدرهای متنی باشد؛ در غیر این صورت (برای مثال، اگر درخواست GET مشروط از اعتبار ضعیف استفاده کند)، این پاسخ نباید شامل دیگر هدرهای متنی باشد، این کار موجب جلوگیری از عدم تطابق بین محتویات کش و اطلاعات هدر بهروز شده میشود. اگر یک پاسخ 304 نشان دهد که کنونی پیوند معین مورد استفاده قرار نگرفته، سیستم کش باید این پاسخ را نادیده بگیرد و درخواست را بدون شرایط بهروز ارسال کند. اگر پاسخ 304 یک روز جدید کش، را مشخص کند، سیستم کش باید تمام اطلاعات در پاسخ را بهروز رسانی کند. |
| 305 |
منبع درخواستی باید از طریق پروکسی معین شده درخواست شود. URI پروکسی باید در هدر Location داده شود تا دریافت کننده بتواند درخواست جداگانهای را ارسال کند تا به منبع مربوطه دسترسی پیدا کند. تنها سرور اصلی میتواند پاسخ 305 را ایجاد کند. توجه کنید: RFC 2068 بهوضوح نمیگوید که پاسخ 305 باید یک درخواست مجزا را هدایت کند و تنها میتواند توسط سرور اصلی ایجاد شود. غفلت از این محدودیتها ممکن است به عواقب امنیتی جدی منجر شود. |
| 306 |
در نسخه جدید دستور العمل، کد وضعیت 306 دیگر استفاده نمیشود. |
| 307 |
منبع درخواستی اکنون به طور موقت از URI متفاوتی پاسخ میدهد. از آنجا که این هدایت موقتی است، مشتری باید به ارسال درخواستهای بعدی به آدرس قبلی ادامه دهد. تنها در صورت مشخص کردن در Cache-Control یا Expires، این پاسخ قابل کش خواهد بود. URI موقتی جدید باید در هدر Location برگردانده شود. مگر اینکه این درخواست یک HEAD باشد، موجودی پاسخ باید شامل Hyperlink به URI جدید و یک توضیح مختصر باشد. به خاطر برخی از مرورگرها که نمیتوانند وضعیت 307 را شناسایی کنند، لازم است که اطلاعات مرتبطی اضافه شود تا کاربران متوجه شوند و به URI جدید درخواست کنند. اگر این درخواست GET یا HEAD نباشد، مرورگر باید از انجام هدایت خودداری کند مگر اینکه تأیید کاربر را دریافت کرده باشد زیرا شرایط درخواست ممکن است تغییر کند. |
| 400 |
1. معانی نامناسب، درخواست فعلی نمیتواند توسط سرور فهمیده شود. مگر اینکه اصلاح شود، مشتری نباید این درخواست را دوباره ارسال کند. 2. پارامترهای درخواست نادرست هستند. |
| 401 |
درخواست فعلی نیاز به شناسایی کاربر دارد. این پاسخ باید اطلاعات هدر WWW-Authenticate مربوط به منبع درخواستی را شامل شود تا از کاربر اطلاعات را درخواست کند. مشتری میتواند درخواست را دوباره با هدر Authorization درست ارسال کند. اگر درخواست فعلی شامل گواهی Authorization باشد، آنگاه پاسخ 401 نشاندهنده این است که سرور گواهیهای ارائهشده را رد کرده است. اگر پاسخ 401 هدرهای موجود در پاسخ قبلی را همراه داشته باشد و مرورگر حداقل یک بار سعی در تأیید هویت کرده باشد، پس مرورگر باید اطلاعات موجود در پاسخ را به کاربر نشان دهد چرا که ممکن است وضعیت تشخیصی مرتبط وجود داشته باشد. به RFC 2617 مراجعه کنید. |
| 402 |
این کد وضعیت برای نیازهای ممکن در آینده رزرو شده است. |
| 403 |
سرور درخواست را فهمیده اما از انجام آن خودداری میکند. بر خلاف پاسخ 401، تأیید اعتبار هیچ کمکی نمیکند و این درخواست نباید دوباره ارسال شود. اگر این درخواست HEAD نباشد و سرور بخواهد توضیح دهد که چرا درخواست نمیتواند انجام شود، پس باید دلایل رد را در بدنه موجودی توصیف کند. البته، سرور میتواند یک پاسخ 404 را نیز بازگرداند اگر نمیخواهد به مشتری اطلاعاتی بدهد. |
| 404 |
درخواست ناموفق است و منبع مورد نظر در سرور یافت نشد. هیچ اطلاعاتی به کاربر نمیتواند بگوید که آیا این وضعیت موقتی است یا دائمی. اگر سرور از وضعیت آگاه باشد، باید از کد وضعیت 410 استفاده کند تا به اطلاع دهد که یک منبع قدیمی به دلایلی از دسترس خارج شده و هیچ آدرس مفیدی برای هدایت موجود نیست. استفاده از کد وضعیت 404 گسترده است، بهویژه هنگامی که سرور نمیخواهد بگوید چرا درخواست رد شده یا غیر از این که نتیجه هیچ پاسخ قابل قبولی نداشته باشد. |
| 405 |
روش درخواست معینشده در خط درخواست، برای درخواست منبع مربوطه قابل قبول نیست. این پاسخ باید هدر Allow را شامل شود تا فهرستی از روشهای قابل پذیرش فعلی را به نمایش بگذارد. با توجه به اینکه روشهای PUT و DELETE به منابع در سرور نویسندگی میکنند، لذا بیشتر سرورهای وب این روشها را پشتیبانی نمیکنند یا بهطور پیشفرض اجازه چنین اقداماتی را نمیدهند و لذا برای این درخواستها کد خطای 405 را بازمیگردانند. |
| 406 |
ویژگی محتوای منبع درخواستی نمیتواند شرایط هدر درخواست را برآورده نماید، بنابراین نمیتوان به ایجاد موجودی پاسخ پرداخت. مگر اینکه این یک درخواست HEAD باشد، این پاسخ باید شامل موجودی باشد که میتواند فهرستی از ویژگیهای موجود محتوا و آدرسهای مربوطه برای انتخاب مناسبتر توسط کاربر یا مرورگر باشد. فرمت موجودی به وسیله نوع محتوا در هدر Content-Type تعیین میشود. مرورگر میتواند براساس نوع و قابلیتهای خود بهترین انتخاب را انجام دهد. با این حال، مقررات، هیچ استانداردی برای انجام چنین انتخاب خودکاری تعیین نکرده است. |
| 407 |
مشابه پاسخ 401 است، اما مشتری باید در سرور پروکسی گواهی معتبر ارائه دهد. سرور پروکسی باید هدر Proxy-Authenticate را برای تأیید هویت برگرداند. مشتری میتواند یک هدر Proxy-Authorization برای تأیید ارائه دهد. به RFC 2617 مراجعه کنید. |
| 408 |
درخواست زمانگذاری شده است. مشتری در حالی که سرور انتظار دارد، نتوانسته است یک درخواست ارسال کند. مشتری میتواند این درخواست را دوباره بدون هر گونه تغییر ارسال کند. |
| 409 |
به دلیل تضاد با وضعیت فعلی منبع درخواست نمیتواند انجام شود. این کد تنها در مواقعی مجاز است که مشتری بتواند تضاد را حل کند و یک درخواست جدید ارسال کند. این پاسخ باید حاوی اطلاعات کافی باشد تا مشتری منبع تضاد را شناسایی کند. تضاد معمولاً در پردازش درخواستهای PUT اتفاق میافتد. به عنوان مثال، در محیطی به کارگیری چک کردن نسخه، اگر اطلاعات نسخه یک درخواست PUT برای تغییری که در یک منبع خاص فرستاده میشود با یک درخواست قبلی دیگر تماس بگیرد، پس سرور باید یک خطای 409 بازگرداند تا مشتری را از اینکه درخواست انجام نمیشود مطلع کند. این ممکن است موجودی را شامل شود تا تفاوتها بین دو نسخه متضاد را نشان دهد تا مشتری بتواند نسخه جدیدی بعد از ادغام ارسال کند. |
| 410 |
منبع درخواستی دیگر در دسترس نیست و هیچ نشانی قابل ارسال شناختهشدهای ندارد. این وضعیت باید به عنوان دائمی در نظر گرفته شود. اگر ممکن است، مشتری که توانایی ویرایش لینک دارد باید تمامی ارجاعات به این آدرس را پس از دریافت مجوز کاربر حذف کند. اگر سرور نمیداند که آیا وضعیت دائمی است یا نه، باید از کد 404 استفاده کند. مگر اینکه موارد اضافی ذکر شود، این پاسخ قابل کش است. هدف پاسخ 410 کمک به مدیران وبسایت برای نگهداری وبسایت و اطلاعرسانی به کاربران است که منبع در دسترس نیست و مالک سرور خواستار حذف تمامی اتصالهای دور به این منبع است. چنین حوادثی در موارد محدود و خدماتی که به زمان بستگی دارند رایج است. بهعلاوه، پاسخ 410 برای اطلاع به مشتریان که یک منبع قبل که متعلق به شخص خاصی بوده دیگر در سایت سرور کنونی در دسترس نیست، نیز به کار میرود. البته، اینکه آیا باید تمامی منابع دائماً ناموجود به عنوان "410 Gone" علامتگذاری شوند و مدتزمانی که این نشان باید حفظ شود کاملاً به سرور وابسته است. |
| 411 |
سرور در عدم وجود هدر Content-Length تعریف شده، درخواست را رد میکند. پس از اضافه کردن هدر Content-Length معتبر که طول محتوای درخواست را مشخص کند، مشتری میتواند درخواست را دوباره ارسال کند. |
| 412 |
سرور هنگام اعتبارسنجی پیششرطهای مندرج در هدر درخواست، نتوانست یکی یا چند پیششرط را تأمین کند. این کد وضعیت به مشتری اجازه میدهد تا در حال دریافت منبع، پیششرطهایی را در اطلاعات متادیتا (دادههای هدر درخواست) تنظیم نماید تا از اجرایی شدن روش درخواست بر روی محتوایی غیر از مورد نظر اجتناب شود. |
| 413 |
سرور از پردازش درخواست جاری خودداری میکند زیرا حجم دادههای موجود در پرسش بیشتر از حد است که سرور تمایل یا توانایی پردازش داشته باشد. در این وضعیت، سرور میتواند اتصال را ببندد تا از ادامه ارسال این درخواست جلوگیری کند. اگر این وضعیت موقتی باشد، سرور باید هدر Retry-After را برای اطلاع از زمانی که مشتری میتواند دوباره امتحان کند، ارائه دهد. |
| 414 |
طول URI درخواست شده بیشتر از حدی است که سرور بتواند تفسیر کند و بنابراین سرور از ارائه خدمات به این درخواست خودداری میکند. این وضعیت نسبتاً نادر است و معمولاً شامل موارد زیر است: ارائه فرمی که باید با روش POST ارسال شود و به روش GET فرستاده میشود، که موجب طولانی شدن رشته علامتگذاری (Query String) میشود. URI هدایت "چاله سیاه"، به عنوان مثال، هر بار هدایت، URI قدیم را به عنوان بخشی از URI جدید در نظر میگیرد، که منجر به طولانیتر شدنURI در چندین هدایت میشود. مشتری در حال تلاش برای استفاده از یک آسیبپذیری در مقیاس خاصی در سرور است. اینگونه سرورهایی که از اندازه ثابت برای محدوده خواندن یا پردازش URI استفاده میکنند، ممکن است در صورتی که پارامترهای GET از حد خاصی فراتر برود، دچار overflow شوند، که منجر به اجرای کد دلخواه میشود [1]. سرورهایی که چنین آسیبپذیری ندارند باید کد 414 را برگردانند. |
| 415 |
فرمت موجود در درخواست ارسالی برای روش درخواست و منبع مورد نظر توسط سرور پشتیبانی نمیشود، بنابراین درخواست رد میشود. |
| 416 |
اگر در درخواست هدر محدوده وجود داشته باشد و هیچ دامنهای که در محدوده ذکر شده باشد با دامنههای موجود کنونی منبع همپوشانی نداشته باشد، و در حین درخواست نیز هدر If-Range مشخص نشده باشد، سرور باید کد 416 را برگرداند. اگر محدوده استفاده شده، به صورت بایتی باشد، آنگاه این وضعیت به این صورت است که تمامی جایگاههای آغازین دامنه دادههای در خواستی بیش از حجم فعلی منبع است. برگرداندن کد 416 باید شامل یک هدر Content-Range باشد که طول فعلی منبع را نشان دهد. این پاسخ همچنین اجازه ندارد از multipart/byteranges بهعنوان نوع محتوای خود استفاده کند. |
| 417 |
محتویات مورد انتظار مشخص شده در هدر Expect نمیتواند توسط سرور تامین شود یا این سرور، یک سرور پروکسی است که شواهد واضحی دارد مبنی بر اینکه در نقطه بعدی در مسیر فعلی، محتویات Expect نمیتواند تامین شود. |
| 421 |
تعداد اتصالات بین آدرس IP فعلی مشتری و سرور بیش از تعداد مجاز است که سرور آن را مجاز میداند. معمولاً، این آدرس IP به آدرس مشتری دیده شده از سرور (مثل آدرس گذرگاه کاربر یا آدرس پراکسی) اشاره دارد. در این شرایط، شمارش اتصالات ممکن است شامل بیش از یک کاربر نهایی باشد. |
| 422 |
فرمت درخواست درست است، اما به دلیل وجود خطا در معنای آن، نمیتوان به آن پاسخ داد. (RFC 4918 WebDAV) 423 Locked منبع جاری قفل شده است. (RFC 4918 WebDAV) |
| 424 |
به دلیل خطای قبلی در پاسخ، درخواست جاری رد شده است، مثلاً PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
در پیشنویس مجموعههای پیشرفته WebDav تعریف شده است اما در "پروتکل مجموعههای ترتیبی WebDAV" (RFC 3658) موجود نیست. |
| 426 |
مشتری باید به TLS/1.0 تغییر وضعیت دهد. (RFC 2817) |
| 449 |
توسط مایکروسافت گسترش یافته، بیانگر این است که درخواست باید بعد از اجرای عمل مناسب دوباره امتحان شود. |
| 500 |
سرور با یک وضعیت غیر منتظره روبرو شده است که باعث میشود نتواند درخواست را به پایان برساند. عموماً این مشکل در زمان بروز خطا در برنامه سرور به وجود میآید. |
| 501 |
سرور از پشتیبانی از یکی از قابلیتهایی که درخواست فعلی نیاز دارد، ناتوان است. زمانی که سرور نتواند روش درخواست را درک کند و نتواند درخواست را برای هیچ منبعی پشتیبانی کند. |
| 502 |
در حالیکه سرور به عنوان یک دروازه یا پروکسی کار میکند، سعی میکند درخواست را انجام دهد اما پاسخ نامعتبری از سرور upstream دریافت میکند. |
| 503 |
سرور به دلیل نگهداری موقت یا بار بیش از حد، در حال حاضر نمیتواند درخواست را پردازش کند. این وضعیت موقتی است و بعد از مدتی دوباره فعال خواهد شد. اگر زمان تأخیر قابل پیشبینی باشد، پاسخ میتواند شامل هدر Retry-After باشد تا این زمان تأخیر مشخص شود. اگر این اطلاعات Retry-After ارائه نشود، مشتری باید مانند پردازش پاسخ 500 به آن بپردازد. توجه: وجود کد وضعیت 503 به این معنی نیست که سرور در زمان بار بیش از حد باید از آن استفاده کند. برخی سرورها تنها میخواهند ارتباط مشتری را رد کنند. |
| 504 |
در حالیکه سرور به عنوان دروازه یا پروکسی کار میکند و سعی میکند درخواست را انجام دهد، قادر به دریافت به موقع پاسخ از سرور upstream (سروری که توسط URI شناسایی میشود، مثلاً HTTP، FTP، LDAP) یا سرور کمکی (مانند DNS) نیست. توجه: برخی از سرورهای پروکسی هنگام نداشتن زمان برای جستجو در DNS ممکن است کد خطا 400 یا 500 را برگردانند. |
| 505 |
سرور از پشتیبانی یا عدم تمایل به پشتیبانی از نسخه HTTP مورد استفاده در درخواست خودداری میکند. این بیانگر این است که سرور نمیتواند یا نمیخواهد از نسخهای مشابه با مشتری استفاده کند. پاسخ باید شامل توضیحاتی باشد که چرا نسخه پشتیبانی نمیشود و سرور از چه پروتکلهایی پشتیبانی میکند. |
| 506 |
توسط "پروتکل همفرهنگی محتوا" (RFC 2295) گسترش یافته و نشاندهنده وجود خطای داخلی در پیکربندی سرور است: منبع متغیرهای مذاکره شده درخواستی به عنوان یکی از محورهای اصلی در همفرهنگی محتوا خود استفاده شده است. |
| 507 |
سرور نمیتواند محتوای لازم برای تکمیل درخواست را ذخیره کند. این وضعیت بهعنوان موقتی در نظر گرفته میشود. WebDAV (RFC 4918) |
| 509 |
سرور به محدودیتهای باند دسترسی رسیده است. این یک کد وضعیت رسمی نیست اما همچنان بهطور گستردهای استفاده میشود. |
| 510 |
سیاستهای لازم برای دستیابی به منبع تأمین نشده است. (RFC 2774) |