AJAX ձևը սպասում է JSON-ի, բայց ստանում է HTML․ պատասխանը քայլ առ քայլ
200 կարգավիճակը JSON լինելու ապացույց չէ։ Անցեք Ցանց պանելով քայլ առ քայլ և առանձնացրեք փոխադրման, ներկայացման և պայմանագրի խափանումները։
Ձևն ուղարկվում է, պտտվող նշիչը հայտնվում է, և կոնսոլը հայտնում է, որ JSON-ում 0 դիրքում անսպասելի < նշան կա։ Էջն ինքը լավ է բեռնվում, դրա համար առաջին արձագանքը վերլուծիչին կամ թունելին մեղադրելն է։ Սովորաբար ոչ մեկը չի մասնակցում․ ուղարկումը տարբեր հարցում է, քան էջի բեռնումը, և այն վերադարձել է մի բանով, որը JSON չէ։ Աշխատեք այն հերթականությամբ, որով զննարկիչը իրոք բացահայտում է այն, որովհետև չորս հնարավոր պատասխանները պահանջում են չորս տարբեր ուղղում։
Քայլ 1․ բռնեք իրականում տեղի ունեցած ուղարկումը
Բացեք Ցանց պանելը ուղարկելուց առաջ, կարգավորեք մատյանն այնպես, որ գրառումները պահպանվեն անցումների ընթացքում, ապա կատարեք մեկ անվտանգ փորձնական ուղարկում ձեզ թույլատրված հաշվով։ Ընտրեք այն հարցումը, որը սկսել է հենց ձևը, և ոչ թե էջի փաստաթղթի հարցումը։
Զգույշ եղեք զտիչներից։ XHR կամ Fetch զտիչը հարմար է, բայց եթե շրջանակը դեռ ուղարկում է թաքնված iframe-ով կամ դինամիկ ստեղծված ձևով, զտիչը կթաքցնի միակ կարևոր հարցումը։ Սկզբում մեկ անգամ ուղարկեք առանց զտիչի և տեսեք, թե ինչ հայտնվեց։
Ընտրված հարցման համար արձանագրեք վեց բան նախքան որևէ մեկնաբանություն՝ մեթոդը, ամբողջական URL-ը հարցման տողով, կարգավիճակը, վերահասցեավորման շղթան, պատասխանի Content-Type-ը և մարմնի առաջին տողերը։ Chrome DevTools-ի Ցանց պանելի տեղեկագիրքը ընդգրկում է Headers, Response և Initiator տեսքերը, որտեղ դրանք գտնվում են, և այլ զննարկիչների համարժեք պանելները ցույց են տալիս նույն դաշտերը։
Քայլ 2․ հաստատեք, որ դա այն հարցումն է, որ մտածում եք
Զարմանալիորեն շատ JSON սխալներ իրականում երթուղավորման սխալներ են։ Եթե ուղարկման մշակիչը բացառություն է նետում նախքան preventDefault կանչելը, զննարկիչը կատարում է բնիկ ձևի POST այն հասցեով, որը գրված է action ատրիբուտում, և սերվերը պատասխանում է ամբողջական HTML էջով։ Մշակիչը երբեք չի աշխատում, ուստի JSON երբեք չի պահանջվել։
Համեմատեք պանելի URL-ը ձեր JavaScript-ի կանչած URL-ի հետ։ Փնտրեք վերահասցեավորում, որը վերջանում է այլ տեղ, բացակայող կամ ավելորդ վերջնական շեղ, մեթոդի անհամապատասխանություն, երբ մշակիչը ուղարկում է GET, իսկ վերջնակետը ընդունում է POST, կամ ձև, որը ուղարկում է հարաբերական ուղի տեղափոխված էջից։ Հետևեք վերահասցեավորման շղթային մինչև վերջ և գրանցեք վերջնական 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 վերահասցեավորումներից հետո, պատասխանի բովանդակության տեսակ, մարմնի ձև և սպասվող պայմանագիր, այլ ոչ թե հում արտահանմամբ։ Ցանցային արխիվները պարունակում են cookie-ներ, token-ներ, հարցման տողեր և ձևում եղած անձնական տվյալները, իսկ ավտոմատ մաքրիչը ստուգատես չէ։
- Բռնեք հարցումը առանց զտիչի նախքան որևէ կոդ փոխելը։
- Հաստատեք, որ նախաձեռնողը ձեր սկրիպտն էր, և վերջնական URL-ը ձեր վերջնակետն է։
- Դասակարգեք պատասխանը նախքան վերլուծիչին դիպչելը։
- Ուղղեք երթուղավորումը, հասանելիությունը, ներկայացումը կամ պայմանագիրը, և երբեք վերլուծիչը թուլացնելով։