tôi dường như không thể có được một câu trả lời dứt khoát về những câu dưới đây (Googling chủ yếu và đọc HTTP/1.1 thông số kỹ thuật):(chunked) HTTP nhị phân nội dung thư và CRLFs
Khi 'chunked' mã hóa chuyển được sử dụng, tại sao máy chủ cần phải viết ra cả hai kích thước chunk theo byte và có kết thúc dữ liệu đoạn tiếp theo với CRLF. Điều này không làm cho việc gửi dữ liệu nhị phân "CRLF-unclean" và phương thức thừa một chút? Điều gì sẽ xảy ra nếu dữ liệu có 0x0A theo sau bởi 0x0D ở một nơi nào đó (tức là đây thực sự là một phần của dữ liệu)? Khách hàng có dự kiến tuân thủ quy mô chunk một cách rõ ràng được cung cấp ở phần đầu của đoạn hoặc bị nghẹt thở trên CRLF đầu tiên mà nó gặp phải trong dữ liệu không? Sự hiểu biết của tôi cho đến nay là chỉ cần lấy kích thước chunk được cung cấp bởi máy chủ, tiến tới dòng tiếp theo, sau đó đọc chính xác số byte này từ bên trong dữ liệu sau (CRLF hoặc không có CRLF bên trong), sau đó bỏ qua CRLF theo sau dữ liệu và lặp lại quy trình cho đến khi không còn khối nữa ... Tôi có đúng không? Điểm CRLF sau mỗi datachunk là gì? Dễ đọc?
Cảm ơn lời giải thích. Bạn lấy nó từ tài liệu RFC 2616 hay ở nơi khác? Lời giải thích của bạn cũng ngụ ý rằng đoạn trả lời CÓ THỂ KHÔNG chứa sự kết hợp CRLF như là một phần của chính dữ liệu? – amn
Nó theo sau từ EBNF trong RFC; lưu ý rằng 'chunk-data' bao gồm' OCTET', gợi ý rằng các byte đó không được hiểu. Một đoạn phản ứng chắc chắn có thể chứa CRLF. Tôi đã thực hiện một codec chunked hai lần bây giờ, cả hai lần trong Java, và trong mỗi trường hợp tôi đã không làm bất kỳ giải thích về nội dung của dữ liệu chunk. Nó mờ đục với khung hình chunk. Bộ giải mã xác định độ dài dự kiến, đọc nhiều byte, và sau đó đảm bảo rằng hai byte tiếp theo là CR và LF. – seh
Điều đó làm cho nó hoàn toàn rõ ràng với tôi. Quy tắc Octets. Cảm ơn bạn đã dành thời gian. – amn