2012-07-07 51 views
11

Tôi có một chương trình nhỏ gửi yêu cầu http và nhận phản hồi bằng giao thức TCP.Nhận phản hồi của yêu cầu http mà không có độ dài nội dung?

Định dạng yêu cầu của tôi;

GET/HTTP/1.0 
Host: somewebsite.com 
{two new line} 

Tôi đọc dòng phản hồi theo dòng từ socket (sử dụng NetworkStream và StreamReader in C#) cho đến khi tôi tìm tiêu đề có độ dài nội dung. Tôi lưu trữ độ dài, sau đó tiếp tục đọc cho đến khi tìm thấy một dòng trống. Sau đó tạo một bộ đệm với độ dài và nhận phần còn lại của phản hồi.

Nhưng một số phản hồi không có tiêu đề có độ dài nội dung. Vì vậy, cách tiếp cận của tôi không thành công. Nếu tôi không biết tôi sẽ nhận được bao nhiêu byte, khi nào tôi nên dừng lại?

Trả lời

4

Xem relevant part of HTTP spec. Trong trường hợp cụ thể của bạn, nếu máy chủ không cung cấp độ dài nội dung, thì PHẢI phải đóng luồng khi hoàn thành phản hồi. Không có cách nào khác đáng tin cậy cho bạn (như một khách hàng) để biết. Bất kể phiên bản HTTP. @Julian chunked mã hóa thực sự là một nâng cấp thông minh trong HTTP/1.1 nhưng là khá cụ thể để streaming và không có lý do tại sao một "đồng bằng" webserver sẽ thực hiện nó. Đó là một máy chủ biết chiều dài nội dung trước khi bắt đầu phản hồi. Và tôi đoán rằng OP không có máy chủ được kiểm soát, nếu không anh ta sẽ không phản đối tiêu đề HTTP bị thiếu.

Nhưng ngay cả khi bạn KHÔNG nhận được tiêu đề chiều dài nội dung, bạn must not unreservedly trust it. Những người triển khai máy chủ cũng chỉ là những con người đáng kinh ngạc. Mang nó như là một phản ứng "có thể xảy ra" nhất, giá trị ban đầu cho một bộ đệm có thể thay đổi kích cỡ. Bạn vẫn phải sẵn sàng để xử lý ít hơn cũng như nhiều hơn (trường hợp tồi tệ hơn).

+7

Điều đó rất gây hiểu lầm. Nếu phản hồi có trường tiêu đề nội dung có độ dài và không sử dụng mã hóa chunked, đó là thông tin * only * bạn có. Nếu bạn nhận được ít nội dung hơn, nội dung sẽ bị coi là bị cắt bớt. Nếu bạn nhận được nhiều nội dung hơn, serer bị hỏng hoặc bạn đang xem phản hồi tiếp theo. –

+0

Tôi đang khiêm tốn yêu cầu giải thích cách đọc phản ứng tiếp theo có thể xảy ra trên một ổ cắm duy nhất, khi khách hàng không hoàn thành việc phân tích cú pháp hiện tại, vì vậy rất khó gửi yêu cầu tiếp theo. Tôi có thể hiểu được điều tốt hơn. Nếu không, tôi không thấy bất kỳ sự bất đồng đáng kể nào về vấn đề này. Bạn sẽ làm gì khi bạn đọc đến độ dài nội dung được khai báo và socket đọc cho bạn biết còn 2 byte nữa không? Trong thực tế, nói rằng "máy chủ bị hỏng ngu ngốc, tôi sẽ không nói chuyện với bạn nữa" là không áp dụng thường xuyên như các lập trình viên tốt muốn. –

+0

vtmarvin: khách hàng có thể sử dụng pipelining. –

Các vấn đề liên quan