خطاهای رایج صفحه وب

کدهای وضعیت HTTP اعداد سه رقمی هستند که اطلاعاتی در مورد وضعیت صفحه در اختیار مرورگرهای وب قرار می دهند. ممکن است هنگام مرور اینترنت برخی از این خطاها را مشاهده کنید یا ممکن است آنها را در حساب میزبانی خود دریافت کرده باشید.

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

۴۰۰ درخواست بد

سرور وب نتوانست یک اسکریپت نادرست را تجزیه کند. اغلب مشکلات برنامه نویسی باعث این مشکل می شود. برای حل این مشکل باید با توسعه دهنده یا ارائه دهنده نرم افزار خود صحبت کنید.

۴۰۱ احراز هویت مورد نیاز است

این صفحه برای دسترسی به آن به نام کاربری و رمز عبور نیاز دارد. اگر سعی کنید بدون آن به آن دسترسی پیدا کنید، یک پیام ۴۰۱ — احراز هویت لازم است دریافت می کنید.

۴۰۳ ممنوع

خطاهای ممنوعه زمانی نمایش دیتا می شوند که شخصی سعی می کند به یک فهرست، فایل یا اسکریپت بدون مجوزهای مناسب دسترسی پیدا کند. به عنوان مثال، اگر یک اسکریپت فقط برای کاربر قابل خواندن باشد و دیگران نتوانند به فایل دسترسی باشند، خطای ۴۰۳ را تماشا خواهند کرد.

فایل های فهرست نامعتبر و دایرکتوری های خالی نیز می توانند باعث خطای ۴۰۳ شوند. برای اطلاعات بیشتر، یکی از مقالات زیر را بر اساس نوع حساب میزبانی که دارید ببینید: cPanel / Plesk.

۴۰۴ پیدا نشد

اگر بازدیدکنندگان به URL هایی دسترسی پیدا کنند که وجود ندارند، خطاهای ۴۰۴ را دریافت می کنند. علت می تواند هر چیزی باشد، از URL های نامعتبر، فایل های از دست رفته، یا تغییر مسیر به URL هایی که دیگر وجود ندارند.

۵۰۰ خطای سرور داخلی

این یک خطای بسیار کلی است که به این معنی است که مشکلی در نمایش وب سایت وجود دارد، اما جزئیات به راحتی در دسترس نیستند. فایل‌های htaccess نامعتبر یا قوانین نامعتبر در آن‌ها معمولاً باعث ۵۰۰ خطا در حساب‌های میزبانی لینوکس می‌شوند. در ویندوز، معمولاً درخواست های نامعتبر از طریق یک فایل web.config است.

برای اینکه بفهمید چه چیزی باعث این مشکل می شود:

لینوکس – گزارش های خطای آپاچی خود را بررسی کنید.

Windows – با استفاده از کد زیر، خطاهای دقیق را در فایل web.config خود فعال کنید:

تعاریف کد وضعیت

هر کد وضعیت در زیر توضیح میدهند، از جمله روش(هایی) که می تواند دنبال کند و هرگونه اطلاعات فرااطلاعی مورد نیاز در پاسخ.

اطلاعاتی ۱xx

این کلاس از کد وضعیت یک پاسخ موقت را نشان می دهد که فقط از خط وضعیت و سرصفحه های اختیاری تشکیل و با یک خط خالی خاتمه می یابد. هیچ هدر مورد نیازی برای این کلاس از کد وضعیت وجود ندارد. از آنجایی که HTTP/1.0 هیچ کد وضعیت ۱xx را تعریف نکرده است، سرورها نباید پاسخ ۱xx را به کلاینت HTTP/1.0 ارسال کنند مگر در شرایط آزمایشی.

مشتری باید ready to  پذیرش یک یا چند پاسخ وضعیت ۱xx قبل از تنظیم قبل باشد، حتی اگر مشتری انتظار پیام وضعیت ۱۰۰ (continue) را نداشت باشد. یک عامل کاربر ممکن است پاسخ های وضعیت ۱xx غیرمنتظره را نادیده بگیرد.

پراکسی ها باید پاسخ های ۱xx را ارسال کنند، مگر اینکه ارتباط بین کارگزار و مشتری آن کلوز شد باشد یا نماینده پروکسی درخواست ایجاد پاسخ ۱xx را داشت باشد. (مثلاً اگر الف هنگام ارسال یک درخواست، پروکسی فیلد “Expect: 100-continue” را اضافه می کند. پس نیازی به ارائه ۱۰۰ پاسخ (ادامه) مربوطه ندارد.)

۱۰٫۱٫۱ ۱۰۰ ادامه دهید

مشتری باید به درخواست خود ادامه دهد. این پاسخ موقت به مشتری اطلاع می دهد که قسمت اولیه درخواست دریافت شد و هنوز توسط سرور رد نشد است. مشتری باید با ارسال باقیماند درخواست ادامه دهد یا اگر درخواست قبلاً تکمیل شد است، این پاسخ را نادیده بگیرد. سرور باید پس از تکمیل درخواست پاسخ نهایی را ارسال کند. بخش ۸٫۲٫۳ را برای بحث دقیق در مورد استفاده و نحوه استفاده از این کد وضعیت ببینید.

۱۰٫۱٫۲ ۱۰۱ پروتکل های سوئیچینگ

سرور از طریق فیلد هدر پیام ارتقاء (بخش ۱۴٫۴۲) درخواست مشتری را برای تغییر در پروتکل برنامه مورد استفاده در این اتصال می‌فهمد و مایل است از آن پیروی کند. سرور بلافاصله پس از خط خالی، پروتکل‌ها را به پروتکل‌هایی تغییر می‌دهد که توسط فیلد هدر Upgrade پاسخ تعریف شده‌اند، که پاسخ ۱۰۱ را خاتمه می‌دهد.

پروتکل باید تنها زمانی تغییر کند که انجام آن سودمند باشد. به عنوان مثال، جابه‌جایی به نسخه جدیدتر HTTP نسبت به نسخه‌های قدیمی‌تر مفید است، و تغییر به یک پروتکل همزمان و هم‌زمان ممکن است هنگام ارائه منابعی که از چنین ویژگی‌هایی استفاده می‌کنند مفید باشد.

۱۰٫۲ موفق ۲xx

این کلاس از کد وضعیت نشان می دهد که درخواست مشتری با موفقیت دریافت، درک و پذیرفته شده است.

۱۰٫۲٫۱ ۲۰۰ OK

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

• GET موجودی متناظر با منبع درخواستی در پاسخ ارسال می شود.
• HEAD فیلدهای entity-header مربوط به منبع درخواستی در پاسخ بدون هیچ پیامی ارسال می شوند.
• ارسال یک موجودیت که نتیجه عمل را توصیف یا حاوی آن است.
• TRACE یک موجودیت حاوی پیام درخواست دریافت شده توسط سرور پایانی است.

۱۰٫۲٫۲ ۲۰۱ ایجاد شد

این درخواست برآورده شد و منجر به ایجاد یک منبع جدید شد. منبع جدید ایجاد شده را می توان توسط URI(های) بازگردانده شده در موجودیت پاسخ، با خاص ترین URI برای کمک ارائه شده توسط فیلد سرصفحه مکان، ارجاع داد. پاسخ باید شامل موجودیتی باشد که شامل فهرستی از ویژگی‌های منبع و مکان (ها) باشد که کاربر یا عامل کاربر می‌تواند مناسب‌ترین را انتخاب کند. قالب موجودیت با نوع رسانه داده شده در قسمت سرصفحه Content-Type مشخص می شود. سرور مبدا باید قبل از بازگرداندن کد وضعیت ۲۰۱ منبع را ایجاد کند. اگر عمل را نمی توان فورا انجام داد، سرور باید با یک پاسخ ۲۰۲ (پذیرفته شده) پاسخ دهد.

یک پاسخ ۲۰۱ ممکن است حاوی یک فیلد سرصفحه پاسخ ETag باشد که مقدار فعلی تگ موجودیت را برای نوع درخواستی ایجاد شده نشان می دهد. بخش ۱۴٫۱۹ را ببینید.

۱۰٫۲٫۳ ۲۰۲ پذیرفته شد

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

پاسخ ۲۰۲ عمداً غیر تعهدی است. هدف آن این است که به سرور اجازه دهد تا درخواستی را برای برخی از فرآیندهای دیگر بپذیرد (شاید یک فرآیند دسته‌گرا که فقط یک بار در روز اجرا می‌شود) بدون اینکه نیازی به برقراری ارتباط عامل کاربر با سرور تا زمانی که فرآیند تکمیل شود ادامه یابد. نهادی که با این پاسخ بازگردانده می‌شود باید نشان‌دهنده وضعیت فعلی درخواست و یک اشاره‌گر به ناظر وضعیت یا تخمینی از زمانی که کاربر می‌تواند انتظار برآورده شدن درخواست را داشته باشد.

نتیجه

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