Biểu mẫu AJAX mong đợi JSON nhưng nhận được HTML: lần theo phản hồi từng bước
Phản hồi 200 không chứng minh đó là JSON. Đi qua bảng Mạng từng bước và tách lỗi truyền tải, trình bày và hợp đồng.
Biểu mẫu được gửi, vòng xoay xuất hiện và bảng điều khiển báo có token < không mong đợi trong JSON tại vị trí 0. Bản thân trang tải tốt, nên phản xạ đầu tiên là đổ lỗi cho bộ phân tích hoặc đường hầm. Thường thì không cái nào trong hai thứ đó tham gia: việc gửi là một yêu cầu khác với việc tải trang, và nó quay về với thứ không phải JSON. Hãy làm việc theo đúng thứ tự mà trình duyệt thực sự tiết lộ, vì bốn câu trả lời khả dĩ cần bốn cách sửa khác nhau.
Bước 1: bắt lấy lần gửi thực sự đã xảy ra
Mở bảng Mạng trước khi gửi, đặt nhật ký giữ lại các mục qua các lần điều hướng, rồi thực hiện một lần gửi thử vô hại trên tài khoản bạn được phép dùng. Chọn yêu cầu do chính biểu mẫu khởi tạo, không phải yêu cầu tài liệu của trang.
Cẩn thận với bộ lọc. Bộ lọc XHR hoặc Fetch tiện lợi, nhưng nếu khung vẫn gửi qua iframe ẩn hoặc biểu mẫu được tạo động, bộ lọc sẽ giấu đi yêu cầu duy nhất quan trọng. Trước tiên hãy gửi một lần không lọc và xem điều gì xuất hiện.
Với yêu cầu đã chọn, ghi sáu thứ trước khi diễn giải bất cứ điều gì: phương thức, URL đầy đủ kèm chuỗi truy vấn, trạng thái, chuỗi chuyển hướng, Content-Type của phản hồi và những dòng đầu của phần thân. Tài liệu tham chiếu bảng Mạng của Chrome DevTools bao gồm các khung nhìn Headers, Response và Initiator nơi những thứ này nằm, và các bảng tương đương trong trình duyệt khác cũng hiển thị đúng những trường đó.
Bước 2: xác nhận đó đúng là yêu cầu bạn nghĩ
Một số lượng đáng ngạc nhiên lỗi JSON thực ra là lỗi định tuyến. Nếu trình xử lý gửi ném ngoại lệ trước khi gọi preventDefault, trình duyệt thực hiện POST biểu mẫu gốc tới địa chỉ trong thuộc tính action, và máy chủ trả về một trang HTML đầy đủ. Trình xử lý không bao giờ chạy, nghĩa là JSON chưa bao giờ được yêu cầu.
So sánh URL trong bảng với URL mà JavaScript của bạn gọi. Tìm chuyển hướng kết thúc ở nơi khác, dấu gạch chéo cuối bị thiếu hoặc thừa, lệch phương thức khi trình xử lý gửi GET còn điểm cuối nhận POST, hoặc biểu mẫu gửi tới đường dẫn tương đối từ một trang đã di chuyển. Theo chuỗi chuyển hướng đến cuối và ghi lại URL cuối cùng, không phải URL đầu tiên.
Sau đó kiểm tra bên khởi tạo. Nếu yêu cầu đến từ điều hướng tài liệu chứ không phải từ script của bạn, bạn đã tìm ra vấn đề, và không thay đổi nào trong bộ phân tích phản hồi giúp được.
Bước 3: phân loại kết quả thành bốn nhóm
Mỗi kết quả thuộc đúng một trong số này, và nhóm quyết định nơi xem tiếp theo.
| 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 |
Các hàng giữa là những hàng bị chẩn đoán sai, vì trạng thái là 200. Trang đăng nhập đạt được sau khi chuyển hướng là một phản hồi HTTP hoàn toàn tốt và một tài liệu JSON rất tệ. Kiểu nội dung application/json không sửa được điều đó: nó chỉ là nhãn, và phần thân bị dán nhãn sai vẫn không phân tích được. Truy cập bị chặn là hàng trông như yêu cầu đã hoàn tất: bảng hiển thị trạng thái, nhưng chính sách khác nguồn gốc giữ phần thân lại, nên với script gọi nó cũng vô dụng như hết thời gian chờ.
Hàng thứ tư cũng phổ biến không kém trên các chồng PHP và khung cũ. Một cảnh báo về việc không dùng nữa được in trước phần tải đã mã hóa tạo ra phần thân mà không bộ phân tích JSON nào chấp nhận, và thường thì cảnh báo đó chính là toàn bộ lời giải thích.
Bước 4: đọc lỗi của bộ phân tích theo đúng nghĩa đen
Văn bản lỗi nêu ký tự đầu tiên đã phá vỡ việc phân tích, và điều đó thường xác định nhóm mà không cần phỏng đoán.
| 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 |
Phần thân rỗng với 200 là trường hợp riêng: điểm cuối đã chạy, không tạo ra gì, và thứ gì đó phía sau coi đó là thành công. Đây là lỗi hợp đồng của ứng dụng chứ không phải lỗi truyền tải, và chỗ của nó là ở bước tiếp theo, không phải ở proxy. Firefox và Safari diễn đạt bốn lỗi giống nhau theo cách khác, nên hãy khớp theo ký tự hoặc phần thân rỗng chứ không theo chuỗi chính xác.
Bước 5: sửa lớp mà bằng chứng chỉ ra
Với vấn đề định tuyến, hãy sửa yêu cầu: sửa action, ngăn trình xử lý rơi qua, khớp điểm cuối và phương thức, rồi thử lại. Với vấn đề trình bày, hãy sửa thứ đã tạo ra phần thân, và tìm hiểu tại sao tài liệu lỗi lại được trả về ở nơi dữ liệu được mong đợi. Với vấn đề hợp đồng, hãy đọc cấu trúc thực sự mà khung mong đợi cho phiên bản bạn chạy, và tạo hình phản hồi theo đó thay vì nới lỏng máy khách.
Phản hồi bị chặn truy cập cần lượt riêng, vì bản thân yêu cầu có thể đúng và phần thân có thể không bao giờ đến được mã của bạn. So sánh Access-Control-Allow-Origin của phản hồi với Origin chính xác mà trình duyệt đã gửi, và nhớ rằng ký tự đại diện không thỏa mãn yêu cầu có thông tin xác thực. Ghép credentials: 'include' ở máy khách với Access-Control-Allow-Credentials: true ở máy chủ, và kiểm tra xem lời gọi có dùng chế độ no-cors hay không, nơi phần thân mờ đục là kết quả được ghi nhận chứ không phải khiếm khuyết.
Thay bộ phân tích bằng thứ dễ dãi hơn là cách sửa duy nhất cần tránh. Đánh giá phản hồi như mã, hoặc bóc văn bản cho đến khi phân tích được, sẽ giấu đi sự không khớp hợp đồng và thêm bề mặt chèn lệnh để đổi lấy sự im lặng. Tương tự, phải kiểm tra trạng thái tách biệt với phần thân: một 200 mang đối tượng lỗi cấp ứng dụng là bình thường ở nhiều API và phải được xử lý bằng cách đọc phần tải.
Khi cần người khác giúp, hãy chia sẻ một bản ghi tối thiểu — phương thức, URL, trạng thái, URL cuối sau chuyển hướng, kiểu nội dung của phản hồi, hình dạng phần thân và hợp đồng mong đợi — thay vì bản xuất thô. Kho lưu mạng chứa cookie, token, chuỗi truy vấn và dữ liệu cá nhân từng nằm trong biểu mẫu, và công cụ làm sạch tự động không phải là bước rà soát.
- Bắt yêu cầu không lọc trước khi thay đổi bất kỳ mã nào.
- Xác nhận bên khởi tạo là script của bạn và URL cuối là điểm cuối của bạn.
- Phân loại phản hồi trước khi chạm vào bộ phân tích.
- Sửa định tuyến, truy cập, trình bày hoặc hợp đồng, và không bao giờ bằng cách nới lỏng bộ phân tích.