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 ಅನ್ನು ನಿಮ್ಮ JavaScript ಕರೆಯುವ URL ನೊಂದಿಗೆ ಹೋಲಿಸಿ. ಬೇರೆಡೆ ಕೊನೆಗೊಳ್ಳುವ ಮರುನಿರ್ದೇಶನ, ಕಾಣೆಯಾದ ಅಥವಾ ಹೆಚ್ಚುವರಿ ಕೊನೆಯ ಸ್ಲ್ಯಾಶ್, ವಿಧಾನ ಹೊಂದಿಕೆಯಾಗದಿರುವುದು, ಅಥವಾ ಸ್ಥಳಾಂತರಗೊಂಡ ಪುಟದಿಂದ ಸಾಪೇಕ್ಷ ಮಾರ್ಗಕ್ಕೆ ಕಳುಹಿಸುವ ಫಾರ್ಮ್ ಹುಡುಕಿ. ಮರುನಿರ್ದೇಶನ ಸರಪಳಿಯನ್ನು ಕೊನೆಯವರೆಗೆ ಅನುಸರಿಸಿ ಮತ್ತು ಕೊನೆಯ 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 ನಿಮ್ಮ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಎಂದು ಖಚಿತಪಡಿಸಿ.
- ಪಾರ್ಸರ್ ಮುಟ್ಟುವ ಮೊದಲು ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ವರ್ಗೀಕರಿಸಿ.
- ಮಾರ್ಗ, ಪ್ರವೇಶ, ಪ್ರತಿನಿಧಿತ್ವ ಅಥವಾ ಒಪ್ಪಂದ ಸರಿಪಡಿಸಿ, ಮತ್ತು ಪಾರ್ಸರ್ ಸಡಿಲಿಸಿ ಎಂದಿಗೂ ಅಲ್ಲ.