| کد وضعیت HTTP | معنی کد وضعیت |
|---|
| 100 | صفحه‌کلاینت باید در ارسال درخواست‌ها ادامه دهد. این پاسخ موقت برای اطلاع دادن به صفحه‌کلاینت که برخی از درخواست‌های آن توسط سرور دریافت شده و رد نشده‌اند، استفاده می‌شود. صفحه‌کلاینت باید باقی‌مانده درخواست‌ها را ارسال کند، یا پاسخ را نادیده بگیرد اگر درخواست تکمیل شده باشد. سرور باید پس از تکمیل درخواست، پاسخ نهایی به صفحه‌کلاینت ارسال کند. |
| 101 | سرور درخواست مشتری را درک کرده و از طریق سربرگ بهبود (Upgrade) به مشتری اطلاع خواهد داد که از پروتکل دیگری برای تکمیل درخواست استفاده کند. پس از ارسال آخرین خط خالی در پاسخ، سرور به پروتکل‌هایی که در سربرگ بهبود تعریف شده‌اند، تغییر خواهد کرد. اقدامات مشابه تنها باید زمانی انجام شوند که تغییر به پروتکل جدید بهتر باشد. به عنوان مثال، تغییر به نسخه جدید HTTP نسبت به نسخه قدیمی مزایای بیشتری دارد، یا تغییر به واقع}}-زمان و پروتکل همزمان برای ارائه منابعی که از این ویژگی‌ها بهره‌مند می‌شوند. |
| 102 | کد وضعیت گسترش‌یافته توسط WebDAV (RFC 2518) نشان‌دهنده ادامه پردازش است. |
| 200. | درخواست موفقیت‌آمیز بود و سرور سربرگ‌های پاسخ یا بدنه‌های داده مورد آرزو را با پاسخ بازگردانده است. |
| 201 | درخواست انجام شده است و یک منبع جدید بر اساس نیازهای درخواست ایجاد شده است و URI آن با سرور لوکیشن بازگردانده شده است. اگر منبع مورد نیاز نتواند به موقع ایجاد شود، '202 پذیرفته شده' باید بازگردانده شود. |
| 202 | سرور درخواست را پذیرفته است، اما هنوز پردازش نکرده است. مانند اینکه ممکن است رد شود، درخواست ممکن است در نهایت اجرا شود یا نشود. در مورد عملیات‌های همزمان، هیچ راهی برای انجام این کار بهتر از ارسال این کد وضعیت وجود ندارد. هدف بازگشت یک 202 پاسخ کد وضعیت برای اجازه دادن به سرور برای پذیرش درخواست‌های دیگر فرآیندها (مانند پارتی-عملیات پایه‌ای که تنها یک بار در روز انجام می‌شود) بدون نیاز به نگه داشتن ارتباط مشتری با سرور تا زمان اتمام عملیات پارتی، انجام می‌شود. در پاسخ به پذیرش درخواست برای پردازش و بازگشت یک 202 کد وضعیت، موجودیت بازگردانده شده باید شامل برخی اطلاعات نشان‌دهنده‌ی وضعیت فعلی فرآیند باشد، همچنین یک اشاره‌گر به نظارت یا پیش‌بینی وضعیت فرآیند، تا کاربر بتواند تخمین بزند که آیا عملیات به پایان رسیده است یا خیر. |
| 203 | سرور درخواست را با موفقیت پردازش کرده است، اما اطلاعات سربرگ موجودیت بازگردانده شده معتبر نیست و یک مجموعه‌ی قاطع بر روی سرور اصلی نیست، بلکه محلی یا سومین-کپی‌کننده. اطلاعات فعلی ممکن است زیر مجموعه یا زیادتر از نسخه‌ی اصلی باشد. به عنوان مثال، متاداده‌ای که شامل منابع است ممکن است باعث شود سرور اصلی متاداده‌ی فوقانی را بداند. استفاده از این کد وضعیت لازم نیست و تنها در صورت بازگشت 200 OK بدون این کد وضعیت. |
| 204 | سرور درخواست را با موفقیت پردازش کرد، اما نیاز ندارد که هیچ محتوای فیزیکی بازگرداند و می‌خواهد اطلاعات متا به‌روز شده را بازگرداند. پاسخ می‌تواند به صورت یک سربرگ موجودیت باشد که اطلاعات متا جدید یا به‌روز شده را بازمی‌گرداند. اگر این اطلاعات سربرگ وجود داشته باشد، باید با متغیر درخواست شده مطابقت داشته باشد. اگر سمت مشتری یک مرورگر باشد، مرورگر کاربر باید صفحه‌ای که درخواست را ارسال کرده است را بدون هیچ تغییری در نمایه‌ی مستند نگه دارد، حتی اگر اطلاعات متا جدید یا به‌روز شده باید بر اساس специفیکیشن به مستند در نمایه‌ی فعال مرورگر کاربر اعمال شوند. چون 204 پاسخی که شامل هیچ پیام‌بدنه‌ای نمی‌تواند باشد، همیشه با اولین خط خالی پس از سربرگ پایان می‌یابد. |
| 205 | سرور درخواست را با موفقیت پردازش کرد و هیچ‌چیزی بازگرداند. اما برخلاف 204 پاسخ، پاسخی که این کد وضعیت را بازمی‌گرداند، نیاز دارد که درخواست‌کننده نمایه‌ی مستند را بازسازد. این پاسخ به طور اصلی برای بازسازندگی فرم بلافاصله پس از پذیرش ورودی کاربر استفاده می‌شود تا کاربر بتواند به راحتی ورودی دیگری را شروع کند. مانند 204 پاسخ باشد، این پاسخ نیز ممنوع است که شامل هرگونه بدنه پیام باشد و با اولین خط خالی پس از سربرگ پایان یابد. |
| 206 | سرور با موفقیت بخشی از درخواست GET را پردازش کرده است. ابزارهای بارگذاری HTTP مانند FlashGet یا Xunlei از این نوع پاسخ برای پیاده‌سازی ادامه قطع یا تقسیم یک مستند بزرگ به بخش‌های بارگذاری چندگانه برای بارگذاری همزمان استفاده می‌کنند. درخواست باید شامل سربرگ Range برای نشان‌دهی محدوده محتوایی که سمت مشتری می‌خواهد، باشد و ممکن است شامل If-Range به عنوان شرط درخواست. پاسخ باید شامل سربرگ‌های زیر باشد: Content-Range برای نشان‌دهی محدوده محتوایی که در این پاسخ بازمی‌گردانده می‌شود؛ اگر آن چند بخشی است،-دانلود بخشی از محدوده با Content-Type multipart/byteranges باشد، هر بخش چند بخش باید شامل یک Content-سربرگ Range برای نشان‌دهی محدوده محتوای این بخش استفاده می‌شود. اگر پاسخ شامل Content-Length استفاده کند، ارزش آن باید با تعداد واقعی بایت‌های محدوده محتوایی که بازمی‌گرداند، مطابقت داشته باشد. تاریخ ETag و/یا Content-Location، اگر درخواست مشابه باید یک 2پاسخ 00. Expires، Cache-کنترل و/یا Vary استفاده کند و اگر ارزش آن ممکن است از ارزش مطابقت‌شده با پاسخ‌های دیگر به همان متغیر قبل متفاوت باشد. اگر این درخواست پاسخ از If-بررسی قوی کش Range، این پاسخ نباید شامل سربرگ‌های دیگر موجودیت باشد؛ اگر این درخواست پاسخ از If-بررسی قوی کش Range، این پاسخ نباید شامل سربرگ‌های دیگر موجودیت باشد؛ این از ناهماهنگی‌ها بین محتوای موجودیت ذخیره‌شده و اطلاعات سربرگ‌های موجودیت به‌روز جلوگیری می‌کند. در غیر این صورت، این پاسخ باید شامل تمامی زمینه‌های سربرگ موجودیت باشد که باید در یک 2پاسخ 00 مطابقت ندارند، کش سمت مشتری باید از ترکیب محتوایی که در-Modified پشتیبانی نمی‌کند و دقیقاً با سربرگ‌های محتوایی که در 206 پاسخ با هر محتوای ذخیره‌شده قبلی ممنوع است. هر کشی که از Range و سربرگ-سربرگ Range از ذخیره محتوای بازگشتی توسط 206 پاسخ. |
| 207 | کد وضعیت گسترش‌یافته توسط WebDAV (RFC 2518) نشان‌دهنده این است که بدنه پیام بعدی یک پیام XML خواهد بود و ممکن است مجموعه‌ای از کدهای پاسخ مستقل بسته به تعداد زیرمتن‌های قبلی داشته باشد.-است. |
| 300 | رایانه‌ای مورد درخواست دارای مجموعه‌ای از گزینه‌های بازخورد است، هر کدام دارای آدرس خاص خود و درخواست‌های مرورگر-اطلاعات. کاربر یا مرورگر می‌تواند آدرسی را برای هدایت به آن انتخاب کند. مگر اینکه این درخواست HEAD باشد، پاسخ باید شامل جسمی باشد که لیستی از ویژگی‌ها و آدرس‌های منبع را شامل شود که کاربر یا مرورگر می‌تواند آدرس هدایت مناسب را از آن‌ها انتخاب کند. فرمت این جسم توسط فرمتی که توسط Content-نوع. مرورگر ممکن است بر اساس فرمت پاسخ و قابلیت‌های خود به طور خودکار بهترین انتخاب را انجام دهد. البته، مذاکره محور شده توسط RFC 2616 این استاندارد مشخص نمی‌کند که چگونه باید این انتخاب خودکار انجام شود. اگر سرور خود به خود یک انتخاب پیشنهادی برای بازخورد دارد، URI بازخورد باید در Location مشخص شود؛ مرورگرها ممکن است از این مقدار Location به عنوان آدرس برای هدایت خودکار استفاده کنند. علاوه بر این، مگر اینکه به طور متفاوت مشخص شده باشد، پاسخ نیز قابل ذخیره‌سازی است. |
| 301 | رایانه‌ای مورد درخواست به طور دائمی به مکان جدیدی منتقل شده است و هرگونه اشاره‌ای به این منبع باید از یکی از چند URI که توسط این پاسخ بازگردانده می‌شود استفاده کند. اگر امکان دارد، سمت مشتری با قابلیت ویرایش لینک‌ها، آدرس درخواست شده را به آدرسی که از سرور بازگردانده شده تغییر دهد. مگر اینکه به طور متفاوت مشخص شده باشد، این پاسخ نیز قابل ذخیره‌سازی است. URI دائمی جدید باید در فیلد Location پاسخ بازگردانده شود. مگر اینکه این درخواست HEAD باشد، جسم پاسخ باید شامل یک هیلینک به URI جدید و توضیح مختصری باشد. اگر این درخواست GET یا HEAD نباشد، مرورگر از خود به خود به مسیر جدید هدایت نمی‌شود مگر اینکه توسط کاربر تأیید شود، زیرا شرایط درخواست ممکن است به دلیل این تغییر تغییر کند. توجه: برای برخی مرورگرها که از استاندارد HTTP استفاده می‌کنند،/1.0 پروتکل، وقتی درخواست POST ارسال می‌کنند و دریافت می‌کنند 301 پاسخ، درخواست هدایت بعدی GET خواهد بود. |
| 302 | منبع درخواست شده اکنون به درخواست از یک URI دیگر به صورت موقت پاسخ می‌دهد. چون این هدایت‌ها موقت هستند، سمت مشتری باید درخواست‌های آینده خود را به آدرس اصلی ارسال کند. این پاسخ فقط قابل ذخیره‌سازی است اگر در Cache-کنترل یا Expires. URI موقت جدید باید در فیلد Location پاسخ بازگردانده شود. مگر این که این درخواست HEAD باشد، باید موجودیت پاسخ شامل یک لینک فراگیر به URI جدید و توضیح مختصری باشد. اگر این درخواست GET یا HEAD نباشد، مرورگر به خودکار هدایت کردن ممنوعیت می‌کند مگر این که توسط کاربر تأیید شود، زیرا شرایط درخواست ممکن است به دلیل این تغییر کند. توجه داشته باشید که although the RFC 1945 و RFC 2068 مشخصات اجازه نمی‌دهد که سمت مشتری روش درخواست را در هنگام هدایت تغییر دهد، بسیاری از مرورگرهای موجود به 302 پاسخ به عنوان 303 پاسخ و استفاده از GET برای دسترسی به URI مشخص شده در Location، روش درخواست اصلی را نادیده بگیرد. کدهای وضعیت 303 و 307 اضافه شده‌اند تا وضوح بیشتری در مورد انتظارات سرور از سمت مشتری داشته باشد. |
| 303 | پاسخ به درخواست فعلی در یک URI دیگر قابل یافتن است و سمت مشتری باید دسترسی GET به این منبع داشته باشد. این روش اصلی‌ترین دلیل برای اجازه دادن به اسکریپت‌ها است-درخواست POST فعال شده است تا به منبع جدیدی هدایت شود. این URI جدید جایگزین مرجع اصلی نیست. همچنین، 303 پاسخ‌ها ممنوع است که در مخزن ذخیره شوند. البته، درخواست دوم (ریشه‌یابی) ممکن است در مخزن ذخیره شود. URI جدید باید در میدان Location پاسخ بازگردانده شود. مگر اینکه این درخواست HEAD باشد، باید بدنه پاسخ حاوی یک لینک فراگیر به URI جدید و توضیح مختصر باشد. توجه: بسیاری از مرورگرهای قبل از HTTP}}/1.1 نمی‌فهمند 303 اگر نیاز به در نظر گرفتن تعامل با این مرورگرها دارید، 302 کافی باشد، زیرا بیشتر مرورگرها وضعیت را به درستی مدیریت می‌کنند 302 پاسخ‌ها دقیقاً به همان روشی که در بالا مشخص شده است، مشتری باید با آن‌ها برخورد کند 303 پاسخ‌ها. |
| 304 | اگر سمت مشتری درخواست GET شرطی ارسال کند و درخواست مجاز باشد و محتوای مستند تغییر نکرده باشد (از آخرین بازدید یا بر اساس شرایط درخواست)، سرور باید این کد وضعیت را بازگرداند. 304 پاسخ‌ها ممنوع است که شامل بدنه پیام باشند، بنابراین همیشه با اولین خط خالی بعد از سربرگ پایان می‌یابند. پاسخ باید شامل اطلاعات سربرگ زیر باشد: تاریخ، مگر اینکه این سرور بدون ساعت باشد.
اگر سرور بدون ساعت نیز این قوانین را دنبال کند، سپس سرور پروکسی و سمت مشتری می‌توانند خود به خود میدان تاریخ را به سربرگ پاسخ دریافتی اضافه کنند (مانند آنچه در RFC 2068)، و مکانیزم ذخیره‌سازی به خوبی کار خواهد کرد. ETag و/یا Content-Location، اگر درخواست مشابه باید یک 2پاسخ 00. Expires، Cache-کنترل و/یا Vary، اگر ارزش آن ممکن است از ارزش مربوط به پاسخ‌های دیگر به همان متغیر قبل متفاوت باشد.
اگر درخواست پاسخ استفاده از تأیید قوی مخزن باشد، پس این پاسخ نباید شامل سایر سربرگ‌های موجودیت باشد؛ در غیر این صورت (مثلاً درخواست GET شرطی از تأیید ضعیف مخزن استفاده می‌کند)، این پاسخ ممنوع است که شامل سایر سربرگ‌های موجودیت باشد؛ این کار از ناهمگونی بین محتوای موجودیت مخزن و اطلاعات سربرگ موجودیت به‌روز جلوگیری می‌کند. اگر یک 304 پاسخ نشان می‌دهد که موجودیت فعلاً در ذخیره‌سازی وجود ندارد، سیستم ذخیره‌سازی باید پاسخ را نادیده بگیرد و درخواست‌های مکرر بدون محدودیت ارسال کند.
اگر یک 304 پاسخی که برای به‌روزرسانی ورودی ذخیره‌سازی دریافت می‌شود، سیستم ذخیره‌سازی باید کل ورودی را به‌روزرسانی کند تا مقادیر تمام فیلدهایی که در پاسخ به‌روزرسانی شده‌اند، منعکس شوند. |
| 305 | منابع درخواست شده باید از طریق پروکسی مشخص شده دسترسی پیدا کنند. اطلاعات URI پروکسی مشخص شده در فیلد Location داده شده است. گیرنده باید درخواست‌های جداگانه‌ای را برای دسترسی به منابع مربوطه از طریق این پروکسی ارسال کند. تنها سرور اصلی می‌تواند یک 305 پاسخ. توجه: هیچ توضیح مختصری وجود ندارد 305 پاسخ در RFC 2068 برای هدایت یک درخواست خاص، و تنها می‌تواند توسط سرور اصلی ایجاد شود. نادیده گرفتن این محدودیت‌ها می‌تواند منجر به عواقب امنیتی جدی شود. |
| 306 | در جدیدترین نسخه از спецификация، 306 کد وضعیت دیگر استفاده نمی‌شود. |
| 307 | منابع درخواست شده اکنون به درخواست‌ها از URI متفاوتی پاسخ می‌دهد. از آنجایی که این هدایت‌ها موقت هستند، سمت مشتری باید درخواست‌های آینده خود را به آدرس اصلی ارسال کند. این پاسخ تنها اگر در Cache مشخص شده باشد قابل ذخیره‌سازی است.-کنترل یا تاریخ انقضا. URI موقت جدید باید در فیلد Location پاسخ بازگردانده شود. مگر اینکه این درخواست HEAD باشد، موجودیت پاسخ‌دهنده باید یک لینک فراتواننده به URI جدید و توضیح مختصری داشته باشد. از آنجایی که برخی مرورگرها این لینک‌ها را تشخیص نمی‌دهند 307 برای اینکه کاربر بتواند این اطلاعات را درک کند و دسترسی به URI جدید را درخواست کند، باید این اطلاعات به اطلاعات بالا اضافه شود.
اگر این درخواست GET یا HEAD نباشد، مرورگر به خودی خود به سمت آدرس جدید هدایت نمی‌کند مگر اینکه کاربر تأیید کند، زیرا شرایط درخواست ممکن است به دلیل این تغییر کند. |
| 400 | 1. معناشتباه است و درخواست فعلی نمی‌تواند توسط سرور درک شود. مگر اینکه تغییر کند، سمت مشتری نباید درخواست را تکراراً ارسال کند. 2. پارامترهای درخواست اشتباه هستند. |
| 401 | درخواست فعلی نیاز به احراز هویت کاربر دارد. پاسخ باید شامل یک WWW-عنوان احراز هویت برای منابع درخواست شده برای درخواست اطلاعات از کاربر. سمت مشتری می‌تواند درخواستی با اطلاعات عنوان احراز هویت مناسب مجدداً ارسال کند. اگر درخواست فعلی شامل گواهینامه‌های احراز هویت باشد، 401 پاسخ نشان می‌دهد که سرور این گواهینامه‌ها را رد کرده است. اگر 401 پاسخ شامل همان جستجوی احراز هویت مانند پاسخ قبلی است و مرورگر حداقل یک بار تلاش برای احراز هویت کرده است، سپس مرورگر باید اطلاعات موجودیت را که در پاسخ شامل شده است به کاربر نشان دهد، زیرا این اطلاعات موجودیت ممکن است شامل اطلاعات تشخیصی مرتبط باشد. ببینید RFC 2617. |
| 402 | این کد وضعیت برای نیازهای احتمالی آینده رزرو شده است. |
| 403 | سرور درخواست را درک کرده است، اما از اجرای آن خودداری کرده است. برخلاف یک 401 پاسخ، احراز هویت کمک نمی‌کند و درخواست نباید تکرار شود. اگر این درخواست HEAD نباشد و سرور بخواهد بتواند دلیل اینکه درخواست نمی‌تواند اجرا شود را توضیح دهد، دلیل رد باید در داخل موجودیت توضیح داده شود. البته، سرور می‌تواند یک 404 پاسخ اگر نمی‌خواهد هیچ اطلاعاتی به سمت سمت مشتری ارائه دهد. |
| 404 | درخواست با شکست مواجه شد و منابع مورد نظر در سرور پیدا نشد. هیچ اطلاعاتی برای اطلاع دادن به کاربر که وضعیت موقت یا دائمی‌است وجود ندارد. اگر سرور از این وضعیت مطلع باشد، 410 کد وضعیت باید برای اطلاع دادن منابع قدیمی که به دلیل مکانیزم‌های داخلی تنظیمات دائمی‌نشدنی هستند و هیچ آدرسی برای پرش به آن وجود ندارد، استفاده شود. 404 کد وضعیت به طور گسترده‌ای استفاده می‌شود زمانی که سرور نمی‌خواهد دلیل رد درخواست را نشان دهد یا هیچ پاسخ مناسب دیگری در دسترس نیست. |
| 405 | بازگرداند. 405 روش درخواست مشخص شده در خط درخواست نمی‌تواند برای درخواست منبع مربوطه استفاده شود. پاسخ باید سربرگ Allow را بازگرداند که لیستی از روش‌های درخواستی که می‌توانند توسط منبع فعلی پذیرفته شوند، نشان می‌دهد. از آنجایی که روش‌های PUT و DELETE منابع سرور را می‌نویسند، بیشتر سرورهای وب این روش‌ها را به طور پیش‌فرض پشتیبانی نمی‌کنند یا اجازه نمی‌دهند و به جای آن‌ها یک |
| 406 | خطای مربوط به این درخواست‌ها.-ویژگی‌های محتوای منبع درخواست شده با شرایط سربرگ درخواست هماهنگ نیست، بنابراین نمی‌توان یک موجودیت پاسخ ایجاد کرد. مگر اینکه این درخواست HEAD باشد، پاسخ باید موجودیتی بازگرداند که کاربر یا مرورگر بتواند ویژگی‌های موجودیت مناسب و لیست آدرس‌ها را انتخاب کند. فرمت موجودیت توسط نوع رسانه‌ای که در سربرگ Content تعریف شده تعیین می‌شود. |
| 407 | سربرگ نوع. مرورگر می‌تواند بهترین انتخاب را بر اساس فرمت و توانایی‌های خود انجام دهد. اما، спецификация هیچ معیاری برای انجام انتخاب‌های خودکار از این نوع تعریف نمی‌کند. 401 مشابه-برای احراز هویت احراز هویت کنید. سمت مشتری می‌تواند پاسخ پروکسی را بازگرداند، اما سمت مشتری باید در سرور پروکسی احراز هویت کند. سرور پروکسی باید سربرگ پروکسی را بازگرداند.-سربرگ تأیید هویت برای احراز هویت. ببینید RFC 2617. |
| 408 | درخواست زمان‌گذشت. سمت مشتری در مدت زمانی که سرور آماده انتظار بود، درخواست را ارسال نکرد. سمت مشتری می‌تواند در هر زمان درخواست را بدون هیچ تغییراتی مجدداً ارسال کند. |
| 409 | درخواست نمی‌تواند به دلیل اختلاف با وضعیت فعلی منبع درخواست شده تکمیل شود. این کد فقط مجاز به استفاده است اگر فرض شود کاربر قادر به حل اختلاف است و درخواست جدیدی را مجدداً ارسال خواهد کرد. پاسخ باید اطلاعات کافی را برای کاربر فراهم کند تا منبع اختلاف را شناسایی کند. اختلافات معمولاً در پردازش درخواست‌های PUT رخ می‌دهند. به عنوان مثال، در یک نسخه-محیط بررسی شده، اگر اطلاعات نسخه پیوسته به یک PUT}}-درخواست اصلاحی ارائه شده برای یک منبع خاص با یک درخواست قبلی (سومین-درخواست یک طرفه (، سرور باید یک 409 خطای اطلاع‌رسانی به کاربر که درخواست نمی‌تواند تکمیل شود.
در این نقطه، احتمالاً بدنه پاسخ شامل مقایسه تفاوت‌ها بین دو نسخه متعارض خواهد بود، تا کاربر بتواند نسخه ترکیبی را دوباره ارسال کند. |
| 410 | منبع درخواست شده دیگر در سرور موجود نیست و هیچ آدرس انتقال معتبری ندارد. این وضعیت باید دائمی تلقی شود. اگر امکان دارد، مشتری با قابلیت ویرایش لینک باید با اجازه کاربر، تمام ارجاعات به این آدرس را حذف کند. اگر سرور نمی‌داند یا نمی‌تواند تعیین کند که آیا این وضعیت دائمی است یا نه، پس یک 404 کد وضعیت باید استفاده شود. مگر اینکه مشخص شود، این پاسخ قابل ذخیره‌سازی در کش است. هدف از 410 پاسخ اصلی برای کمک به وب‌مستر در نگهداری وب‌سایت، اطلاع دادن به کاربر که منبع دیگر موجود نیست و صاحب سرور می‌خواهد تمام اتصالات دوربرد به این منبع حذف شوند.
این نوع رویداد در زمان معمولی-محدود، ارزش-خدمات اضافه شده. به طور مشابه، 410 پاسخ استفاده می‌شود تا به مشتری اطلاع دهد که منابعی که ابتدا به یک فرد تعلق داشتند دیگر در این سرور موجود نیستند. البته، این کاملاً بستگی به صاحب سرور دارد که آیا تمام منابع قابل دسترسی دائمی را به عنوان 'Gone' علامت‌گذاری کند یا نه. 410 وضعیت 'Gone' و مدت زمانی که این نشانه نگه داشته می‌شود. |
| 411 | سرور درخواست را بدون تعریف محتوا رد می‌کند-سربرگ طول. پس از اضافه کردن محتوای معتبر-در سربرگ طول، طول بدنه درخواست را نشان می‌دهد، مشتری می‌تواند درخواست را دوباره ارسال کند. |
| 412 | سرور در زمان تأیید اینکه پیش‌شرط‌ها در حیطه فیلد هدر درخواست داده شده‌اند، موفق به برآورده کردن یکی یا چندین پیش‌شرط نشده است. این کد وضعیت به سمت مشتری اجازه می‌دهد که پیش‌شرط‌ها را در متاداده درخواست شده (فیلد هدر درخواست داده) تنظیم کند، بنابراین از اعمال روش درخواست به منابعی غیر از آنچه می‌خواهد جلوگیری می‌کند. |
| 413 | سرور از پردازش درخواست فعلی خودداری می‌کند زیرا درخواست بیش از مقدار جسمی‌ای را که سرور تمایل یا توانایی پردازش آن را دارد، ارسال می‌کند. در این حالت، سرور می‌تواند اتصال را ببندد تا از ادامه ارسال درخواست توسط سمت مشتری جلوگیری کند. اگر این وضعیت موقتی باشد، سرور باید یک Retry-پس از هدر پاسخ برای اطلاع دادن به سمت مشتری که چقدر زمان دارد می‌تواند دوباره تلاش کند. |
| 414 | URI درخواست شده طولانی‌تر از آن است که سرور بتواند آن را تفسیر کند، بنابراین سرور درخواست را رد می‌کند. این بسیار نادر است و موارد معمول شامل: فرم ارسالی که باید از روش POST استفاده می‌کرد، به روش GET تبدیل می‌شود و باعث می‌شود که رشته پرسش (Query String) بسیار طولانی شود. URIهای بازگشتی "سوراخ‌های سیاه"، مانند هر بازگشتی که از URI قدیمی به عنوان بخشی از URI جدید استفاده می‌کند، منجر به این می‌شود که URI پس از چندین بازگشت بسیار طولانی شود. کاربر سعی می‌کند سرور را با باگ‌های امنیتی که در برخی سرورها وجود دارد، مورد حمله قرار دهد.
این نوع سرور از یک-缓冲区 طولی برای خواندن یا دستکاری URI درخواست شده. وقتی پارامترهای بعد از GET از یک حد مشخص فراتر می‌روند، ممکن است پر شدن بیش از حد حافظه رخ دهد، که منجر به اجرای کدهای تصادفی می‌شود [1]. سرورهایی که چنین آسیب‌پذیری‌هایی ندارند باید یک 414 کد وضعیت. |
| 415 | برای روش درخواست فعلی و منابع درخواست شده، جسمی که در درخواست ارسال شده است، در فرمتی قرار دارد که سرور از آن پشتیبانی نمی‌کند، بنابراین درخواست رد می‌شود. |
| 416 | اگر درخواست شامل هدر رنج باشد و هیچ یک از محدوده‌های داده‌ای مشخص شده در رنج با محدوده موجود منابع فعلی همخوانی نداشته باشد و If-هدر رنج در درخواست تعریف نشده است، سرور باید یک 416 کد وضعیت. اگر Range از محدوده بایتی استفاده کند، این وضعیت به این معناست که موقعیت اولین بایت تمام محدوده‌های داده‌ای مشخص شده در درخواست از طول منابع فعلی بیشتر است. سرور باید همچنین محتوای Content را شامل شود-سربرگ Range entity با 416 کد وضعیت برای نشان‌دادن طول منابع فعلی. این پاسخ نیز ممنوع است از multipart استفاده کند/byteranges به عنوان محتوای-نوع. |
| 417 | محتوایی که در سربرگ درخواست مشخص شده و انتظار می‌رود توسط سرور برآورده نشود، یا سرور یک سرور پروکسی باشد که شواهد واضحی دارد که محتوای مورد انتظار نمی‌تواند در نقطه بعدی مسیر فعلی برآورده شود. |
| 421 | تعداد اتصال‌هایی که از آدرس آی‌پی اینترنتی که در آن سمت مشتری قرار دارد به سرور انجام می‌شود، از حداکثر مجاز سرور بیشتر است. معمولاً آدرس آی‌پی اینترنتی در اینجا به آدرس سمت مشتری از دید سرور اشاره دارد (مانند آدرس گیت‌وُی یا سرور پروکسی کاربر). در این حالت، شمارش اتصال ممکن است شامل بیش از یک کاربر نهایی باشد. |
| 422 | تعداد اتصال‌هایی که از آدرس آی‌پی اینترنتی که در آن سمت مشتری قرار دارد به سرور انجام می‌شود، از حداکثر مجاز سرور بیشتر است. معمولاً آدرس آی‌پی اینترنتی در اینجا به آدرس سمت مشتری از دید سرور اشاره دارد (مانند آدرس گیت‌وُی یا سرور پروکسی کاربر). در این حالت، شمارش اتصال ممکن است شامل بیش از یک کاربر نهایی باشد. |
| 422 | درخواست به درستی فرمت شده است، اما به دلیل خطای معنایی نمی‌توان به آن پاسخ داد. (RFC 4918 WebDAV) 423 قفل شده منابع فعلی قفل شده است. (RFC 4918 WebDAV) |
| 424 | درخواست فعلی به دلیل خطایی در درخواست قبلی، مانند PROPPATCH، شکست خورد. (RFC 4918 WebDAV) |
| 425 | تعریف شده در پیش‌نویس مجموعه‌های پیشرفته WebDav، اما نه در پروتکل پیاپی WebDAV (RFC 3658). |
| 426 | طرف مشتری باید به TLS تغییر کند/1.0. (RFC 2817) |
| 449 | توسعه‌یافته توسط مایکروسافت، درخواست‌ها باید پس از انجام عمل مناسب مجدداً تلاش شوند. |
| 500 | سرور با یک وضعیت غیرمنتظره مواجه شد که جلوگیری از تکمیل درخواست را به همراه داشت. معمولاً این مشکل وقتی که کد سرور فاش می‌شود، رخ می‌دهد. |
| 501 | سرور ویژگی مورد نیاز درخواست فعلی را پشتیبانی نمی‌کند. وقتی سرور روش درخواست شده را نمی‌تواند تشخیص دهد و نمی‌تواند درخواست خود را برای هر منبعی پشتیبانی کند. |
| 502 | وقتی سرور به عنوان گیت‌وُی یا پروکسی کار می‌کند و درخواستی را اجرا می‌کند، پاسخ نامعتبری از سرور بالادستی دریافت می‌کند. |
| 503 | سرور در حال حاضر به دلیل تعمیر موقت سرور یا اضافه بار نمی‌تواند درخواست‌ها را پردازش کند. این وضعیت موقت است و پس از مدتی بازپس گرفته خواهد شد. اگر زمان تأخیر قابل پیش‌بینی باشد، پاسخ می‌تواند شامل Retry باشد-پس از سربرگ برای نشان‌دهی زمان تأخیر. اگر زمان تأخیر قابل پیش‌بینی باشد، پاسخ می‌تواند شامل Retry-پس از ارائه اطلاعات، سمت مشتری باید آن را مانند این 5پاسخ 00. توجه: وجود یک 503 کد وضعیت معنای این را ندارد که سرور باید در صورت اضافه بار از آن استفاده کند. برخی از سرورها فقط می‌خواهند اتصال مشتری را رد کنند. |
| 504 | وقتی که سروری که به عنوان گیت‌واچ یا پروکسی کار می‌کند، تلاش می‌کند تا درخواستی را اجرا کند، نمی‌تواند به موقع پاسخی از سرور اولیه (شناخته شده به عنوان URI، مانند HTTP، FTP، LDAP) یا سرور ثانویه (مانند DNS) دریافت کند. توجه: برخی از سرورهای پروکسی به جای این 400 یا 5خطای 00 وقتی که درخواست DNS به پایان می‌رسد |
| 505 | سرور از نسخه HTTP مورد استفاده در درخواست پشتیبانی نمی‌کند یا از پشتیبانی امتناع می‌کند. این به این معنی است که سرور نمی‌تواند یا نمی‌خواهد از همان نسخه به عنوان سمت مشتری استفاده کند. پاسخ باید شامل یک موجودیت باشد که دلیل عدم پشتیبانی از نسخه را توضیح دهد و پروتکل‌هایی که سرور پشتیبانی می‌کند را معرفی کند. |
| 506 | گسترش یافته توسط پروتکل مذاکره محتوای شفاف (RFC 2295), این نشان‌دهنده یک خطای پیکربندی داخلی در سرور است: منبع متقاضی‌شده برای مذاکره به گونه‌ای پیکربندی شده است که از خودش برای مذاکره محتوای شفاف استفاده کند، بنابراین در فرآیند مذاکره مناسب نیست. |
| 507 | سرور نمی‌تواند محتوایی که برای تکمیل درخواست مورد نیاز است، ذخیره کند. این وضعیت موقت تلقی می‌شود. WebDAV (RFC 4918) |
| 509 | سرور به محدودیت پهنای باند رسیده است. این کد وضعیت رسمی نیست، اما همچنان به طور گسترده استفاده می‌شود. |
| 510 | قوانینی که برای بدست آوردن منابع مورد نیاز است، برآورده نمی‌شود. (RFC 2774) |
