Kitkat httpurlconnection 테스트 해보신분 계신가요?

Question

new Thread(new Runnable() {
			
			@Override
			public void run() {
				// TODO Auto-generated method stub
				try {
					URL ss = new URL(path);
					url = (HttpURLConnection) ss.openConnection();
					
					url.setConnectTimeout(1000);
					
									
					if(url.getResponseCode() == HttpURLConnection.HTTP_OK){
					
						int ddd = url.getContentLength();
						String sddd = url.getContentType();
						
					}
					
					
					
				}catch(Exception ee)
				{
					ee.printStackTrace();
				}
				
				finally{
					if(url != null) 
						{
						url.disconnect();
						url= null;
						}
				}
				
			}
		}).start();

Url path 인자값은 http프로토콜의 파일 링크  URL입니다.

젤리빈까지는 이상없는데 킷켓에서만 발생하고 있습니다.

단순 파일의 사이즈 구하는등 기본 httpurlconnection api에서 엄청난 데이터가 발생하는데 

킷켓 HttpURLConnection 버그를 의심하고 있습니다.

일단 데이터를 나가지 않게 하는 방법은 찾았는데 

정확히 킷켓 버그 인지 확신이 들지 않아 같은 현상을 겪고 계신분이 있는지 찾고 있습니다.

 

 

 

 

 

Answer 1

엄청난 데이터가 발생한다는게 무슨 뜻인가요?

Comments

url의 파일 사이즈가 26메가 정도 인데
api 사용만으로  26메가 또는 그 이상의 데이터가 발생하고 있습니다.

Answer 2

저도 KitKat에서 위의 코딩과 똑같이 url.getContentLength(); 값을 못가져오는 경우를 겪었습니다.

stackoverflow에 url.disconnect(); 대신 아래 코딩으로 대체하여 구현해 놓은 것이 있어 적어봅니다.

HttpClient httpclient = new DefaultHttpClient();

HttpResponse httpResponse = httpclient.execute(new HttpGet(fileUrl));

httpResponse.setHeader("Connection", "close");

 

위와 같이 Connection을 close한 경우가 있더군요. 저도 적용해 봤는데......

도움이 될런지 모르겠네요.

Answer 3

버그라고 보긴 힘들 것 같은데요.

레퍼런스에 이런 말이 있습니다.

By default, this implementation of HttpURLConnection requests that servers use gzip compression. Since getContentLength() returns the number of bytes transmitted, you cannot use that method to predict how many bytes can be read from getInputStream(). Instead, read that stream until it is exhausted: when read() returns -1. Gzip compression can be disabled by setting the acceptable encodings in the request header:

즉, HttpUrlConnection은 request할 때 용량을 줄이기 위해 gzip compression을 요청한다는 뜻입니다. 그럼 실제 무압축상태에서 1MB인 content라도 response header의 content-length필드에는 gzip 압축된 크기가 나올겁니다. 원하는 내용이 아니죠. 정확한 length를 알려면 압축을 풀어보는 수밖에 없습니다. 그래서 끝까지 다 읽는 과정이 들어간 것이 아닐까요?

해결방법은 바로 나와 있는 것처럼 무압축으로 request하면 될 것도 같네요. 헤더의 필드가 실제 사이즈니까 다 읽을 필요 없겠죠.

 urlConnection.setRequestProperty("Accept-Encoding", "identity");

네트웍 패킷 한 번 따보세요. compression이 gzip인지, response header의 Content-Length 필드가 얼마로 오는지도요.

 

================================

다시 읽어보니, 레퍼런스에서 말하는 내용은 getContentLength()가 틀린 값이 올 수도 있으니 믿지말라는 얘기였군요.;;;

흠흠.. 삭제하려다가 삭제 버튼을 못찾아서 그냥 놔둡니다. ㅎ