AJAX فارم JSON کی توقع کرتا ہے مگر HTML موصول ہوتا ہے: جواب کا مرحلہ وار جائزہ لیں
200 کا جواب اس بات کا ثبوت نہیں کہ وہ JSON ہے۔ نیٹ ورک پینل کا مرحلہ وار جائزہ لیں اور منتقلی، نمائندگی اور معاہدے کی ناکامیاں الگ کریں۔
فارم جمع ہوتا ہے، گھومنے والا نشان ظاہر ہوتا ہے، اور کنسول کہتا ہے کہ JSON میں مقام 0 پر غیر متوقع < علامت ہے۔ صفحہ بذات خود ٹھیک لوڈ ہوتا ہے، اسی لیے پہلا خیال تجزیہ کار یا سرنگ کو مورد الزام ٹھہرانا ہوتا ہے۔ عام طور پر دونوں میں سے کوئی ملوث نہیں ہوتا: بھیجنا صفحہ لوڈ ہونے سے مختلف درخواست ہے، اور یہ ایسی چیز کے ساتھ واپس آیا جو JSON نہیں۔ اسی ترتیب سے کام کریں جس میں براؤزر واقعی اسے بے نقاب کرتا ہے، کیونکہ چار ممکنہ جوابات کے لیے چار مختلف اصلاحات درکار ہیں۔
مرحلہ 1: وہ بھیجنا پکڑیں جو واقعی ہوا
بھیجنے سے پہلے نیٹ ورک پینل کھولیں، لاگ کو ترتیب دیں کہ نیویگیشن کے دوران اندراجات محفوظ رہیں، پھر اس اکاؤنٹ پر ایک بے ضرر تجرباتی بھیجنا کریں جسے استعمال کرنے کی اجازت ہے۔ وہ درخواست منتخب کریں جو فارم نے خود شروع کی، نہ کہ صفحے کی دستاویز کی درخواست۔
فلٹرز سے محتاط رہیں۔ XHR یا Fetch فلٹر آسان ہے، لیکن اگر فریم ورک اب بھی چھپے ہوئے iframe یا متحرک طور پر بنائے گئے فارم سے بھیجتا ہے، تو فلٹر واحد اہم درخواست چھپا دے گا۔ پہلے ایک بار بغیر فلٹر بھیجیں اور دیکھیں کیا آیا۔
منتخب درخواست کے لیے کسی بھی تشریح سے پہلے چھ چیزیں لکھیں: طریقہ، کوئری اسٹرنگ سمیت مکمل URL، حیثیت، ری ڈائریکٹ کا سلسلہ، جواب کا Content-Type، اور باڈی کی پہلی سطریں۔ Chrome DevTools کا نیٹ ورک پینل حوالہ ان Headers، Response اور Initiator مناظر کا احاطہ کرتا ہے جہاں یہ ہوتے ہیں، اور دیگر براؤزرز کے مساوی پینل بھی وہی فیلڈز دکھاتے ہیں۔
مرحلہ 2: تصدیق کریں کہ یہی وہ درخواست ہے جو آپ سوچتے ہیں
حیرت انگیز طور پر بہت سی JSON غلطیاں دراصل روٹنگ کی غلطیاں ہیں۔ اگر جمع کرنے کا ہینڈلر preventDefault بلانے سے پہلے استثنا پھینکے، تو براؤزر action خصوصیت میں لکھے پتے پر مقامی فارم POST کرتا ہے، اور سرور مکمل HTML صفحے کے ساتھ جواب دیتا ہے۔ ہینڈلر کبھی نہیں چلتا، اس لیے JSON کبھی طلب نہیں ہوا۔
پینل کے URL کا موازنہ اس URL سے کریں جو آپ کا JavaScript بلاتا ہے۔ کہیں اور ختم ہونے والا ری ڈائریکٹ، غائب یا زائد آخری سلیش، طریقے کی عدم مطابقت، یا منتقل شدہ صفحے سے نسبتی راستے پر بھیجنے والا فارم تلاش کریں۔ ری ڈائریکٹ کے سلسلے کو آخر تک Follow کریں اور پہلا نہیں بلکہ آخری URL نوٹ کریں۔
پھر شروع کرنے والے کی جانچ کریں۔ اگر درخواست آپ کی اسکرپٹ کے بجائے دستاویز کی نیویگیشن سے آئی ہے، تو آپ مسئلہ پا چکے ہیں، اور جواب کے تجزیہ کار میں کوئی تبدیلی مدد نہیں کرے گی۔
مرحلہ 3: نتیجے کو چار اقسام میں تقسیم کریں
ہر نتیجہ ان میں سے ٹھیک ایک میں آتا ہے، اور قسم طے کرتی ہے کہ آگے کہاں دیکھنا ہے۔
| What you see | Category | Where to look |
|---|---|---|
| Request never finishes, TLS or connection error | No usable response | Endpoint reachability, certificate, front-end timeout |
| Request completes, script gets an opaque failure | Access blocked | Cross-origin policy, credentials mode, missing response header |
| 200 with an HTML body or a login form | Wrong representation | Redirect, expired session, route fallback, error handler |
| Body begins with a notice then valid JSON | Wrong representation | Server-side warning output before serialisation |
| Valid JSON, framework rejects it | Contract mismatch | Envelope shape, field names, value types |
درمیانی سطریں وہ ہیں جن کی لوگ غلط تشخیص کرتے ہیں، کیونکہ حیثیت 200 ہے۔ ری ڈائریکٹ کے بعد پہنچنے والا سائن ان صفحہ بالکل اچھا HTTP جواب اور بہت برا JSON دستاویز ہے۔ application/json مواد کی قسم اسے ٹھیک نہیں کرتی: یہ صرف لیبل ہے، اور غلط لیبل والی باڈی پھر بھی تجزیہ نہیں ہو سکتی۔ رسائی مسدود وہ سطر ہے جو مکمل درخواست جیسی لگتی ہے: پینل حیثیت دکھاتا ہے، لیکن کراس اوریجن پالیسی باڈی روک لیتی ہے، اس لیے بلانے والی اسکرپٹ کے لیے یہ وقت ختم ہونے جتنی ہی بیکار ہے۔
چوتھی سطر پرانے PHP اور فریم ورک اسٹیکس پر اتنی ہی عام ہے۔ انکوڈ شدہ پے لوڈ سے پہلے چھپی ہوئی فرسودگی کی وارننگ ایسی باڈی بناتی ہے جو کوئی JSON تجزیہ کار قبول نہیں کرے گا، اور اکثر وہی وارننگ پوری وضاحت ہوتی ہے۔
مرحلہ 4: تجزیہ کار کی غلطی کو لفظی طور پر پڑھیں
خرابی کا متن پہلا حرف بتاتا ہے جس نے تجزیہ توڑا، اور یہ عام طور پر بغیر کسی اندازے کے قسم کی نشاندہی کرتا ہے۔
| Error text (Chrome/V8) | What it means |
|---|---|
| Unexpected token < in JSON at position 0 | The body starts with markup: an HTML page or an error document |
| Unexpected end of JSON input | Empty body, or the response was truncated |
| Unexpected token o in JSON at position 1 | You parsed something already parsed, typically an object rather than text |
| Unexpected token u | The body starts with the bare word undefined, usually an empty response rendered as a string |
200 کے ساتھ خالی باڈی ایک الگ معاملہ ہے: اینڈ پوائنٹ چلا، کچھ پیدا نہیں کیا، اور نیچے کسی چیز نے اسے کامیابی سمجھا۔ یہ منتقلی کی نہیں بلکہ ایپلیکیشن معاہدے کی ناکامی ہے، اور اس کی جگہ پراکسی میں نہیں اگلے مرحلے میں ہے۔ Firefox اور Safari وہی چار ناکامیاں مختلف انداز میں بیان کرتے ہیں، اس لیے درست اسٹرنگ کے بجائے حرف یا خالی باڈی پر موازنہ کریں۔
مرحلہ 5: اس تہہ کی اصلاح کریں جس کی طرف شواہد اشارہ کرتے ہیں
روٹنگ کے مسئلے کے لیے درخواست درست کریں: action ٹھیک کریں، ہینڈلر کو گرنے سے روکیں، اینڈ پوائنٹ اور طریقہ ہم آہنگ کریں، اور دوبارہ جانچیں۔ نمائندگی کے مسئلے کے لیے وہ چیز درست کریں جس نے باڈی بنائی، اور معلوم کریں کہ جہاں ڈیٹا متوقع تھا وہاں خرابی کی دستاویز کیوں واپس آتی ہے۔ معاہدے کے مسئلے کے لیے آپ کے چلائے جانے والے ورژن کے لیے فریم ورک کا اصل متوقع ڈھانچہ پڑھیں، اور کلائنٹ ڈھیلا کرنے کے بجائے جواب کو اسی کے مطابق ڈھالیں۔
مسدود رسائی والا جواب اپنا الگ مرحلہ چاہتا ہے، کیونکہ درخواست بذات خود درست ہو سکتی ہے اور باڈی کبھی آپ کے کوڈ تک نہ پہنچے۔ جواب کے Access-Control-Allow-Origin کا موازنہ براؤزر کے بھیجے گئے عین Origin سے کریں، اور یاد رکھیں کہ وائلڈ کارڈ اسناد والی درخواست پوری نہیں کرتا۔ کلائنٹ میں credentials: 'include' کو سرور میں Access-Control-Allow-Credentials: true کے ساتھ جوڑیں، اور دیکھیں کہ کال نے no-cors موڈ استعمال کیا یا نہیں، جہاں مبہم باڈی نقص نہیں بلکہ دستاویزی نتیجہ ہے۔
تجزیہ کار کو زیادہ نرم چیز سے بدلنا واحد اصلاح ہے جس سے بچنا چاہیے۔ جواب کو کوڈ کے طور پر جانچنا، یا تجزیہ ہونے تک متن اتارنا، معاہدے کی عدم مطابقت چھپاتا ہے اور خاموشی کے بدلے انجیکشن کی سطح بڑھاتا ہے۔ اسی طرح حیثیت کو باڈی سے الگ جانچنا لازم ہے: ایپلیکیشن سطح کے خرابی آبجیکٹ والا 200 بہت سے API میں معمول ہے اور پے لوڈ پڑھ کر سنبھالنا چاہیے۔
جب کسی اور کی مدد درکار ہو، خام ایکسپورٹ کے بجائے کم سے کم ریکارڈ شیئر کریں — طریقہ، URL، حیثیت، ری ڈائریکٹ کے بعد آخری URL، جواب کا مواد کی قسم، باڈی کی شکل اور متوقع معاہدہ۔ نیٹ ورک آرکائیوز میں کوکیز، ٹوکن، کوئری اسٹرنگز اور فارم میں موجود ذاتی ڈیٹا ہوتا ہے، اور خودکار صفائی کرنے والا جائزہ نہیں ہے۔
- کوئی بھی کوڈ بدلنے سے پہلے بغیر فلٹر درخواست پکڑیں۔
- تصدیق کریں کہ شروع کرنے والا آپ کی اسکرپٹ تھی اور آخری URL آپ کا اینڈ پوائنٹ ہے۔
- تجزیہ کار کو چھونے سے پہلے جواب کی درجہ بندی کریں۔
- روٹنگ، رسائی، نمائندگی یا معاہدہ درست کریں، اور تجزیہ کار ڈھیلا کر کے کبھی نہیں۔