작은 프로그램에서 HTTP 요청을 보내고 TCP 프로토콜로 응답을받습니다.Content-Length가없는 http 요청에 대한 응답을 얻으시겠습니까?
내 요청 형식.
GET/HTTP/1.0
Host: somewebsite.com
{two new line}
Content-Length 헤더를 찾을 때까지 소켓에서 응답을 (NetworkStream과 C#의 StreamReader를 사용하여) 읽습니다. 길이를 저장 한 다음 빈 줄을 찾을 때까지 계속 읽습니다. 그런 다음 길이가있는 버퍼를 만들고 나머지 응답을받습니다.
하지만 일부 응답에는 콘텐츠 길이 헤더가 없습니다. 그래서 내 접근 방식은 실패합니다. 얼마나 많은 바이트를 수신해야하는지 모르겠습니까?
HTTP/1.0? 스트림이 닫힐 때.
HTTP/1.1에서? chunked encoding.
relevant part of HTTP spec을 참조하십시오. 특정 경우에 서버가 컨텐츠 길이를 돌려주지 않으면 응답 완료시 스트림을 닫아야합니다 (MUST). 다른 신뢰할 수있는 방법으로 (클라이언트로서) 알 수 없습니다. HTTP 버전에 관계없이. @ 줄리안 청크 인코딩은 실제로 HTTP/1.1에서 영리한 업그레이드이지만 스트리밍에만 국한되며 "일반"웹 서버가 스트리밍을 구현할 이유가 없습니다. 응답을 시작하기 전에 콘텐츠 길이를 알고있는 서버입니다. 그리고 OP는 통제하에있는 서버를 가지고 있지 않다고 생각합니다. 그렇지 않으면 그는 누락 된 HTTP 헤더를 반대하지 않을 것입니다.
하지만 콘텐츠 길이 헤더를 얻더라도 must not unreservedly trust it입니다. 서버 구현자는 너무 잘못된 인간입니다. 크기를 조정할 수있는 버퍼에 대한 초기 값인 "가장 가능성있는"응답으로 가져옵니다. 당신은 여전히 더 많은 것을 처리 할 준비가되어 있어야합니다 (더 나쁜 경우).
매우 오해의 소지가 있습니다. 응답에 콘텐츠 길이 헤더 필드가 있고 청크 분할 인코딩을 사용하지 않는 경우 사용자가 보유한 * 유일한 * 정보입니다. 콘텐츠를 더 적게받는 경우 콘텐츠는 잘린 것으로 간주되어야합니다. 더 많은 콘텐츠를 받으면 시청자가 고장 났거나 이미 다음 응답을보고 있습니다. –
클라이언트가 현재의 구문 분석을 완료하지 못했을 때 다음 응답을 읽는 것이 단일 고유 소켓에서 어떻게 일어날 수 있는지에 대해 겸손히 묻습니다. 아직 다음 요청을 이미 보냈을 가능성은 거의 없습니다. 나는 downvote을 더 잘 이해할 것이다. 그렇지 않으면 나는이 문제에 대해 중요한 의견 차이를 보지 못한다. 선언 된 컨텐츠 길이까지 읽었을 때 당신은 무엇을하겠습니까? read는 2 바이트 더 남았음을 알려줍니다. 실제로, "어리석은 부러진 서버, 나는 더 이상 당신과 이야기하지 않을 것"이라고 말하는 것은 좋은 프로그래머가 원하는만큼 자주 적용되지 않습니다. –
vtmarvin : 클라이언트가 파이프 라이닝을 사용할 수 있습니다. –