نوشته های امین ایمانی

جدا کردن سه رقمی واحد پولی در javascript

امین ایمانی — Fri, 13 Aug 2021 15:00:43 +0430

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

انواع متد های HTTP

امین ایمانی — Sat, 21 Nov 2020 02:38:38 +0330

HTTP Methodshttp methods: {1. Get2. Put3. Patch4. Delete5. Post6. Head7. Options8. Connect9. Trace}methodsCRUDe.g.Post ---> Createعمدتا یک رکورد در لیستی که درمنبعی مشخص است ایجاد میکند.Get ----> Readمعمولا برای دریافت و خواندن اطلاعات استفاده میشه .Put ---> Update/Replaceاین متد برای آپدیت کردن دیتا استفاده میشود.Patch ---> Update/Modifyاین متد نیز برای آپدیت استفاده میشود که تفاوتش با متد قبلی توضیح داده شده .Delete --- >Deleteساده ترین متد برای حذف رکوردی خاص یا همه رکورد ها میباشد.حالا این CRUD که اون بالا نوشتیم چی هست ؟!به مجموعه عملیات ساختن یا ایجاد (Create) . خواندن (Read) . آپدیت یا بروزرسانی یک رکورد (Update) و حذف رکوردی یا رکورد هایی - (Delete) گفته میشه CRUD.نکته : متد های Idempotent متد هایی هستن که اجرای درخواست های از این نوع هر چند مرتبه که انجام بشه نتیجه یکسانی داره. اما متد های غیر Idempotent متد هایی هستند که اجرا اونها به دفعات باعث بوجود آمدن آنومالی و side effect های متعددی خواهد شد.متد POST :این متد برای ساخت یا ایجاد رکوردی جدید در منبع (میتواند DB باشد) استفاده میشودپارامتر های ارسالی از طریق نوار url قابل خواندن نیست .این متد از نوع غیر Idempotent است و اجرای چندباره این نوع درخواست باعث بوجود آمدن رکورد های متعددی از پارامتر های تکراری خواهد بودامنیت دیتای ارسالی در درخواست نسبتا بالاست (به قول بچه های تست نفوذ و امنیت no system is safe ) و بازه انواع درخواست های ارسالی شامل :· رشته ها (داده های متنی)· داده های باینری (آپلود فایل)تمامی دیتاهای ارسالی در بدنه درخواست قرار میگیره .مزایا و معایب متد Post :· امنیت نسبتا بالاتری نسبت به متد Get داره و اطلاعات ارسالی در Address bar مرورگر قال مشاهده نیستن.· سرعت درخواست های post (به مقدار خیلی خیلی کمی) کمتر از درخواست های متد Get هست.· محدودیت کمتری (هم به لحاظ نوع مقادیر ارسالی و هم به لحاظ طول url) نسبت به Get داره.(توی برخی منابع گفته شده که طول محدودی برای url ندارد.)· هرگز در history مرورگر ذخیره نمیشه.· به هیچ وجه قابل cache شدن هم نیست.متد GET :این متد از نوع Idempotent است. و اجرای چند باره این درخواست نتیجه یکسانی خواهد داشت.این متد عمدتا برای خواندن اطلاعات از یک سورس مشخص استفاده میشن و فرمت response به صورت json/xml هست .درخواست های از نوع get بدنه یا body ندارند چرا که عمدتا برای درخواست اطلاعات استفاده میشن.گاهی برای فرمت کردن دیتایی که از قبل json یا xml نیست هم از این متد استفاده میشه.این متد پارامتر های ورودی را با فرمت زیر معمولا ارسال میکندکد زیر query Params پیش فرض سرچ در cms وردپرس میباشد.Front-course.ir/?s=Search-Termرشته هایی که space در میان واژگان دارند از طریق کاراکتر ‘-’ از هم جدا میشوند.پارامتر ها با ? شروع میشوند و هر property میتواند value داشت باشد یا نداشته باشد.(بسته به برنامه نویسی سمت back-end)مقادیر با & از هم جدا میشوند. به عنوان مثال:front-course.ir/?name=Amin&user-age=&user-id=1در کد بالا name و user-id هرکدام دارای مقداری هستند ولی user-age مقداری ندارد.مزایا و معایب :· برای ارسال اطلاعات مهم نظیر پسورد ها یا اطلاعات کارت های بانکی نمیتوان(نباید) از این متد استفاده کرد چون تمام مقادیر ارسالی در هر درخواست در address bar مرورگر قابل مشاهده هستن.· داده ها میتوانند bookmark بشوند (امکان به اشتراک گذاری لینک حاوی این query params وجود دارد )· متد get دارای محدودیت طول میباشد یعنی مقادیر بسیاری را نمیتوان در هر request ارسال کرد (max length = 2048 chars in url).· عموما درخواست های از نوع Get قابل کش شدن هستن و توی لاگ سرور(عمدتا یک سری اسکریپت وجود داره که هزاران رکورد از تمام اتفاقاتی که میوفته (سمت کاربر یا سمت سرور) لاگ میگیرن ) هم ذخیره میشن.· در درخواست های این نوع تنها کاراکتر های ASCII قابل ارسال هستن.متد PUT :این متد از نوع Idempotent است. و اجرای چند باره این درخواست نتیجه یکسانی خواهد داشت.ماهیت این متد در ظاهر برای آپدیت یک رکورد از اطلاعات استفاده میشه ولی در عمل به این صورت هست که اول رکورد مورد نظر را پاک میکنه و (در همان مکان) یک رکورد جدید با استفاده از پارامتر های ارسالی جدید ایجاد میکنه که عملا دیتای ما Replace میشه .حالا اینجا سوال این هست که اگر فیلد هایی که در سرور موجود هست جایگزینی در ارسال درخواست put ما نداشته باشن چه اتفاقی براشون میوفته ؟؟!چون رکورد جاری حذف میشه و بعدش دیتای ما replace میشه فیلد هایی ک جایگزین جدیدی براشون تعریف نشده مقدار null خواهند گرفت. و عملا در صورت عدم درنظر گرفتن همه فیلد ها در درون درخواست مقداری از اطلاعات قبلی ما که نیازی به ویرایش یا آپدیت شدن نداشتن از بین میرن.متد PATCH :این متد هم از نوع Idempotent است و و اجرای چند باره این درخواست نتیجه یکسانی خواهد داشت.این متد هم مکانیزمی مشابه به متد put داره ولی مزیتش نسبت به put این هست که فیلد هایی که مقادیر جایگزین در درخواست ارسالی براشون درنظر گرفته نمیشه . از بین نمیرن.در اصل فقط مقادیری که باید نغییر کنند . تغییر میکنند.مثلا اگر نیاز باشه پسورد یک کاربر عوض بشه اگر از متد put استفاده میکردیم همه اطلاعات کاربری اون شخص اعم از ایمیل و نام کاربری از بین میرفت.ولی در متد Patch فقط پسورد عوض میشه و باقی فیلد ها مقادیرشون دست نخورده باقی میمونن (از بین نمیرن).متد DELETE :این متد برخلاف متد Post از نوع Idempotent است و اجرای چند باره این درخواست نتیجه یکسانی خواهد داشت.ساده ترین روش حذف فایل یا رکوردی خاص از یک منبع مشخص است.ممکن است این request ها body داشته باشند.Response های موفقیت آمیز هم ممکن است body داشته باشد.این نوع درخواست ها در مرورگر cache نمیشوند.عموما وقتی درخواستی موفقیت آمیز ارسال میشه . Response ها با http message های متفاوتی ممکن هست دریافت بشه.برای مثال درخواست زیر میگه فایلی به نام badfile.html رو از سرور حذف کن.DELETE /badFile.htm HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) Host: www.Site.com Accept-Language: en-us Connection: Keep-Aliveو در پاسخ چنین چیزی دریافت میشه:HTTP/1.1 200 OK Date: Mon, 27 Jul 2019 12:28:53 GMT Server: Apache/2.2.14 (Win32) Content-type: text/html Content-length: 30 Connection: Closedکه با توجه به message code 200 که به منزله ok هست میگه که این کار انجام شدو اگر این درخواست body هم داشته باشه به شکل زیر میشه :

url deleted

متد HEAD :همانند متد get عمل میکنه با این تفاوت که فقط head درخواست return میشه که این head شامل یک سری اطلاعات از پارامتر های ارسالی و... است. Body درخواست return نمیشه.در عمل بیشتر برای چک کردن مقدار برگشتی هر Get Request استفاده میشه .متد OPTIONS :این متد عمدتا زمانی استفاده میشه که میخوایم بدونیم چه متد هایی رو وب سرور مد نظرما پشتیبانی میکنهکه میتونیم url خاصی رو بهش بدیم یا اینکه از کاراکتر Astrisk (*) جلوی OPTIONS استفاده کنیم تا ببینیم در کلیت سرور چه متد هایی ساپورت میشه.برای مثال اینجا داریم که :OPTIONS * HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)و درصورت موفقیت آمیز بودن درخواست نتیجه به شکل زیر خواهد بود :HTTP/1.1 200 OK Date: Mon, 27 Jul 2019 12:28:53 GMT Server: Apache/2.2.14 (Win32) Allow: GET,HEAD,POST,OPTIONS,TRACE Content-Type: httpd/unix-directoryاگر به سطر سوم دقت کنید تمام متد های پشتیبانی شده رو برای ما مشخص کرده .متد TRACE :این متد معمولا برای دیباگ کردن و در پروسه Development استفاده میشه.حالا به چه صورت؟؟!به این شکل که وقتی درخواستی از نوعTRACE برای سرور از سمت کلاینت ارسال میشه . سرور برای کلاینت درخواستی که کلاینت فرستاده بود رو مجدد میفرسته تا کلاینت بتونه Content درخواستی که ارسال کرده بوده رو مشاهده کنه.مثال:TRACE / HTTP/1.1 Host: www.Site.com User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)و نتیجه برگشتی درصورت موفقیت آمیز بودن درخواست به شکل زیر خواهد بود.HTTP/1.1 200 OK Date: Mon, 27 Jul 2019 12:28:53 GMT Server: Apache/2.2.14 (Win32) Connection: close Content-Type: message/http Content-Length: 39 TRACE / HTTP/1.1 Host: www.Site.com.com User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)متد CONNECTبا استفاده از این متد میشه یک اتصال یا connection بین کلاینت و وب سرورمون که توی مثال ما Apache هست برقرار کنیم :برای مثال توی درخواست زیر قرار هست که به سرور فرضا یک سایتی درخواست کانکشن بدیمCONNECT www.Site.com HTTP/1.1 User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT) در صوررتی که این درخواست با موفقیت انجام بشه نتیجه Head به شکل زیر خواهد بود. HTTP/1.1 200 Connection established Date: Mon, 27 Jul 2019 12:28:53 GMT Server: Apache/2.2.14 (Win32)

استفاده از استاندارد SRP در React (کامپوننت های تک وظیفه)

امین ایمانی — Fri, 20 Nov 2020 17:32:22 +0330

مفهوم srp به این موضوع دلالت داره که هر کامپوننت باید یک وظیفه رو انجام بده.مثلا داشتن یک کامپوننت که هم یک درخواست میده به Rest Api و هم دیتای برگشتی رو نمایش میده یک آنومالی محسوب میشه.شیوه صحیح این هست که یک کامپوننت درخواست رو بفرسته و دیتا رو بگیره ، و به یک کامپوننت فرزند از طریق Prop یا State Management که میتونه ریداکس یا کانتکست باشه ، پاس داده بشه .توی حالت بالا ۲وظیفه وجود داره و ۲ کامپوننت .نکته بسیار مهم : هر کامپوننت باید تنها ۱ دلیل برای تغییر وضعیت داشته باشهحالا این یعنی چی؟؟؟باز هم مفهوم تک وظیفه ای بودن هر کامپوننت مطرح شده .حالا دلیل این تک وظیفه ای بودن چی هست ؟؟زمانی که شما چندین و چند کامپوننت تک وظیفه ای داشته باشید ، دیباگ کردن پروژه خیلی ساده تر خواهد بود چون طبق مشکل پیش اومده مشخص هست که کدام کامپوننت وظیفه خودش رو به درستی انجام نمیده.مزیت تک وظیفه ای بودن کامپوننت ها این هست که کاملا تحت کنترل ما هستن و تمامی تغییرات توی محیطی کاملا ایزوله اتفاق خواهد افتاد (این تغییرات نباید کامپوننت دیگه ای رو تحت اثیر قرار بده )تک وظیفه ای بودن کامپوننت ها سایز هر کامپوننت رو محدود نگه میداره و باعث تمرکز بیشتر رو کلیت پروژه خواهد شد . علاوه بر این موضوع کامپوننت های تک وظیفه ای فرآیند کد نویسی راحت تری دارن و در آینده برای تغییرات در کد و تست نویسی پیچیدگی چندانی نخواهند داشت.اگر کامپوننتی داریم که بیش از ۱ وظیفه رو انجام میده باید بر اساس و اولویت اجرای کد به بخش های کوچک تری تقسیم بشن.کپسوله سازی کامپوننت ها :یک کامپوننت کپسوله سازی شده از prop ها برای کنترل رفتار خودشون استفاده میکنن و این در حالی هست که ساختار این کامپوننت تحت تاثیر مقادیر دریافت شده prop از کامپوننت والد خودش قرار نمیگیره .Coupling یک سیستم ویژگی کامپوننت هست که درجه یا میزان وابستگی بین کامپوننت هارو مشخص میکنه و ۲ نوع مختلف داره :１. Loose Coupling:حالتی از ارتباط کامپوننت ها باهم هست که کمترین میزان ارتباط وجود داره و کامپوننت ها در حالت ایده آل کاملا مستقل از هم کار میکنن.２. Tight Coupling :در این حالت هر کامپوننت ارتباط های بسیار و تنگاتنگی با کامپونتت های دیگه داره و در این حالت استقلال کامپوننت ها از هم در پایین ترین حد و گاها صفر قرار داره .استاندارد طراحی ساختار کامپوننت ها loose coupling رو ترجیح میده چرا که این مورد توصیف ذاتی واضحی از SRP داره .

کد های وضعیت http

امین ایمانی — Fri, 20 Nov 2020 05:58:53 +0330

۵ کلاس از status code های http وجود داره که هر کلاس ماهیت کلی یک request response رو نشون میده و هرکدام ازین کلاس ها یک رنج تعریف شده از پیام هارو شامل میشن که توی این مقاله موارد خیلی مرسوم تر رو کمی توضیح میدم.Informational responses (100–199)Successful responses (200–299)Redirects (300–399)Client errors (400–499)Server errors (500–599)قبل از این که وارد توضیحات بخش کلاسها بشیم یک موردی هست که توی HEAD تقریبا همه درخواست ها مشاهده میشه و اون هم user-agent هست .user-agent درواقع حاوی اطلاعاتی اعم از نوع و نسخه سیستم عامل و مرورگر شماست که بین سیستم عامل کلاینت و سرور تبادل میشه (به منظور بهینه سازی سرویسی که قرار هست ازش استفاده بشه متناسب با resource های سخت افزاری و نرم افزاری شما)کدهای سری 100، مربوط به اطلاعات (Informational) :این دسته از کد ها از ۱۰۰ شروع میشن و عمدتا برای دریافت اطلاعات مربوط به امکان پذیرش درخواست توسط سرور یا امکان پردازش فرآیند های مربوط به درخواست یا درباره نقل و انتقال packet ها استفاده میشن.مهم ترین کد های وضعیت توی کلاس Information :· ۱۰۰ – ادامه ارسال (Continue) :این کد وضعیت زمانی ارسال میشه درون HEAD درخواست ما یک EXPECT HEADER وجود داشته باشه.حالا که سرور HEAD درخواست ما رو دریافت کرده (درخواست نه رد شده و نه پذیرفته شده)و مایل هست که payload موجود در بدنه درخواست رو هم دریافت کنه تا نتیجه نهایی رو به صورت Response استاندارد ارسال کنه .کلاینت حالا باید کد وضعیت ۱۰۰ رو نادیده بگیره و درخواستش رو ارسال کنه .مثال زیر بیانگر این موضوع هست:PUT /somewhere/fun HTTP/1.1Host: origin.example.comContent-Type: video/h264Content-Length: 1234567890987Expect: 100-continue· ۱۰۱ – تعویض پروتکل (Switching Protocols) :سرور در این وضعیت متوجه میشه که باید به پروتکلی سوییچ کنه که با درخواست کلاینت مطابقت داشته باشه . (با استفاده از header upgrade field)عموما این سوییچ بین پروتکل ها زمانی اتفاق خواهد افتاد که قرار هست از یک نسخه قدیمی تر http به نسخه جدید تر سوییچ بشه .به عبارتی سرور وقتی این کارو میکنه که مزیتی در این سوییچینگ وجود داشته باشه (فقط زمانی که این سوییچینگ دارای مزیت باشه موافقت خواهد کرد) .مثلا :وقتی قرار هست که به یک پروتکل Asynch و Real-Time سوییچ بشه این اتفاق انجام میشه چرا که این روش مزیتی نسبت به حالت فعلی داره .· ۱۰۲ – درحال پردازش (Proccessing ) :این کد وضعیت زمانی ارسال میشه که یک درخواست از سمت کلاینت ارسال میشه و به صورت کامل از سمت سرور دریافت میشه و احتمالا یه زمانی مثلا ۱۰ ثانیه طول میکشه تا پردازش اون تکمیل بشه ولی پردازش و پاسخ هنوز انجام نشده .حالا سرور یک کد ۱۰۲ میفرسته و میگه که دارم پردازشش میکنم کمی صبر کن.به محض تمام شدن مرحله پردازش یک Response حاوی مقادیر استاندارد برگشتی برای کلاینت ارسال خواهد شد.مهم ترین کد های وضعیت توی کلاس Successful responses :· ۲۰۰ – ok (درخواست موفقیت آمیز بود):وقتی درخواست ما با موفقیت به سرور ارسال بشه و سرور با درخواست موافقتش رو اعلام کنه کد ۲۰۰ میفرسته و میگه ok .معمولا این پاسخ به درخواست ما یک payload هم خواهد داشت که بسته به متد مورد استفاده در درخواست موارد مخلتفی رو به ما نمایش خواهد داد .درصورتی استفاده از متد:o Get : اطلاعات ارسالی شامل محتوا و منبع مورد نظر خواهیم گرفت.o Head: نتیجه ای مشابه Get با این تفاوت که این درخواست بدنه نخواهد داشت .o Post : یک موجودیتی که توضیحات یا دیتایی که درباره این عملیات هست رو شامل میشه.· ۲۰۱ – created (ساخته شده ):در این وضعیت سرور اعلام میکنه که درخواست شما دریافت شد و عملیات مورد نظر شما انجام شده و نتیجه در یک یا چند منبع که در حال ایجاد هست قرار هست که ذخیره بشه (معمولا تایم زیادی نباید طول بکشه)معمولا به همراه این درخواست با کد ۲۰۱ یک payload هم به دست کلاینت میرسه که درونش لینک یا لینک هایی مربوط به منبعی که نتیجه درخواستمون اونجا ذخیره شده . قرار گرفته .· ۲۰۲ – Accepted (پذیرفته شده) :در این وضعیت سرور به ما اعلام میکنه که درخواست شما پذیرفته شده ولی پردازش درخواست هنوز به اتمام نرسیده .· ۲۰۳ - Non-authoritative Information (اطلاعات نامعتبر یا اصطلاحا دست دوم)در این وضعیت سرور به ما اطلاع میده که موجودیت اطلاعاتی که برات ارسال کردم ، از طرف خودم نیست.احتمالا یک کپی لوکال یا شخص ثالثی هست . (Proxies)· ۲۰۴ – No Content – (عدم وجود محتوا)در این وضعیت سرور به ما اعلام میکنه که اوکی من برات یک Header و یک کد وضعیت فرستادم و همه چی روبراهه (به لحاظ درخواست سمت کلاینت) ولی محتوا یا payload ندارم که متناسب با درخواستت برات ارسال کنم .· ۲۰۵ – Reset-Content (ریست محتوا)در این وضعیت سرور درخواست مارو اجرا میکنه و به مرورگر/سیستم عامل یا همون user-agent اعلام میکنه که فرمی که سبب ارسال این درخواست شده رو ریست کن تا به حالت اول برگرده و پاسخ دریافت بشه.· ۲۰۶ – Partial-Content (محتوای جزئی یا ناقص)زمانی که درHeader درخواست فیلدی مبنی بر محدوده ی محتوا تعیین بشه سرور برای درخواست مذکور محتوا را با متوجه به محدوده تعریف شده در چند بخش ارسال میکند.مهم ترین کد های وضعیت توی کلاس Redirects :· ۳۰۰ – multiple Choices (انتخاب های چندگانه)این وضعیت مربوط به شرایطی هست که قراره عمل Redirect صورت بگیره.دراین حالت مرورگر/سیستم عامل یا همون user-agent خودمون در تعامل ۲ مرحله ای (عموما) با سرور هست و ادامه و تکمیل فرایند نیاز به انجام عمل دیگه ای در سمت کلاینت هست .نکته : Redirect ها نباید در یک درخواست، بیش از 5 بار تکرار بشنکه در غیر اینصورت در اکثر مرورگر ها فرض بر وجود حلقه یا (loop) شده و ارتباط قطع میشه .· ۳۰۱ – Moved Permanently (به صورت دائمی منتقل شده)این کد وضعیت یکی از مهم ترین آیتم ها در خصوص Seo هست و سرور اعلام میکنه (عمدتا وقتی مشکلی پیش میاد برای سایت) که این سایت به آدرس دیگه ای منتقل شده و در عمل کلاینت رو به آدرس جدید هدایت میکنه .· ۳۰۲ – Found (منبع پیدا شده)این کد وضعیت به این معناست که منبع در دسترس هست اما مرورگر موقتا باید به آدرس دیگه ای رجوع کنه .نکته : فرق این ۳۰۲ با ۳۰۱ در این هست که ۳۰۲ موقتی هست ولی ۳۰۱ میگه برای همیشه این آدرس فعلی (که دیگه در دسترس نخواهد بود) به آدرس جدیدی منتقل شده .· ۳۰۳ – see others (دیدن بقیه موارد)این کد وضعیت بیانگر این هست که پاسخ سرور به درخواست کلاینت در منبع دیگه ای وجود داره و لازم هست که حتما از متد Get برای واکشی کردن دیتا استفاده کنید .· ۳۰۴ – not modified (تغییر داده نشده)این کد زمانی نمایش داده میشه که user-agent درخواست این رو داره که متوجه بشه آیا از آخرین بار تا درخواست کنونی. تغییراتی روی فایل یا منبع فایل ایجاد شده یا خیر.نکته: پاسخ این نوع درخواست هیچ گاه نباید body payload داشته باشه.· ۳۰۵ – use proxy (استفاده از پراکسی یا سرور واسطه)بسیاری از موارد دیده میشه که یک سری منابع برای دسترسی نیاز به دسترسی به سرور واسطه ای دارن و اون سرور واسطه پراکسی هست .البته عمده مرورگر های معروف این وضعیت رو از سیستمشون حذف کردن به دلایل امنیتی.و مدتی بعد هم کلا منسوخ شد .· ۳۰۷ - Temporary Redirect (ریدایرکت موقتی) (برای سئو اهمیت زیادی داره)در این وضعیت کد تمام شرایط مشابه ۳۰۲ هست با این تفاوت که اینجا بدون تایید کاربر اتفاقی نخواهد افتاد.مهم ترین کد های وضعیت توی کلاس Client errors :· ۴۰۰ – Bad request (درخواست اشتباه!)این ارور کد زمانی پیش میاد که سرور نمیتونه متوجه بشه که درخواست ما دقیقا چی هست و خیلی از اوقات این بخاطر مشکل نگارشی هست ، البته گفته شده گاهی افت سرعت یا قطعی اینترنت هم میتونه باعث نمایش این کد خطا بشه.· ۴۰۱ – Unauthorized (احراز هویت نشده)این ارور زمانی رخ میده که دسترسی به یک منبع نیاز به هویت سنجی یا اصطلاحا لاگین شدن و تشخیص هویت کلاینت ، صورت نگرفته باشه.· ۴۰۲ – payment required (پرداخت ضروری است)این ارور کد معمولا زیاد مرسوم نیست ولی خب کاربردش همونطور که از اسمش مشخص هست نشون میده بخش هایی هستن که برای مشاهده یا پاسخ سرور نیازمند پرداخت هزینه هستن مثل حق اشتراک های VIP .اما در کل استفاده ای معمولا ازشون نمیشه.· ۴۰۳ – Forbidden (ممنوعه) مهم برای سئوحتما براتون پیش اومده که به این ارور وقتی دارید از منابع خارجی(خارج از ایران) استفاده میکنید بر بخورید.o وقتی یک سایت بنابر تحریم ها دسترسی ip های کاربران ایرانی رو میبنده این ارور به شما نمایش داده میشه.o دلیل بعدی این هست که عمدتا Directory Browsing توسط مدیران سایت در سرور ها غیر فعال میشه و این امکان وجود نداره حتی برای کاربرانی که لا گین میکنن.o همچنین این ارور میتونه از تنظیم نادرست فایل .htaccess که برای محدودیت گذاری استفاده از منابع سرور استفاده میشه هم باشه.· ۴۰۴ – Not Found (آدرس پیدا نشد!)با این ارور کد سرور به ما اعلام میکنه که آدرسی که دنبالش هستی رو نمیتونم پیدا کنم ، احتمالا وجود ندارهاحتمالا یجایی اشتباه نگارشی وجود داشته (البته ما باید دقیقا به آدرسی که مربوط به منبع مورد نظرمون هست درخواست بدیم حالا هرطوری که نوشته باشه باید همونطور در درخواست بیاد)· ۴۰۵ – method not allowed (متد مورد استفاده مجاز نیست)این حالت زمانی پیش میاد که متد مورد استفاده ما برای درخواست ، در سرور تعریف نشده .وقتی سرور یک Response کد ۴۰۵ برای ما ارسال میکنه یک لیست از همه متد های مجاز برای ماهم ارسال میکنه و میگه که با این متد ها اگر درخواست بدی میتونی با من ارتباط بگیری.· ۴۰۶ – not Acceptable (مجاز نیست)با این کد وضعیت سرور به ما اعلام میکنه که منبع مورد نظر درخواست شما Header رو پذیرا نیست و فقط توان تولید محتوا یا Representation داره· ۴۰۷ - Proxy Authentication Required (احراز هویت پراکسی نیازمند است)این کد وضعیت مشابه ۴۰۱ هست با این تفاوت که کاربر در پراکسی احراز هویت بشه و در درخواست بعدی در Header درخواست ، فیلد Proxy-Authorization رو هم قرار بده .· ۴۰۸ – Request Timeout (درخواست منقضی شده)با این کد وضعیت به ما اعلام میشه که درخواست کاربر از مدت زمان معین سرور بیشتر طول کشیده و همین درخواست اگر مجدد ارسال بشه و در مدت زمان مناسب انجام بشه· ۴۰۹ – Conflict (تداخل)این کد وضعیت بیانگر این هست که بنا به دلایل مختلف این درخواست (احتمالا با درخواست دیگه ای)به تداخل خورده و فقط زمانی این کد به کاربر ارسال میشه که سرور تشخیص بده کلاینت میتونه این تداخل رو برطرف کرده و مجدد درخواستش رو submit کنه .· ۴۱۰ – Gone (از دست رفته یا منبع وجود ندارد)این کد زمانی پیش میاد که منبع مورد نظر درخواست ما وجود نداشته باشه و سرور امکان این رو نداشته باشه که چک کنه ببینه آیا این وضعیت دائمی هست یا موقتی .· ۴۱۱ – Length Required (طول بدنه درخواست الزامی است)این ارور کد زمانی رخ میده که سرور درخواستی رو که طول محتوای تعریف شده ای در Header نداره رو پس میزنه.کلاینت میتونه با تعریف فیلد طول محتوا در Head مجدد درخواستش رو ارسال کنه .· ۴۱۲ – Precondition Failed (پیش شرط ها رد شده)وقتی سرور شروع به چک کردن شرط ها میکنه ، اگر در Header درخواست کلاینت یک یا چند مورد از شرط ها نقض یا رد شده باشه ، این کد وضعیت نمایش داده میشه .· ۴۱۳ – Payload too large (محتوای بارگزاری بسیار حجیم است)این کد خطا مربوط به این هست که محتوای درخواست ما از چیزی که سرور انتظار داره یا توان پردازش اون رو داره بسیار بیشتر هست .در این حالت معمولا سرور اتصال رو قطع میکنه تا از ادامه ارسال درخواست جلوگیری کنه .· ۴۱۴ – Request-URI too large (نام منبع مورد نظر بسیار طولانی یا حجیم است)سرور زمانی که از سرویس دادن به درخواست به دلیل طولانی بودن نام یا آدرس درخواست ممانعت کنه این ارور کد رو نمایش میده .که عمدتا این ارور کد زمانی رخ میده که کلاینت بخواد یک درخواست با متد Post رو به درخواستی با متد Get تبدیل کنه و همونطور که میدونیم درخواست های متد post میتونن طول بیشتری نسبت به درخواست های متد get داشته باشن .· ۴۱۵ – unsupported media type (عدم پشتیبانی از فایل چند رسانه ای خاصی)این ارور زمانی رخ میده سرور از محتوای نوعpayload در خواست ایراد میگیره و میگه این نوع فایل چند رسانه ای که داری برای من با درخواستت ارسال میکنی با متدی که استفاده کردی پشتیبانی نمیشه و متاسفانه مجبورم با درخواستت مخالفت کنم.معمولا علت این ارور مربوط عدم تطابق Content-Type یا Content-Encoding هست .· ۴۱۶ – Requested Range not Satisfiable (عدم تطابق بازه درخواست )این ارور مربوط به زمانی هست کلاینت درخواست دسترسی به بخشی از منبعی رو داره و اون بخش حذف شده .· ۴۱۷ – Expectation failed (شرط های مورد انتظار رد شده)هر درخواست در Head خودش دارای یک سری فیلد ضروری هست . درصورتی که سرور نتونه این فیلد های ضروری رو بخونه و مطابقت بده این ارور کد رو نمایش میده .· ۴۲۰ – Enhance your Calm (توییتر)این کد زمانی نمایش داده میشه که داریم با api توییتر کار میکنیم و کاربر امتیاز محدودی داشته باشه .· ۴۲۲ – unprocessable entity (موجودیت غیر قابل پردازش)ممکنه شرایطی پیش بیاد که سرور درخواست رو میپذیره و مشکلی هم در سینتکس درخواست وجود نداره ، اما مشکلاتی از قبیل خطاهای منطقی و ... وجود دارهدر این شرایط سرور از پاسخ مقتضی به کلاینت امتناع میکنه .· ۴۲۳ – locked (قفل شده)نشان دهنده ی این هست که منبع یا منابعی که درخواست به اون ارسال میشه قفل هست و پاسخ سرور باید شامل یک پیش شرط مناسب مثل 'lock-token-submitted' یا 'no-conflicting-lock' باشه.· ۴۲۴ – Failed Dependency (درخواست پیشین رد شده)زمانی که درخواستی وابسته به درخواست قبلی باشه و این درخواست قبلی ما به هر دلیلی انجام نشده باشه ارور ۴۲۴ نمایش داده خواهد شد .· ۴۲۶ – upgrade required (نیازمند ارتقا)در این حالت سرور از پذیرفتن درخواست ما ممانعت میکنه و اعلام میکنه درخواست شما قابل انجام هست فقط در صورتی که از پروتکل دیگه ای استفاده کنید .· ۴۲۸ – Precondition required (نیازمند پیش شرط)این کد بیانگر این هست که درخواست کلاینت باید درخواست شرطی باشه و بیشتر برای جلوگیری از تداخل و تغییر وضعیت در سرور استفاده میشه .· ۴۲۹ – too many requests (درخواست های بیش از حد مجاز)زمانی که تعداد درخواست های کلاینت در یک بازه زمانی مشخص از حد مجاز بیشتر میشه این ارور کد نمایش داده میشه (Rate Limiting)· ۴۳۱ – request header field too large (فیلد های درخواست در هدر حجیم است)سرور مایل به دریافت فیلد های حجیم درون درخواست Header نیست و با این ارور کد مخالفت خودش با درخواست رو اعلام میکنه .احتمال داره که بعد از کاهش حجم فیلد های درخواست در Head و با تلاش مجدد کلاینت درخواست مورد پذیرش واقع بشه .· ۴۴۴ – connection closed without response (اتصال بدون دریافت پاسخ قطع شد)ارور کد ۴۴۴ غیر استاندارد و غیر رسمی بوده و برای ارسال اعلان قطع ارتباط (بدون ارسال پاسخ )به وب سرور nginx ، به منظور جلوگیری از درخواست های مخرب و آلوده استفاده میشه.· ۴۵۱ – unavailable for legal reasons (دور از دسترس به دلایل قانونی)این ارور کد زمانی نمایش داده میشه که سرور به دلایل قانونی از سرویس دهی به درخواستی ممانعت میکنه .در بدنه این نوع پاسخ ها توضیحاتی وجود دار دال بر علت عدم سرویس دهی سرور به درخواست کلاینت.· ۴۹۹ – client closed request (قطع ارتباط از طرف کلاینت)ارور کدی غیر استاندارد که از طرف nginx معرفی شده و زمانی رخ میده که کاربر حین انجام درخواست ارتباطش با سرور رو قطع میکنه .مهم ترین کد های وضعیت توی کلاس Server errors :· ۵۰۰ – Internal Server Error (خطای داخلی سرور)این کد وضعیت در قالب پیام خطا زمانی رخ میده که تنظیمات مربوط به سرور مشکلی داشته باشن. یا زمانی که قرار هست آپدیت یا بروزرسانی انجام بدیم میتونیم از این کد استفاده کنیم .البته تجربه شخصی من درباره این ارور زمانی پیش اومد که از یک اسکریپت نا معتبر و به ظاهر کار راه انداز توی پروژم استفاده کردم و وقتی قرار بود یه سری دیتا Post کنم سمت سرور این ارور رو میداد که بعد از کلی ارتباط با هاستینگ و تیکت و غر زدن سر کارشناسان اونا متوجه شدم مشکل از این اسکریپت بوده و وقتی اون اسکریپت رو حذف کردم همه چی به حالت نرمال برگشت.(پ .ن : هر ماژولی رو توی پروژه نباید ایمپورت کرد)· ۵۰۱ – Not Implemented (تکمیل نشده یا تجهیز نشده)این کد وضعیت یا بهتره بگم خطا زمانی رخ میده که سرور در اون لحظه به دلایل مختلف توان انجام و پردازش درخواست مارو نداشته باشه .که دلایل رخ دادن این اتفاق میتونه این باشه که متدی که کلاینت داره استفاده میکنه برای ارسال درخواست در سرور پشتیبانی نمیشه .یا درخواست ما به صورت ناقص داره ارسال میشه و احتمالا یکی یا چند تا از پارامتر هایی که اصولا باید در Head درخواست ما وجود داشته باشه نیست.· ۵۰۲ – Bad Gatewayاین کد مربوط به این هست که سرور بالا دستی (نه سروری که داریم بهش درخواست میدیم) پاسخی به درخواست ما نداده(به دلایل مختلف).اینجا سروری که ما بهش درخواست میدیم به عنوان یک Gateway در نظر گرفته میشه .گاهی این خطا پیش میاد که فرآیند درخواست و پاسخ بین کلاینت و سرور اصلی از طریق Gateway برقرار نمیشه.که گفته شده این خطا موقتی هست و بعد از چند بار تلاش کاربر این مورد حل میشه.· ۵۰۳ – Service Unavailable (سرویس در دسترس نیست)این خطا معمولا زمانی پیش میاد که ترافیک سمت سرور زیاد هست یا بروزرسانی سمت سرور داره رخ میده .همین موضوعات باعث میشه که موقتا سایت از دسترس خارج بشه و عموما بعد از چند دقیقه یا چند ساعت مشکل برطرف میشه .برای یه پروژه ای که فکرشم نمیکردم اینقدر درخواست داشته باشه از هاست اشتراکی استفاده کردم و بازدید سایت (درخواست های سمت کلاینت) در روز از یه حدی که بیشتر میشد کلا سایت از دسترس خارج میشد .· ۵۰۴ – Gateway Timeoutاین خطا زمانی پیش میاد که سمت کلاینت یک درخواست به سمت سروری که نقش Gateway رو داره ارسال میکنه ( فرآیند ارسال و دریافت یک بازه زمانی محدود داره) و در بازه زمانی معتبر فرایند انجام نمیشه.· ۵۰۵ – Http Version not Supported (نسخه http پشتیبانی نمیشود)وقتی نسخه درخواست http ما توسط سرور پشتیبانی نشه به چنین اروری برمیخوریم که سرور در پاسخ گاهی دلیل پشتیبانی نکردنش رو هم توضیح میده .منابعw3MDNwebgoo.irhttpstatusestools.ietf