مفت HTTP اسٹیٹس کوڈز کا حوالہ

Expect: 100-continue والی درخواستوں کے لیے استعمال ہوتا ہے۔ سرور تسلیم کرتا ہے کہ وہ کلائنٹ جسم بھیجنے سے پہلے وصول کرنے کے لیے تیار ہے۔ جدید ویب ایپس میں شاذ و نادر دیکھا جاتا ہے۔

عام طور پر WebSocket اپ گریڈز کے لیے استعمال ہوتا ہے — کلائنٹ Upgrade: websocket کی درخواست کرتا ہے اور سرور سوئچ کرنے کے لیے 101 کے ساتھ جواب دیتا ہے۔

WebDAV درمیانی جواب لمبی کارروائیوں کے دوران کلائنٹ ٹائم آؤٹ روکنے کے لیے بھیجا جاتا ہے۔ متروک — جدید سرورز اسے نہیں بھیجنے چاہیں۔

سرورز کو جبکہ حتمی جواب ابھی تیاری میں ہے Link ہیڈرز (preload/preconnect) بھیجنے دیتا ہے، تاکہ براؤزرز اہم اثاثوں کو جلد فیچ کرنا شروع کر سکیں۔

معیاری کامیاب جواب۔ معنی HTTP طریقہ پر منحصر ہے: GET → وسیلہ واپس کیا گیا، POST/PUT → کارروائی مکمل۔

عام طور پر POST کے بعد۔ جواب میں ایک Location ہیڈر شامل ہونا چاہیے جو نئے وسیلہ کے URL کی طرف اشارہ کرے۔

async کارروائیوں کے لیے — سرور کام قطار میں ڈال رہا ہے۔ کلائنٹ کو ایک status endpoint پول کرنا چاہیے یا بعد میں واپس چیک کرنا چاہیے۔

درخواست کامیاب رہی، لیکن درمیانہ (جیسے کیشنگ یا تبدیل کرنے والا پروکسی) نے اصل سرور سے payload میں تبدیلی کی — مثال کے طور پر، تصویروں کو دوبارہ کمپریس کرنا۔ عملی طور پر شاذ و نادر۔

اکثر DELETE کارروائیوں یا PUT اپڈیٹس کے لیے استعمال ہوتا ہے جن کو body واپس کرنے کی ضرورت نہیں ہے۔ کلائنٹ موجودہ صفحہ سے نہیں جانا چاہیے۔

204 کی طرح، کوئی body واپس نہیں کیا جاتا — لیکن کلائنٹ کو اضافی طور پر فارم یا منظر کو ری سیٹ کرنے کو کہا جاتا ہے جس نے درخواست پیدا کی (مثال کے طور پر اگلی entry کے لیے فارم فیلڈز صاف کریں)۔

Range درخواست کا جواب۔ ویڈیو پلیئرز اور ڈاؤن لوڈ مینیجرز کے ذریعے منقطع ڈاؤن لوڈ دوبارہ شروع کرنے یا بڑی فائلوں کو سٹریم کرنے کے لیے استعمال ہوتا ہے۔

WebDAV: ایک XML body کئی sub-operations کے نتائج کو الگ الگ رپورٹ کرتا ہے — مثال کے طور پر batch move جہاں کچھ items کامیاب ہوں اور دوسری ناکام۔

WebDAV: 207 Multi-Status جوابات کے اندر استعمال ہوتا ہے تاکہ وہی collection کے members کو بار بار درج نہ کرنا پڑے جب bindings loops بناتی ہوں۔

Delta encoding: سرور مکمل وسیلہ کی بجائے پچھلے ورژن کے خلاف diff واپس کرتا ہے، بینڈ وڈتھ بچاتا ہے۔ بہت کم لاگو کیا جاتا ہے۔

سرور متعدد خیارات پیش کرتا ہے (مثال کے طور پر مختلف شکلیں یا زبانیں) اور کلائنٹ کو ایک منتخب کرنا چاہیے۔ شاذ و نادر استعمال ہوتا ہے، کیونکہ خودکار content negotiation عام طور پر اس کو سنبھالتا ہے۔

مستقل URL تبدیلیوں کے لیے استعمال کریں — سرچ انجنز اپنے index کو اپڈیٹ کریں گے۔ SEO authority نئے URL کو منتقل کرتا ہے۔

یہ ظاہر کرتا ہے کہ redirect مستقل نہیں ہے۔ 301 سے کیشنگ کم جارحانہ ہے۔ چیزوں کے لیے استعمال کریں جیسے 'login درکار ہے، /login کو redirect کیا جا رہا ہے'۔

POST submissions کے بعد استعمال ہوتا ہے — جواب کہتا ہے 'آپ کا POST کام کر گیا، نتیجہ کے لیے یہ GET URL دیکھیں'۔ براؤزرز ہمیشہ نئے URL کو GET کرتے ہیں۔

شرطی درخواست کا جواب (If-None-Match یا If-Modified-Since ہیڈرز کے ساتھ)۔ بینڈ وڈتھ بچاتا ہے — کوئی body واپس نہیں کیا جاتا۔

اگر original POST تھا، تو redirect بھی POST استعمال کرتا ہے۔ جدید متبادل 302 جب method conservation اہم ہو۔

301 کا جدید متبادل جب آپ POST درخواستوں کو redirect کے بعد POST رہنا چاہتے ہوں۔

عام وجوہات: body میں malformed JSON، غلط query parameters، یا missing required fields۔ درخواست body اور ہیڈرز چیک کریں۔

کلائنٹ کو authentication credentials (Authorization ہیڈر، cookie، token) شامل کرنا چاہیے۔ 'Unauthorized' غلط نام ہے — اس کا مطلب واقعی 'unauthenticated' ہے۔

اصل میں ڈیجیٹل payments کے لیے ارادہ۔ جدید استعمال: APIs بعض اوقات 402 واپس کرتے ہیں جب صارف اپنا paid quota exceed کر دے۔

401 سے مختلف — صارف لاگ ان ہے، لیکن ان کے اکاؤنٹ کو اس وسیلہ کی اجازت نہیں ہے۔ role/permissions logic چیک کریں۔

یا تو URL غلط ہے، وسیلہ حذف کیا گیا، یا یہ کبھی موجود ہی نہیں تھا۔ سرورز کبھی کبھی 404 واپس کرتے ہیں تاکہ 403 زیادہ درست ہو۔

مثال کے طور پر، ایک endpoint کو GET درخواست جو صرف POST قبول کرتا ہے۔ جواب میں ایک Allow ہیڈر ہونا چاہیے جو درست طریقے درج کرے۔

کلائنٹ نے ایک content type، زبان، یا encoding (Accept، Accept-Language، Accept-Encoding کے ذریعے) کے لیے پوچھا جو سرور پورا نہیں کر سکتا۔ بہت سے سرورز سخت negotiation چھوڑتے ہیں اور default واپس کرتے ہیں۔

401 جیسے، لیکن ایک proxy کے ذریعے جاری: کلائنٹ کو Proxy-Authorization credentials بھیجنا چاہیے۔ corporate networks میں دیکھا جاتا ہے authenticating proxies کے ساتھ۔

کلائنٹ کو درخواست بھیجنے میں بہت زیادہ وقت لگا یا اتصال خالی رہا۔ درخواست دوبارہ کوشش کریں۔

عام طور پر بیک وقت ترمیم کے تنازعات یا ڈپلیکیٹ وسائل کی تخلیق کے لیے واپس کیا جاتا ہے (مثال کے طور پر، ایسی ای میل کے ساتھ صارف بنانا جو پہلے سے موجود ہے)۔

404 سے زیادہ سخت — سرور واضح طور پر جانتا ہے کہ وسیلہ پہلے موجود تھا لیکن مستقل طور پر ہٹا دیا گیا ہے۔ سرچ انجن ہٹا دیں گے۔

درخواست مسترد کر دی گئی کیونکہ اس میں Content-Length سربراہ نہیں تھا اور سرور نامعلوم سائز کی جسمیں مسترد کرتا ہے۔ سربراہ شامل کریں اور دوبارہ کوشش کریں۔

شرطی سربراہین جیسے If-Match یا If-Unmodified-Since ناکام ہونے پر واپس کیا جاتا ہے — عام طور پر متفائل لاکنگ: کسی اور نے آپ کے ورژن کے بعد سے وسیلہ بدل دیا۔ دوبارہ لائیں اور دوبارہ کوشش کریں۔

بڑی فائلوں اپ لوڈ کرتے وقت عام۔ سرور کنفیگریشن (nginx، apache) زیادہ سے زیادہ جسم کا سائز متعین کرتا ہے۔ سرور کی تشکیل چیک کریں۔

عام طور پر بہت لمبی کویری سٹرنگز کی وجہ سے (مثال کے طور پر GET میں ڈیٹا کو انکوڈ کرنا)۔ POST جسم میں سوئچ کریں، یا اگر آپ اس پر کنٹرول کرتے ہیں تو سرور کی حد بڑھائیں۔

مثال کے طور پر، ایسے سرور میں application/xml بھیجنا جو صرف application/json قبول کرتا ہے۔ Content-Type سربراہ کو صحیح طریقے سے سیٹ کریں۔

Range سربراہ فائل میں ایسے حصے کے لیے پوچھتا ہے جو موجود نہیں ہے — مثال کے طور پر ڈاؤن لوڈ کو فائل کے آخر سے آگے دوبارہ شروع کرنا۔ جواب میں Content-Range شامل ہونا چاہیے جس میں اصل سائز ہو۔

جب سرور Expect: 100-continue کو سپورٹ نہیں کرتا ہے۔ کچھ کلائنٹس بڑے POSTs پر بطور ڈیفالٹ یہ سربراہ بھیجتے ہیں؛ اسے غیر فعال کرنا عام طور پر خرابی کو حل کرتا ہے۔

1998 سے اپریل کے مذاق (RFC 2324)۔ کچھ حقیقی APIs اسے مذاق کے لیے یا متروک endpoints کو نشان زد کرنے کے لیے استعمال کرتے ہیں۔ پروڈکشن استعمال کے لیے نہیں۔

HTTP/2 کنکشن دوبارہ استعمال کے ساتھ عام: درخواست اس سرور تک پہنچی جو ہدف hostname کے لیے تشکیل شدہ نہیں ہے۔ کلائنٹ کو نیا کنکشن پر دوبارہ کوشش کرنی چاہیے۔

مثال کے طور پر، JSON صحیح طریقے سے پارس ہوا لیکن ضروری فیلڈ غائب تھا، یا فیلڈ کی قیمت رینج سے باہر تھی۔ REST API تصدیق جوابات میں عام۔

WebDAV: ذریعہ یا منزل کا وسیلہ کسی اور کلائنٹ کے ذریعے لاک ہے، اس لیے آپریشن جاری نہیں رہ سکتا۔ لاک جاری ہونے کا انتظار کریں یا صحیح ٹوکن کے ساتھ اسے توڑیں۔

WebDAV: منحصر آپریشنز کی زنجیر میں، ایک پہلی کارروائی ناکام ہوئی، اس لیے یہ نہیں کی گئی۔ پہلی ناکامی کو دیکھیں۔

TLS 1.3 0-RTT (ابتدائی ڈیٹا) سے متعلق: سرور شدہ درخواست کو پروسیس کرنے کا خطرہ نہیں اٹھائے گا۔ کلائنٹ کو ہینڈشیک مکمل ہونے کے بعد دوبارہ کوشش کرنی چاہیے۔

سرور موجودہ پروٹوکول پر درخواست کو پورا کرنے سے انکار کرتا ہے لیکن اپ گریڈ کے بعد — جواب میں ضروری پروٹوکول کا نام دیتے ہوئے Upgrade سربراہ شامل ہے۔

سرور شرطی سربراہین (جیسے If-Match) کا مطالبہ کرتا ہے تاکہ اپڈیٹ میں نقصان سے بچا جا سکے۔ وسیلہ حاصل کریں، اس کا ETag کیپچر کریں، اور If-Match کے ساتھ دوبارہ بھیجیں۔

سست ہو جائیں۔ جواب میں Retry-After سربراہ شامل ہونا چاہیے جو دوبارہ کوشش کرنے کا وقت بتائے۔ درخواست کوٹا والے APIs کے ساتھ عام۔

یا تو ایک سربراہ یا کل سربراہ سائز حد سے تجاوز کرتا ہے — زیادہ تر بڑی کوکیز کی وجہ سے۔ کوکیز صاف کریں یا اپنی ایپ ان میں محفوظ کریں۔

وسیلہ قانونی وجوہات کی بنا پر بلاک ہے — سنسرشپ، عدالتی احکام، یا علاقائی ضوابط۔ یہ نمبر ناول Fahrenheit 451 کی طرف اشارہ ہے۔

سرور کی طرف کی خرابیوں کے لیے عام catch-all۔ اصل وجہ کے لیے سرور کے لاگز چیک کریں: ہینڈل شدہ استثنیٰ، ڈیٹا بیس کی خرابی، وغیرہ۔

مثال کے طور پر، سرور HTTP method کو نہیں پہچانتا۔ عملی میں نایاب — زیادہ سے زیادہ آپ 405 دیکھیں گے۔

مائیکروسرویس آرکیٹیکچرز میں عام۔ آپ کے load balancer یا reverse proxy کو backend سروس سے غلط جواب ملا۔

یا تو maintenance کے لیے بند ہے یا overloaded۔ جواب میں Retry-After سربراہ شامل ہونا چاہیے۔ deployments کے دوران اکثر واپس کیا جاتا ہے۔

Backend سروس کافی جلدی جواب نہیں دیا۔ upstream سروس کی صحت اور timeout تشکیلات چیک کریں۔

درخواست کا اہم HTTP ورژن سرور کے ذریعے سپورٹ نہیں کیا جاتا ہے۔ جدید کلائنٹس کے ساتھ تقریباً کبھی نہیں دیکھا جاتا۔

شفاف content negotiation loop میں ختم ہوا: منتخب variant خود negotiation کے لیے تشکیل شدہ ہے۔ سرور کی تشکیل میں خرابی ظاہر کرتا ہے۔

WebDAV-specific اصل میں لیکن کبھی کبھی عام سرورز کے ذریعے استعمال کیا جاتا ہے۔ اس کا مطلب ہے سرور اسٹوریج کی پابندیوں کی وجہ سے درخواست کو محفوظ نہیں کر سکتا۔

WebDAV: Depth: infinity درخواست پروسیس کرتے ہوئے loop میں داخل ہوا (مثال کے طور پر سرکلر bindings)۔ آپریشن ختم کر دیا گیا۔

متروک HTTP Extension Framework سے: سرور کو درخواست کو پورا کرنے سے پہلے مزید معلومات کی ضرورت ہے۔ جدید ویب پر مؤثر طور پر استعمال نہیں کیا جاتا۔

captive portals (ہوٹل/ایئرپورٹ WiFi) کے ذریعے استعمال کیا جاتا ہے تاکہ اشارہ کریں کہ صارف بیرونی سائٹس تک رسائی سے پہلے نیٹ ورک میں لاگ ان کرے۔