ฟอร์มถูกส่ง ตัวหมุนปรากฏ และคอนโซลบอกว่ามีอักขระ < ที่ไม่คาดคิดใน JSON ที่ตำแหน่ง 0 หน้าตัวเองโหลดได้ดี จึงเป็นเหตุให้ความคิดแรกคือโทษตัวแยกวิเคราะห์หรืออุโมงค์ โดยปกติไม่เกี่ยวข้องทั้งคู่: การส่งเป็นคำขอที่แตกต่างจากการโหลดหน้า และมันกลับมาพร้อมสิ่งที่ไม่ใช่ JSON ทำงานตามลำดับที่เบราว์เซอร์เปิดเผยจริง เพราะคำตอบที่เป็นไปได้สี่แบบต้องใช้การแก้ไขที่ต่างกันสี่แบบ

ขั้นที่ 1: จับการส่งที่เกิดขึ้นจริง

เปิดแผงเครือข่ายก่อนส่ง ตั้งบันทึกให้เก็บรายการข้ามการนำทาง แล้วทำการส่งทดสอบที่ไม่เป็นอันตรายหนึ่งครั้งบนบัญชีที่ได้รับอนุญาตให้ใช้ เลือกคำขอที่ฟอร์มเองเป็นผู้เริ่ม ไม่ใช่คำขอเอกสารของหน้า

ระวังตัวกรอง ตัวกรอง XHR หรือ Fetch สะดวก แต่ถ้ากรอบยังส่งผ่าน iframe ที่ซ่อนอยู่หรือฟอร์มที่สร้างขึ้นแบบไดนามิก ตัวกรองจะซ่อนคำขอเดียวที่สำคัญ ส่งหนึ่งครั้งโดยไม่มีตัวกรองก่อนแล้วดูว่าเกิดอะไรขึ้น

สำหรับคำขอที่เลือก ให้บันทึกหกอย่างก่อนตีความใด ๆ: เมธอด URL เต็มพร้อมสตริงคำค้น สถานะ ห่วงโซ่การเปลี่ยนเส้นทาง Content-Type ของการตอบกลับ และบรรทัดแรกของเนื้อหา เอกสารอ้างอิงแผงเครือข่าย ของ Chrome DevTools ครอบคลุมมุมมอง Headers, Response และ Initiator ที่สิ่งเหล่านี้อยู่ และแผงที่เทียบเท่าในเบราว์เซอร์อื่นแสดงฟิลด์เดียวกัน

ขั้นที่ 2: ยืนยันว่าเป็นคำขอที่คุณคิด

จำนวนข้อผิดพลาด JSON ที่น่าประหลาดใจคือข้อผิดพลาดด้านเส้นทาง ถ้าตัวจัดการการส่งโยนข้อยกเว้นก่อนเรียก preventDefault เบราว์เซอร์จะทำ POST ฟอร์มแบบดั้งเดิมไปยังที่อยู่ที่แอตทริบิวต์ action ระบุ และเซิร์ฟเวอร์ตอบด้วยหน้า HTML เต็ม ตัวจัดการไม่เคยทำงาน จึงไม่มีการขอ JSON เลย

เปรียบเทียบ URL ในแผงกับ URL ที่ JavaScript ของคุณเรียก มองหาการเปลี่ยนเส้นทางที่จบที่อื่น เครื่องหมายทับปิดที่ขาดหรือเกิน ความไม่ตรงกันของเมธอด หรือฟอร์มที่ส่งไปยังเส้นทางสัมพัทธ์จากหน้าที่ถูกย้าย ติดตามห่วงโซ่การเปลี่ยนเส้นทางจนถึงที่สุดและบันทึก URL สุดท้าย ไม่ใช่ตัวแรก

จากนั้นตรวจสอบผู้เริ่มต้น ถ้าคำขอมาจากการนำทางเอกสารไม่ใช่จากสคริปต์ของคุณ คุณพบปัญหาแล้ว และไม่มีการเปลี่ยนแปลงใดในตัวแยกวิเคราะห์การตอบกลับที่จะช่วยได้

ขั้นที่ 3: แบ่งผลลัพธ์เป็นสี่หมวด

ทุกผลลัพธ์อยู่ในหนึ่งในนี้เท่านั้น และหมวดเป็นตัวกำหนดว่าจะดูที่ใดต่อไป

What you seeCategoryWhere to look
Request never finishes, TLS or connection errorNo usable responseEndpoint reachability, certificate, front-end timeout
Request completes, script gets an opaque failureAccess blockedCross-origin policy, credentials mode, missing response header
200 with an HTML body or a login formWrong representationRedirect, expired session, route fallback, error handler
Body begins with a notice then valid JSONWrong representationServer-side warning output before serialisation
Valid JSON, framework rejects itContract mismatchEnvelope 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 0The body starts with markup: an HTML page or an error document
Unexpected end of JSON inputEmpty body, or the response was truncated
Unexpected token o in JSON at position 1You parsed something already parsed, typically an object rather than text
Unexpected token uThe 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 สุดท้ายคือปลายทางของคุณ
  • จำแนกการตอบกลับก่อนแตะตัวแยกวิเคราะห์
  • แก้ไขเส้นทาง การเข้าถึง การแสดงผล หรือสัญญา และไม่เคยด้วยการผ่อนคลายตัวแยกวิเคราะห์

บทความที่เกี่ยวข้อง