0

I'm writing a mobile application and I'm having difficulty downloading lengthy files from a Yahoo! server that periodically (about every three minutes) aborts the download. The mobile application successfully downloads lengthy files from other servers via the same slow data connection. A dump of the HTTP header from the Yahoo! server is

D/AsyncDownloadFile( 694): header fields: {p3p=[policyref="http://info.yahoo.co m/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA PO L HEA PRE LOC GOV"], content-type=[application/octet-stream], connection=[close] , last-modified=[Fri, 06 Aug 2010 14:47:50 GMT], content-length=[2000000], age=[ 0], server=[YTS/1.17.13], accept-ranges=[bytes], date=[Sat, 07 Aug 2010 18:53:02 GMT]}

which shows it defines connection=[close]. A different (non Yahoo!) server defines connection=[keep-alive] and my mobile application successfully downloads from it. So I have a few questions:
What is causing the Yahoo! server to periodically abort the downloads? What can I do to avoid the periodic aborting or what can I do to resume an aborted download? Are requests for byte ranges considered when the server defines connection=[close]?

Things I've read:

Things I've tried:

  • I've tried setting the http header "Connection" field to "keep-alive" but the Yahoo! server response was a header "Connection" field set to "close".
  • I've tried resuming the connection as described in this question. Even though the HTTP header from the Yahoo! server shows that it supports byte range requests and the content range responses appear correct (e.g., content-range=[bytes 387924-1999999/2000000]), the resumed transfers incorrectly resume at the file start. I'm wondering if that is due to the connection=[close] setting.

Because the subject of HTTP headers is rather new to me, any suggestions or warnings about common pitfalls are welcome.

[UPDATE] I received a reply from Yahoo! tech support saying that byte range is not supported: "Yahoo! Web Hosting does not support Accept-range header since we work with a pool of servers and each request potentially reaches a different server. You will see connection=[close] in the response header indicating this." The remaining question is whether or not the periodic download abortions can be avoided. (I tried requesting Connection="keep-alive" but that was ignored.)

Community
  • 1
  • 1
gregS
  • 2,580
  • 5
  • 28
  • 33
  • What's the URL you're trying to access? – Mark Nottingham Aug 11 '10 at 07:17
  • The URL is http://eduneer.com/tangled/phenotypic/2010_03_3.dat It is a test file of 500,000 4-byte integers that increment starting at 0. If aborted and resumed, a hex dump of the downloaded test file shows that the Yahoo! server restarts at the beginning of the file rather than resuming at the specified byte range. – gregS Aug 11 '10 at 11:02
  • I received a reply from Yahoo! tech support explaining that byte range requests are not accepted: "Yahoo! Web Hosting does not support Accept-range header since we work with a pool of servers and each request potentially reaches a different server. You will see connection=[close] in the response header indicating this." – gregS Aug 11 '10 at 11:08
  • You should post that as an answer and accept it (after one or two days). – BalusC Aug 11 '10 at 12:11

1 Answers1

0

I received a reply from Yahoo! tech support explaining that byte range requests are not accepted: "Yahoo! Web Hosting does not support Accept-range header since we work with a pool of servers and each request potentially reaches a different server. You will see connection=[close] in the response header indicating this."

Given that resuming a download is not possible, I asked if it was possible to avoid the periodic aborting of downloads (e.g., Connection=[keep-alive]). The Yahoo! tech support reply: "the process is handled by the system and there is currently no work around."

While these are not the answers I would have liked, I give credit to Yahoo! tech support for fielding questions about the Yahoo! server behavior.

gregS
  • 2,580
  • 5
  • 28
  • 33