HttpClient 4.0을 사용하여 ResponseHandler에서 얻은 응답이 실제 페이지 내용의 약 절반에 불과합니다. 반환 된 페이지의 문자열 대 ~ 61k 바이트 브라우저로). 나는이 일을 제한 할 어떤 종류의 한계가있는 곳을 찾는 것처럼 보인다. 어떤 아이디어?Httpclient가 전체 응답을 반환하지 않음
업데이트 : 발견 한 다른 한 가지는 이전 요청에 대한 일반적인 값인 반면 엔티티의 getContentLength 메서드에서 반환 한 크기는 -1입니다. javadoc은 길이가 알려지지 않았다는 것을 의미하는 것으로 보입니다.
업데이트 2 : 80KB가 넘는 페이지에 대한 응답을 찾으려고 시도했습니다. 응답 문자열의 최대 길이는 항상 18210 자입니다. 어떤 아이디어?
아마도 그렇지 않을 수도 있지만 어딘가에서 스트림을 플러시하지 않는 경우가 발생할 수 있습니다.
동의. 특히 Threads가 I/O와 관련되어있을 때 System.exit()가 호출되는 경우. – nicerobot
이것은 아마도 당신이 정교 할 수 있습니까? 이 페이지를 가져 오는'DefaultHttpClient'도 6+를 가져옵니다. 명시 적으로 플러시/삭제해야합니까? –
아직 읽은 데이터가 남아있는 동안 종료하지 않도록해야한다고 생각합니다. 스트림 닫기에 관해서는 javadoc http://goo.gl/iJjd를, InputStream.available()에 대해서는 javadoc을보세요 http://goo.gl/qXUf – nicerobot
다른 곳은 서버 쪽입니다.
하나의 가능성은 웹 응용 프로그램 코드가 때때로 응답 작성의 중간에 흔들리는 경우입니다. 또 하나는 서버 컨테이너 코드에 버그가 있다는 것입니다. 예를 들어, 톰캣의 오래된 버전에는 큰 응답이 엉망이되거나 잘리는 버그가 있음을 막연하게 기억합니다.
내가 응답을 읽기 전에 client.getConnectionManager().shutdown()을 호출하여이 문제가 발생했음을 발견했습니다. 요청을 수행 할 때 내 finally {} 블록 중 하나를 시도했고 종료로 인해 응답 중간 읽기가 중단되는 경쟁 조건이 발생했습니다.
getContentLength()도 Transfer-Encoding : chunked 헤더로 인해 발생했기 때문에 나에게도 -1을 돌려주었습니다. 나는 HttpClient 라이브러리가 chunked 응답을 올바르게 처리하지 못한다고 생각했지만 실제로는 그저 내 것이었다.
응답 내용을 보았습니까? 당신이 기대하는 페이지의 잘린 버전을 얻고 있습니까? 아니면 다른 페이지를 얻고 있습니까? –
잘린 버전 - 말 그대로 페이지의 첫 번째 절반. –