کدهای وضعیت HTTP: هر کد ممکن لیست شده

افشای: پشتیبانی شما به حفظ سایت کمک می کند! ما برای برخی از خدماتی که در این صفحه توصیه می کنیم هزینه ارجاع دریافت می کنیم.


Contents

مبانی وضعیت کد HTTP

اکثر مردم خیلی سخت فکر نمی کنند که چه اتفاقی می افتد هنگام حرکت به یک صفحه وب. آنها فقط مرورگر خود را باز می کنند ، روی چیزی کلیک می کنند ، و در آنجا روی صفحه من است!

به دنبال کد خاص هستید؟ نگاهی به جدول مطالب در سمت راست داشته باشید!

ما ترجیح می دهیم در مورد رقص پیچیده درخواست ها و پاسخ هایی که بین مرورگر وب رایانه و یک سرور دور از ذهن شما رخ می دهد ، در یک مرکز داده ، غیب (معمولاً) حتی توسط مدیر سیستم وب سایت و کارکنان IT فکر نکنیم..

اما پس از آن ، هر بار و یک بار ، ما با یک خطا مواجه می شویم. ما یک صفحه هوشمندانه 404 پیدا نشده با تصویر خنده دار دریافت می کنیم. یا یک صفحه خالی با یادداشتی از مرورگر خود دریافت می کنیم که در مورد برخی خطای ناشناخته 501 به ما خبر می دهد.

به عنوان یک بازدید کننده وب سایت معمولی ، این موضوع فقط آزار دهنده است. ما معمولاً دوباره امتحان می کنیم – تازه کردن ، بازگشت ، دوباره کلیک کنید. بعضی اوقات کار می کند – ما آنرا یک جلوه می نامیم و به سرعت فراموش می کنیم. بعضی اوقات کار نمی کند – ما آن را “وب سایت بد” می نامیم و معمولاً بلافاصله آن را فراموش می کنیم.

اما اگر واقعاً وب سایت راه اندازی می کنید – این همه چیز را تغییر می دهد. خطاهای HTTP آزار دهنده نیستند. آنها دیوانه هستند. آنها شرم آور هستند.

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

چگونه خطاهای HTTP را برطرف می کنید؟ چگونه می توانید از خطاهای HTTP جلوگیری کنید؟ معنی این همه کدهای وضعیت HTTP چیست?

این مواردی است که این راهنما به همراه اطلاعات در مورد:

  • کدهای وضعیت HTTP خوب (کدهایی که معمولاً مشاهده نمی کنید)
  • کدهای وضعیت HTTP مفید
  • از چه نوع تغییر مسیرهایی باید استفاده کنید (و چرا).

اما اول ، برای درک کدهای وضعیت HTTP ، باید درک کنید که چگونه HTTP در درجه اول کار می کند.

درخواست ها و پاسخ های HTTP

HTTP مخفف “پروتکل انتقال HyperText” است.

پروتکل چیست?

وقتی سوار یک کشتی نیروی دریایی هستید ، روش خاصی برای انجام کارها وجود دارد. ابتدا به پرچم سلام می کنید ، سپس به افسر درود می پردازید ، سپس برای سوار شدن از شما درخواست اجازه می کنید.

این یک پروتکل است.

پروتکل مجموعه ای از قوانین برای نوع خاصی از تعامل است.

بعضی اوقات پروتکل بسیار سفت و سخت است و تعریف می شود:

  • برای سوار شدن به کشتی:
    • پرچم سلام
    • درود بر افسر وظیفه
    • اجازه سوار شدن را بخواهید.

بعضی اوقات پروتکل ها کمی سست و نانوشته ، اما هنوز هم مشهور است:

  • وقتی کیک تولد شما فرا رسید:
    • صبر کنید تا همه خواندن را تمام کنند
    • آرزو کن
    • شمع ها را ترجیح دهید ، ترجیحاً با یک نفس.

تعامل رایانه همه چیز در مورد پروتکل ها است. هنگامی که دو کامپیوتر (یا شبکه ای از رایانه ها) با یکدیگر صحبت می کنند ، آنها باید یک مجموعه قوانین کاملاً تعریف شده برای برقراری ارتباط داشته باشند..

قوانینی برای برقراری ارتباط مرورگر وب رایانه محلی شما با سرور وب میزبان سایتی که می خواهید در آن جستجو کنید HTTP است (پروتکل انتقال HyperText).

چرا ما در حال انتقال HyperText هستیم?

در ابتدا ، صفحات وب در درجه اول اسناد بودند. “صفحه وب” به عنوان “صفحه” واقعی تصور می شد. یک سایت مجموعه ای از اسناد بود. صفحه اصلی یک سایت “فهرست” اسناد موجود بود.

چه نوع اسنادی؟ اسناد Hypertext.

Hypertext فقط بدان معنی است که اسناد به “لینکهای پیوندی” به یکدیگر پیوند دارند. امروز ما آنها را “پیوندهای” قدیمی نامیده ایم – اکنون آنها بسیار عادی هستند که دیگر آنها را “هایپر” نمی نامیم..

پیوندهای “هایپر” قابل کلیک در متن – این ایده ، که اکنون بسیار رایج است ، هنگامی که اولین بار ایننرنت ایجاد شد ، چنان انقلابی بود که همه چیز به این نام خوانده شد.

زبان تألیف این اسناد؟ زبان نشانه گذاری هایپرتکست (HTML). و پروتکل درخواست و دریافت این اسناد؟ HTTP.

بنابراین HTTP است …

HTTP مجموعه ای از قوانین و رویه ها برای چگونگی درخواست یک مرورگر وب (یا “مشتری” دیگر) از رایانه دیگر (“سرور”) است ، و اینکه چگونه رایانه دیگر به آن درخواست ها پاسخ می دهد..

درخواست HTTP

بنابراین ، وقتی یک آدرس را تایپ می کنید ، روی پیوندی کلیک می کنید یا در غیر این صورت یک صفحه وب را باز می کنید ، مرورگر شما در حال ارسال درخواست به برخی سرورهای دیگر است.

هدف درخواست توسط URL و سیستم DNS تعریف شده است. سیستم DNS موضوع دیگری برای یک روز دیگر است ، اما اساساً – DNS یک کتاب آدرس است که با نام های دامنه با آدرس های IP خاص رایانه مطابقت دارد..

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

  • نوع درخواست دو مورد متداول عبارتند از:
    • دریافت – “لطفا این منبع را برای من ارسال کنید.”
    • POST – “در اینجا داده هایی برای پردازش وجود دارد.”
  • Header Fields – زمینه های انتخاب داده متا اختیاری برای گفتن سرور در مورد مشتری (مثلاً چه نوع مرورگر) استفاده می شود.
  • بدن – داده های ارسال شده توسط مشتری (برای استفاده با POST).

سرور این درخواست را دریافت می کند و (پس از پردازش) پاسخی را ارسال می کند.

پاسخ HTTP

اولین خط پاسخ همان است وضعیت HTTP.

خط وضعیت دارای دو بخش است ، یک کد شماره (مانند 200) و توضیح متن (مانند موفقیت).

هنگامی که همه چیز خوب است ، وضعیت 200: موفقیت را دریافت می کنید (که شما به عنوان یک کاربر انسانی هرگز نمی بینید) ، سپس برخی از داده های سرصفحه (که شما نیز آن را نمی بینید) ، و سپس منابعی که درخواست کردید (همان چیزی است که شما مشاهده می کنید ).

این منبع ممکن است یک صفحه وب ، یک تصویر ، یک فیلم ، یک فایل صوتی باشد. همچنین ممکن است چیزی باشد که شما نمی بینید ، مانند پرونده جاوا اسکریپت یا صفحه سبک.

وقتی همه چیز خوب پیش نمی رود ، ممکن است پیامی درباره وضعیت مشاهده کنید. معمولاً هنگامی که چیزی مانند کد 404 یا 501 دریافت می کنید ، این اتفاق می افتد. کد های خطا هستند مشکلی پیش آمد.

پاسخ های دارای کد خطای 404 یا 501 با منبع درخواستی شما برنخواهند گشت. بعضی اوقات آنها با یک منبع متفاوت (مانند صفحه هوشمند 404) برمی گردند. بعضی اوقات منبع به هیچ وجه وجود ندارد (این هنگامی است که شما صفحه خالی مرورگر و پیام خطای پیش فرض را دریافت می کنید).

همچنین کدهای وضعیتی وجود دارند که به مرورگر می گویند مانند تغییر مسیر 301 به مرور مکان دیگری نگاه کند. این پاسخ ها همچنین به منبع درخواستی نمی رسند.

در عوض ، داده های هدر به مرورگر می گوید درخواست جدیدی را با برخی URL دیگر ایجاد کند. معمولاً متوجه نمی شوید که چه اتفاقی بیفتد ، زیرا مرورگر شما فقط آنچه را گفته است را انجام می دهد و درخواست دوم را انجام می دهد.

سپس این منبع را از پاسخ دوم به شما نشان می دهد ، بدون آنکه به شما بگویم هر اتفاقی افتاده است. کدهای پاسخگویی تغییر مسیر معمولاً برای کاربران نهایی مهم نیست ، اما آنها باید برای مدیران وب سایت اهمیت زیادی داشته باشند.

کلاس های کد وضعیت

احتمالاً متوجه شده اید که تمام کدهای وضعیت شماره های سه رقمی هستند. آیا متوجه شده اید که رقم اول همیشه بین 1 تا 5 است?

کدهای وضعیت به پنج “کلاس” کدها گروه بندی می شوند. خطای 404: Not Found بخشی از كدهای وضعیت 400 (یا ، بعضی اوقات ، 4xx) است. هر کلاس طیف خاصی از موضوعات یا حالات را در بر می گیرد.

  • 1xx – اطلاعاتی – اینها پاسخهای موقتی در نظر گرفته شده برای استفاده هستند در حالی که سرور به پردازش درخواست ادامه می دهد. آنها به ندرت مورد استفاده قرار می گیرند.
  • 2xx – موفقیت – کدهای مورد استفاده در هنگام کار ، همانطور که قرار است کار کنند. کدهای موفقیت مختلف بر اساس آنچه مشخص شده است ، درخواست درخواست شده است.
  • 3xx – تغییر مسیر – کدهایی که به مشتری گفته می شود منابع مورد نظر را در جایی دیگر جستجو کند.
  • 4xx – خطای مشتری – این کدها به مشتری می گویند که کار اشتباهی انجام داده است.
  • 5xx – خطای سرور – کد زمانی را که انتظار می رود چیزی در سرور کار نکند ، کد کنید.

ما کدهای خاص از هر کلاس را با عمق بیشتری در بخش های خود پوشش خواهیم داد.

برخورد با کدهای وضعیت HTTP (و خطا)

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

کد وضعیت HTTP 1xx – اطلاعاتی

دانش قدرت است. اطلاعات آزاد کننده است.

— کوفی عنان

کدهای وضعیت HTTP در کلاس 1xx در نظر گرفته شده به صورت موقت هستند ، قبل از ارسال پاسخ دوم کامل و کامل توسط سرور ارسال می شود.

آنها در HTTP / 1.1 معرفی شدند ، بنابراین مرورگرهای اولیه که HTTP / 1.0 را اجرا می کنند نمی توانند از عهده آن برآیند و سرورها نباید در این موارد کدهای 1xx را پایان دهند..

HTTP 100 ادامه دهید

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

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

در این موارد ، مشتری (مرورگر) ممکن است درخواست اولیه را با یک هدر ارسال کند که شامل انتظار: 100-ادامه است.

در صورت وقوع ، سرور درخواست اولیه را دریافت می کند و – اگر همه چیز خوب نیست – با وضعیت 100: ادامه دهید. این به مشتری برای تکمیل درخواست سیگنال می دهد.

اگر همه چیز درست نباشد ، سرور یک انتظار 417 را با موفقیت ارسال می کند.

پروتکل های سوئیچینگ HTTP 101

مشتری می تواند از یک سرور بخواهد پروتکل ها را تغییر دهد ، به عنوان مثال از HTTP / 1.1 به HTTP / 2.0.

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

پردازش HTTP 102

این کد فقط با WebDAV استفاده می شود ، که افزونه ای از HTTP است که توانایی دستکاری فایل را فراهم می کند ، تا حدودی شبیه به FTP (هرچند در اجرای واقعی بسیار متفاوت است).

یک درخواست WebDAV ممکن است شامل درخواست های فرعی زیادی باشد. وضعیت 102: پردازش به مشتری این امکان را می دهد که سرور درخواست را دریافت کند و روی آن کار می کند ، اما هنوز کار دارد. این باعث می شود مشتری از فرض درخواست از بین نرود و زمان بندی شود.

کد وضعیت HTTP 2xx – موفقیت

تنها چیزی که شما در این زندگی نیاز دارید جهل و اعتماد به نفس است ، و سپس موفقیت مطمئن است.

– مارک تواین

کدهای وضعیت HTTP در کلاس 2xx در صورت تکمیل درخواست همانطور که در نظر گرفته شده استفاده می شوند.

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

HTTP 200 خوب

این پاسخ استاندارد برای درخواست های موفق است – این کد وضعیتی است که شما معمولاً می خواهید و انتظار دارید.

وقتی درخواست GET (درخواست منبع) باشد ، پاسخ شامل منبع خواهد بود. وقتی درخواست POST (یا نوع دیگری) است ، پاسخ شامل منبعی خواهد بود که نتیجه عمل را توصیف یا شامل می کند.

HTTP 201 ایجاد شده است

برخی از درخواست ها برای ایجاد منبع جدید در نظر گرفته شده است. با موفقیت کامل ، وضعیت 201 ارسال می شود تا نشان دهد منبع جدید ایجاد شده است. این معمولاً در رابطه با نوع درخواست PUT استفاده می شود.

HTTP 202 پذیرفته شد

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

اطلاعات غیر معتبر HTTP 203

پاسخ شامل منبع درخواست شده است ، اما این منبع ممکن است از منبع دیگری به دست آمده باشد ، بنابراین ممکن است غیرقابل اعتماد باشد – سرور اعتبار یا صحت منبع را تضمین نمی کند..

HTTP 204 بدون محتوا

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

وقتی درخواست 204 ارسال می شود ، نماینده کاربر (مشتری یا مرورگر وب) به طور خاص قرار نیست نظر خود را تغییر دهد.

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

تنظیم مجدد محتوا HTTP 205

پاسخ 205 شبیه به 204 است ، اما نماینده کاربر قرار است نظر خود را به حالت پیش فرض مستند فعلی بازگرداند.

محتوای جزئی HTTP 206

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

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

  • مشتری: 1/4 اول را به من بدهید.
    • سرور: 206 محتوای جزئی
  • مشتری: دوم را به من بدهید

    1/4.

    • سرور: 206 محتوای جزئی.
  • و غیره …
    • … و غیره.

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

HTTP 207 چند وضعیت

مانند 103 ، این فقط در WebDAV استفاده می شود.

یک درخواست WebDAV می تواند چندین درخواست فرعی داشته باشد که هرکدام وضعیت و پاسخ خود را دارند. وضعیت 207 نشان می دهد که بدنه پاسخ شامل یک سند XML است که جزئیات وضعیت و پاسخ های هر درخواست زیر را شرح می دهد.

HTTP 208 قبلاً گزارش شده است

کد وضعیت دیگری که فقط WebDAV است. این بدان معنی است که اعضای یک اتصال دهنده DAV قبلاً در پاسخ قبلی به درخواست فعلی شمرده شده اند ، و دوباره درج نمی شوند.

HTTP 226 IM استفاده می شود

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

کد وضعیت HTTP 3xx – تغییر مسیر

هر وقت چیزی را رها کردید ، باید آن را با چیزی جایگزین کنید.

– لو هولتز

به منظور تکمیل درخواست ، اساسنامه در کلاس 3xx ارسال می شود که اقدامات بیشتری از طرف مشتری انجام شود. این اغلب در هدایت یک URL به آدرس دیگر استفاده می شود ، البته نه همیشه.

در مورد درخواست های GET ، مرورگر به طور کلی درخواست دوم را بدون هیچ گونه ورودی یا تعامل اضافی از طرف کاربر انجام می دهد. در موارد دیگر ، مداخله کاربر اضافی لازم است.

برای جلوگیری از حلقه های تغییر مسیر بی نهایت ، مرورگرها معمولاً بیش از پنج تغییر مسیر پیاپی از همان درخواست را دنبال نمی کنند..

گزینه های چندگانه HTTP 300

در صورت درخواست چندین گزینه برای منبع ، وضعیت 300 توسط مرورگرها برگردانده می شود. از نظر تئوری ، این می تواند برای ارائه گزینه های مختلف فرمت فایل ، ارائه رسانه های مختلف با همان محتوا یا حتی ابهام کلمه ای باشد..

وضعیت 300 Multiple Choice از پتانسیل زیادی برخوردار است ، اما اغلب مورد استفاده قرار نمی گیرد.

HTTP 301 بطور دائمی منتقل شد

این وضعیت نشان می دهد که منبع به طور دائم URL را تغییر داده است.

موتورهای جستجو بر اساس این کار ، فهرست خود را به روز می کنند ، معمولاً هر رتبه ای را از URL اصلی به URL جدید اختصاص می دهند.

مرورگرها و انواع دیگر مشتریها معمولاً URL جدید را ذخیره می کنند و بطور خودکار URL هدایت شونده را دنبال می کنند بدون اینکه مستقیماً درخواست اصلی را بررسی کنند ، حتی اگر URL اصلی به صورت دستی تهیه شود. نشانک های ذخیره شده نیز به طور معمول به روز می شوند.

به طور کلی ، اگر به دلیل تغییر در نام ساختار ساختار URL ، تغییر مسیر را تنظیم می کنید ، باید از 301 استفاده کنید: تغییر مسیر دائمی.

این موارد را می توان در پرونده .htaccess یا httpd.conf در سرور شما یا اغلب در سیستم مدیریت محتوای شما تنظیم کرد. (به عنوان مثال ، چندین افزونه WordPress برای مدیریت ریدایرکت 301 وجود دارد.)

هنگامی که یک وب سایت مجدداً طراحی شد و ساختار URL تغییر یافت ، تنظیم یک تغییر مسیر 301 برای هر URL از سایت اصلی بسیار مهم است. عدم انجام این کار باعث ایجاد پیوندهای شکسته و بازدیدکنندگان ناامید خواهد شد.

HTTP 302 یافت شد

کد وضعیت 302 معمولاً برای تغییر مسیرهای موقتی استفاده می شود. عمل صنعت با 301 تغییر مسیر متفاوت از مشخصات اصلی است ، و مشخصات برای تحقق عمل صنعت تکامل یافته است.

در ابتدا مشخصات ذکر شده است که یک وضعیت 302 باید باعث شود مرورگر درخواست دوم و یکسان را با URL جدید ایجاد کند. با این حال ، بسیاری از مرورگرهای نسل اول وب ، آن را به گونه‌ای اجرا کردند که درخواستهای POST به صورت درخواست GET دوباره نوشتند.

برای تلاش برای روشن شدن وضعیت ، مشخصات به روز شده HTTP / 1.1 دو کد وضعیت دیگر ، 303 و 307 را اضافه کرد.

قرار بود 302 یافته از رفتار “تغییر به GET” که پیاده سازی شده بود تقلید کند ، در حالی که 307 هدایت موقت قرار بود جایگزین رفتار مورد انتظار 302 اصلی شود.

با این حال ، اکثر سرورها و چارچوبهای وب به سادگی به استفاده از 302 برای سازگاری به عقب با مرورگرهایی که استانداردهای جدیدتر را پیاده سازی نمی کنند ادامه دادند..

مشخصات HTTP بعداً با روش استاندارد تكمیل شد و به مرورگرها اجازه می دهد تا درخواستهای POST را برای درخواستهای GET بازنویسی كنند.

نتیجه همه اینها این است که اگر شما از یک مسیر هدایت مجدد 302 در URL استفاده می کنید که قرار است داده های POST را بپذیرد ، احتمالاً این داده ها در درخواست دوم درج نمی شوند.

به همین دلیل ، در صورتی که سرور بتواند داده های ارسالی را در URL اصلی بپذیرد ، از 302 فقط در URL هایی استفاده می کند که می توانند داده های POST (فرم های وب) را بپذیرند و بعد از پذیرش داده ها از تغییر مسیر برای تحویل صفحه استفاده کنند..

همه اینها ، در عمل ، باعث می شود 303 افزون نباشد.

به طور کلی ، از یک تغییر مسیر 302 استفاده نمی شود

HTTP 303 به موارد دیگر مراجعه کنید

در عمل ، این با وضعیت 302 یکسان است. این بدان معناست که با استفاده از روش GET می توانید پاسخ یا منبع را در URL دیگری پیدا کنید. در صورت دریافت پاسخ به درخواست POST ، مرورگر باید فرض كند كه داده ها دریافت شده اند.

HTTP 304 اصلاح نشده است

مرورگرهای وب می توانند درخواستی را با هدر ارسال كنند كه می پرسد آیا منبع از زمان داده و زمان خاص تغییر یافته است یا خیر. این کار در صورتی انجام می شود که مرورگر قبلاً منبع را بارگیری کرده و آن را ذخیره کرده باشد.

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

اما اگر این منبع تغییر نکرده باشد ، سرور وضعیت 304 Not اصلاح شده را ارسال می کند و منبع را نیز ارسال نمی کند. سپس مرورگر باید نسخه ذخیره شده منبع را ارائه دهد ، زیرا تغییر نکرده است.

HTTP 305 از پروکسی استفاده کنید

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

پروکسی سوئیچ HTTP 306

وضعیت 306 در ابتدا به معنای “درخواست های بعدی باید از پروکسی مشخص شده استفاده کند.” دیگر استفاده نمی شود.

تغییر مسیر موقت HTTP 307

این وضعیت برای تکرار قصد اصلی وضعیت 302 ایجاد شده است (به بالا مراجعه کنید).

وضعیت 307: موقتی تغییر مسیر موقت بدان معنی است که درخواست باید این بار با URL دیگری تکرار شود ، اما در آینده ، در آینده ، هنوز هم درخواست ها باید از URL اصلی استفاده کنند.

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

تغییر مسیر دائمی HTTP 308

درخواست فعلی باید با استفاده از URL دیگر تکرار شود ، و کلیه درخواست های آینده نیز باید به آن URL ارسال شود.

مانند 307 و 302 ، این وضعیت عملکرد مشخص شده در مشخصات اصلی 301 را کپی می کند. با 308 ، اگرچه (مانند 307) درخواست دوم باید با درخواست اصلی یکسان باشد – با استفاده از همان روش و شامل همان داده ها.

HTTP 308 رزومه ناقص

این کد وضعیت ایجاد شده و توسط Google استفاده می شود. این بخشی از پیشنهادهای درخواستهای قابل بازگشت HTTP است و برای از سرگیری درخواستهای PUT یا POST متوقف شده استفاده می شود..

کد وضعیت HTTP 4xx – خطای مشتری

هر کسی می تواند اشتباه کند ، اما فقط یک احمق در خطا پابرجاست.

– مارکوس تولیوس سیسرو

از پنج کلاس کدهای وضعیت HTTP ، فقط دو مورد واقعاً “کد خطا” هستند ، کلاسهای 4xx و 5xx.

سری 4xx خطاهای HTTP در نظر گرفته شده است که به نظر می رسد خطا از مشتری سر می زند – یعنی چیزی در درخواست وجود ندارد.

همراه با وضعیت خطا و سایر اطلاعات مربوط به عنوان ، سرورها اغلب پاسخ کاملی را ارائه می دهند (به جای “منبع” به نام “یک” نامیده می شود ، اما در غیر این صورت همان) که قرار است برای کاربر نمایش داده شود.

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

درخواست بد HTTP 400

این یک پاسخ کلی به یک درخواست با مشکل است. مشکل می تواند نحو نادرست ، قالب بندی نامعتبر یا مسیریابی درخواست فریبنده باشد. سرورها غالباً اطلاعات اضافی راجع به آنچه در درخواست به طور اشتباه انجام شده است ، ارائه می دهند.

HTTP 401 غیرمجاز

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

پرداخت HTTP 402 الزامی است

معمولاً مورد استفاده قرار نمی گیرد ، زیرا مشخصات اطلاعات کافی را برای اجرای فعلی در اختیار شما قرار نمی دهد (نامگذاری شده و برای استفاده های بعدی محفوظ است ، اما مشخصات کامل اتخاذ نشده است).

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

YouTube در صورت دریافت درخواست های بسیار زیاد از یک آدرس IP تنها از این وضعیت استفاده می کند. پاسخ نیاز به CAPTCHA دارد تا تأیید کند کاربر یک انسان است.

HTTP 403 ممنوع

مشابه 401 ، این بدان معنی است که درخواست معتبر است ، اما سرور به آن پاسخ نمی دهد زیرا کاربر اجازه مشاهده منبع را ندارد. بر خلاف خطای 401: غیرمجاز ، تأیید اعتبار هیچ تفاوتی نخواهد کرد.

HTTP 404 یافت نشد

این رایج ترین خطای کلاس 4xx است که ممکن است متداول ترین وضعیت HTTP برای یک کاربر متوسط ​​باشد.

404 در صورت اعتبار بودن درخواست بازگردانده می شود ، اما منبع درخواستی به سادگی در سرور یافت نمی شود.

بیشتر چارچوبهای وب به مدیر وب سایت امکان ایجاد “صفحه 404” را می دهند. این صفحه است که کاربر هنگام بروز یک خطای 404 می بیند.

به طور معمول ، این مسئله کاربر را آگاه می کند ، از ناراحتی عذرخواهی می کند ، و روش های متفاوتی برای یافتن مطالبی که کاربر به دنبالش است ، مانند جستجو.

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

گرچه خطاهای 4xx از نظر فنی “خطاهای مشتری” هستند ، خطای 404 معمولاً نتیجه پیوندهای مرده است – URL هایی که قبلاً دارای محتوا بودند اما اکنون تغییر کرده اند..

به همین دلیل ، تهیه یک صفحه 404 می تواند برای وب سایت ها کمی شرم آور باشد ، زیرا اغلب به معنای عدم ارائه تغییر مسیر صحیح URL است. پیامد این نیست که “شما درخواست خود را بهم ریختید” ، بلکه “چیزهایی را که می خواستید از دست دادیم”.

به همین دلیل ، بسیار سخت است که وب سایت ها 404 صفحه خود را به مکانی برای طنز تبدیل کنند.

HTTP 405 روش مجاز نیست

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

به عنوان مثال ، به URL که داده فرم را دریافت کرده است باید با درخواست POST قابل دسترسی باشد. یک درخواست GET ممکن است منجر به پاسخ 405 شود: روش مجاز نیست. استفاده از PUT روی یک منبع فقط خواندنی نیز ممکن است باعث چنین پاسخی شود.

HTTP 406 قابل قبول نیست

درخواست ها می توانند و با استفاده از انواع MIME نوع محتوای مورد نظر خود را مشخص کنند.

اگر منبع درخواست شده از نوعی باشد که با نوع (های) مندرج در عنوان پذیرش درخواست مطابقت نداشته باشد ، سرور 406 را باز می گرداند: خطای قابل قبول نیست.

HTTP 407 احراز هویت پروکسی مورد نیاز است

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

HTTP 408 درخواست زمان پایان

این خطا هنگامی اتفاق می افتد که سرور در حالی که منتظر درخواست است ، تمام شود.

از مشخصات:

مشتری ظرف زمانی که سرور آماده صبر کردن بود درخواستی ارائه نداد. مشتری ممکن است درخواست را بدون تغییر در هر زمان بعدی تکرار کند.

درگیری HTTP 409

نشان می دهد که درخواست نمی تواند پردازش شود زیرا با خود مغایرت دارد. این ممکن است به عنوان مثال در مورد بروزرسانی های متعدد که باعث ایجاد تعارض با یکدیگر می شوند رخ دهد.

HTTP 410 رفته است

این خطا شبیه به خطای 404 است ، اما در نظر گرفته شده است که نشان می دهد منبع درخواستی عمداً حذف شده است و دیگر در هیچ URL موجود نمی باشد..

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

بیشتر موارد استفاده نیازی به این کار ندارند و معمولاً خطای 404 خطای مناسب تری است.

طول HTTP 411 مورد نیاز است

منبع درخواست شده مستلزم این است که درخواستها طول آنها را مشخص کنند ، و درخواست آن را انجام نداد.

پیش شرط HTTP 412 انجام نشد

درخواست کننده پیش شرط ها یا شرایط مورد نیاز را در عنوان درخواست قرار داد ، و سرور قادر به برآورده کردن یک یا چند مورد از این موارد نیست.

HTTP 413 درخواست کنید که اشخاص خیلی بزرگ باشند

این درخواست بزرگتر از توانایی پردازش سرور است.

HTTP 414 درخواست – URI خیلی طولانی

URI (URL) ارائه شده برای پردازش سرور خیلی طولانی بود.

این اغلب وقتی ایجاد می شود که مقدار نامناسب از داده ها در URL به عنوان رشته پرس و جو در یک درخواست GET منتقل می شوند. راه حل معمول تبدیل درخواست به POST و قرار دادن داده ها به بدنه درخواست است.

نوع رسانه پشتیبانی نشده HTTP 415

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

HTTP 416 دامنه درخواستی رضایت بخش نیست

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

انتظار HTTP 417 انجام نشد

در صورت عدم تحقق انتظارات تعیین شده توسط عنوان انتظار در درخواست ، این وضعیت توسط سرور بازگردانده می شود.

عنوان انتظار معمولاً برای درخواست وضعیت سرور از 100 سرور استفاده می شود.

HTTP 418 من یک قوری هستم

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

پایان نامه تأیید هویت HTTP 419

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

خرابی روش HTTP 420 (چارچوب بهار)

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

HTTP 420 آرامش خود را بهبود ببخشید (توییتر)

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

وضعیت استاندارد تر برای چنین شرایطی 429 است: درخواست های بسیار زیادی.

HTTP 421 درخواست غلط

این وضعیت در HTTP / 2 معرفی شد. هنگامی که درخواست به سرور هدایت می شود ، که در حال حاضر قادر به تولید پاسخ نیست ، استفاده می شود.

HTTP 422 نهاد غیرقابل پردازش

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

HTTP 423 قفل شد

با WedDAV استفاده می شود. این بدان معنی است که منبع درخواست شده قفل شده است.

HTTP 424 وابستگی ناموفق بود

مورد استفاده با WebDav. این درخواست شکست خورد زیرا درخواست قبلی ، که درخواست فعلی به آن وابسته است ، انجام نشد.

ارتقاء HTTP 426 موردنیاز است

مشتری باید مطابق در هدر ارتقاء به پروتکل متفاوتی تغییر کند.

HTTP 428 پیش شرط لازم است

این مورد زمانی استفاده می شود که سرور نیاز به شرط بودن درخواست داشته باشد.

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

طبق مشخصات ، این وضعیت برای جلوگیری از “بروزرسانی از دست رفته” ، درجایی که یک مشتری وضعیت منبع را بدست می آورد ، آن را اصلاح می کند ، و آن را به سرور باز می گرداند ، در حالی که شخص ثالث حالت را روی سرور تغییر داده است. منجر به درگیری

HTTP 429 درخواست های بسیار زیاد

مشتری (معمولاً مطابق با آدرس IP تعریف شده است) در مدت زمان مشخص درخواست های زیادی ارسال کرده است.

HTTP 431 درخواست زمینه های هدر بیش از حد بزرگ

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

زمان ورود HTTP 440 (Microsoft)

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

HTTP 444 بدون پاسخ (Nginx)

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

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

HTTP 449 دوباره امتحان کنید با (Microsoft)

بخشی از استاندارد نیست ، اما توسط مایکروسافت استفاده می شود.

درخواست باید پس از انجام عمل شرح داده شده در پاسخ ، دوباره امتحان شود.

HTTP 450 مسدود شده توسط والدین کنترل والدین (Microsoft)

بخشی از استاندارد نیست ، اما توسط مایکروسافت استفاده می شود.

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

HTTP 451 به دلایل قانونی در دسترس نیست (پیش نویس)

این وضعیت هنوز جزئی از استاندارد نیست ، اما به صورت پیش نویس در دسترس است.

استفاده در نظر گرفته شده برای زمانی است که یک منبع به دلیل سانسور یا دلایل قانونی دیگر امکان تهیه آن وجود ندارد. شماره کد مرجع کتاب Farenheit 451 است.

تغییر مسیر HTTP 451 (Microsoft)

بخشی از استاندارد نیست ، اما توسط مایکروسافت استفاده می شود. در Exchange ActiveSync وجود دارد اگر سرور دیگری کارآمد باشد یا سرور نتواند به صندوق پستی کاربران دسترسی پیدا کند.

HTTP 494 درخواست هدر خیلی بزرگ (Nginx)

بخشی از استاندارد نیست ، اما توسط Nginx مورد استفاده قرار گرفت. اکنون مستهلک شده است.

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

خطای گواهی HTTP 495 (Nginx)

بخشی از استاندارد نیست. در واقع یک وضعیت پاسخگویی مانند گذشته نیست ، اما هنگام رخ دادن خطای گواهی مشتری SSL ، در گزارش های Nginx ظاهر می شود.

HTTP 496 بدون گواهینامه (Nginx)

بخشی از استاندارد نیست. در واقع یک وضعیت پاسخگویی مانند گذشته نیست ، اما هنگامی که مشتری گواهی ارائه نکرده است ، در پرونده های Nginx ظاهر می شود.

HTTP 497 HTTP به HTTPS (Nginx)

بخشی از استاندارد نیست. در واقع یک وضعیت پاسخگویی مانند گذشته نیست ، اما هنگام ارسال درخواستهای HTTP ساده به درگاه HTTPS در پرونده های Nginx ظاهر می شود.

HTTP 498 Token منقضی شده / نامعتبر (Esri)

بازگشت توسط ArcGIS برای سرور. کد 498 نشانه منقضی شده یا غیرقانونی را نشان می دهد.

درخواست بسته مشتری HTTP 499 (Nginx)

بخشی از استاندارد نیست. در واقع یک وضعیت پاسخگویی به عنوان استفاده نشده است ، اما هنگامی که سرور هنوز در حال پردازش درخواست خود است ، در گزارش های Nginx در گزارش های Nginx ظاهر می شود و باعث می شود سرور نتواند کد وضعیت را به عقب برگرداند.

HTTP 499 توکن مورد نیاز (Esri)

بازگشت توسط ArcGIS برای سرور. کد 499 نشان می دهد که یک نشانه لازم است (اگر هیچ نشانه ای ارسال نشده است).

کد وضعیت HTTP 5xx – خطای سرور

من واقعاً شگفت زده می شوم که فکر می کنم ذهن من چقدر ضعیف است و مستعد خطا است.

eneرنه دکارت

همراه با سری 4xx ، کلاس 5xx کدهای وضعیت HTTP کدهای خطایی هستند ، که در صورت اشتباه پیش می رود. کدهای خطای 5xx کدهای خطای سرور هستند ، به این معنی که وقتی مشکل روی سرور است ، نه با مشتری ، بازگردانده می شوند..

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

خطای سرور داخلی HTTP 500

این عمومی ترین خطای سرور است و هنگامی که چیزی نامشخص پیش آمد ، توسط سرورهای وب صادر می شود.

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

هنگامی که یک خطای 500 ایجاد می شود ، مشاهده پرونده های سرور اغلب می تواند به تعیین محل خطا کمک کند. این اغلب می تواند به راحتی خطاهای تایپی در پرونده .htaccess باشد.

HTTP 501 اجرا نشده است

این زمانی برمی گردد که روش درخواست HTTP (مانند PUT یا DELETE) ، روش API در برخی موارد ، هنوز عملی نشده است. این برای API های سرویس وب استفاده می شود. معمولاً دلالت یک خطای 501 این است که روش درخواست برای اجرای آینده برنامه ریزی شده است.

HTTP 502 Bad Gateway

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

سرویس HTTP 503 در دسترس نیست

سرور در حال حاضر در دسترس نیست. به عنوان مثال ، زیرا برای نگهداری بیش از حد بارگیری یا پایین آمده است.

پیامد خطای 503 این است که قطع خام موقتی است.

پایان زمان دروازه HTTP 504

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

HTTP 505 نسخه HTTP پشتیبانی نمی شود

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

HTTP 506 Variant همچنین مذاکره می کند

برای درک خطای 506 ، باید مذاکره با محتوای شفاف را درک کنید.

با مذاکره محتوا ، یک URL واحد می تواند همان منبع یا اطلاعات را در قالب های مختلف ارائه دهد. به عنوان مثال ، ممکن است همان تصویر به صورت JPEG و به عنوان یک GIF رمزگذاری شود.

خطای 506 هنگامی رخ می دهد که این مذاکره در محتوا باعث حلقه شود. به عنوان مثال: منبع درخواست شده A دارای دو تغییر است – B و C. هر دو نوع A دارای یک نوع هستند.

برای بیان آن به زبان فنی ، مشخصات خطای 506 را با این شرح می دهد:

مذاکره محتوای شفاف برای درخواست منجر به یک مرجع دایره ای می شود.

ذخیره سازی کافی HTTP 507 (WebDAV ؛ RFC 4918)

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

حلقه HTTP 508 کشف شد

سرور هنگام تلاش برای خدمت به منبع درخواست شده با یک حلقه نامحدود روبرو شد.

بیش از حد پهنای باند HTTP 509 (Apache)

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

HTTP 510 تمدید نشده است

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

احراز هویت شبکه HTTP 511 لازم است

خطای 511 هنگامی که مشتری برای دستیابی به دسترسی به شبکه نیاز به تأیید اعتبار دارد ، برمی گردد.

این وضعیت برای استفاده در هنگام رهگیری پراکسی های مورد استفاده برای کنترل دسترسی به شبکه در نظر گرفته شده است – یعنی “پورتال های اسیر” که قبل از دسترسی به اینترنت از طریق پورتال WiFi ، نیاز به ورود به سیستم یا توافق نامه شرایط خدمات دارند..

(اگر تاکنون سعی کرده اید در فرودگاه یا هتل آنلاین شوید ، احتمالاً با خطای 511 روبرو شده اید.)

خطای ناشناخته HTTP 520

این کد خطا جزئی از استاندارد HTTP نیست ، اما توسط چندین ارائه دهنده بزرگ زیرساخت های سرور به عنوان سرویس ، از جمله CloudFlare استفاده می شود. این به عنوان یک خطای کلی “گرفتن همه” برای مشکلات ناشناس استفاده می شود که منجر به پر نشدن درخواست می شود.

خطای اتخاذ شبکه HTTP 598 (Microsoft)

این کد خطا جزئی از استاندارد HTTP نیست ، اما توسط پروکسی های HTTP مایکروسافت برای سیگنال دادن زمان خواندن شبکه در پشت پروکسی به مشتری در مقابل پروکسی استفاده می شود..

خطای زمان پایان شبکه اتصال HTTP 599 (Microsoft)

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

منابع

  • IANA: وب سایت اداره اعداد اختصاص داده شده به اینترنت.
  • ثبت کد وضعیت HTTP: صفحه رسمی IANA با پیوندهای مربوط به RFC برای هر کد.

خواندن بیشتر

ما راهنماهای ، آموزش ها و اینفوگرافیک های بیشتری در رابطه با توسعه وب داریم:

  • من می نشینم؟ صفحات وضعیت برای 50 ارائه دهنده میزبان برتر: حتی بهترین سرورها هر از گاهی از بین می روند. در این مقاله لیستی از صفحات وضعیت برای 50 شرکت برتر میزبان ارائه شده است.
  • برنامه نویسی شبکه با پریز های اینترنتی: اگر می خواهید شبکه سخت هسته را یاد بگیرید ، این مقاله برای شروع کار است.
  • لیست نهایی ابزارهای وب مستر A-Z: از کد نویسی گرفته تا هاستینگ تا بازاریابی ، این مقاله همه چیز را دارد.

راهنمای نهایی برای میزبانی وب

راهنمای نهایی ما برای میزبانی وب را بررسی کنید. این کار همه چیزهایی را که باید بدانید برای ایجاد یک انتخاب آگاهانه توضیح می دهد.

راهنمای نهایی برای میزبانی وب
راهنمای نهایی برای میزبانی وب

Jeffrey Wilson Administrator
Sorry! The Author has not filled his profile.
follow me
    Like this post? Please share to your friends:
    Adblock
    detector
    map