Re: NSURLDownload and resuming a download
Re: NSURLDownload and resuming a download
- Subject: Re: NSURLDownload and resuming a download
- From: email@hidden
- Date: Thu, 12 Jun 2008 09:46:41 -0700
I've been doing some additional research using an HTTP Tracing tool (http://schroepl.net/cgi-bin/http_trace.pl) From what I can tell, Rapidshare is in fact indicating that they support ranged requests. Here is the header info of a request of a file I know for a fact can be resumed via Safari:
[ 15] HTTP/1.0 200 OK
[ 17] Connection: close
[ 35] Date: Thu, 12 Jun 2008 14:34:31 GMT
[ 20] Accept-Ranges: bytes
[ 31] ETag: "4d4b18-1aa7cbc-341b48c0"
[126] Server: Apache/2.0.61 (Unix) PHP/4.4.7 mod_ssl/2.0.61 OpenSSL/0.9.7e mod_fastcgi/2.4.2 Phusion_Passenger/1.9.0 DAV/2 SVN/1.4.2
[ 24] Content-Length: 27950268
[ 29] Content-Type: application/zip
[ 44] Last-Modified: Fri, 06 Jun 2008 01:15:55 GMT
Client-Date: Thu, 12 Jun 2008 14:34:21 GMT
Client-Peer: 208.97.191.210:80
Client-Response-Num: 1
Here is the header info of the request from Rapidshare (which Safari is unable to resume and will always start from the beginning):
[ 15] HTTP/1.0 200 OK
[ 17] Connection: close
[ 35] Date: Thu, 12 Jun 2008 14:32:56 GMT
[ 20] Accept-Ranges: bytes
[ 25] Content-Length: 100431872
[ 38] Content-Type: application/octet-stream
[ 57] Content-Disposition: Attachment; filename=gg701.part1.rar
[ 95] P3P: CP="ALL DSP COR CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa CONa TELa OUR STP UNI NAV STA PRE"
Client-Date: Thu, 12 Jun 2008 14:32:45 GMT
Client-Peer: 195.122.131.84:80
Client-Response-Num: 1
Of interest is the "Accept-Ranges: bytes" part. That's the indicator that the server allows ranged requests. Obviously NSURLDownload is checking something else in addition to that to determine if the download can be resumed. I just need to figure out what that is.
I sent an inquiry to Rapidshare to see if they were doing anything unconventional but didn't get a useful reply:
-----------------------------------------------------------------------------
Dear user,
sorry but we can not help you in this matter.
Other download-managers don't have problems like this.
Best regards,
Support
-----------------------------------------------------------------------------
Anybody have any more insight?
On Tuesday, June 10, 2008, at 02:42PM, <email@hidden> wrote:
> Jim,
>
>Thanks for the follow up. I was experimenting last night with tcpdump but unfortunately I really wasn't sure how to interpret the output. I'll try again tonight and post the results.
>
>On a related note, do you know exactly how NSURLDownload is setting the resumeData property? (i.e. determining if the download can be resumed) Through trial and error I learned that I have to call the cancel method before checking the resumeData property, otherwise it was always nil. That leads me to believe the when calling cancel, some sort of determination is being made. Is it attempting a ranged get to see if it gets an appropriate response?
>
>-jeffrey
>
>On Tuesday, June 10, 2008, at 11:52AM, "Jim Luther" <email@hidden> wrote:
>>Use:
>>
>>$ sudo tcpdump -s 0 -w ~/packets.dmp port 80
>>
>>where "80" is the port you are connecting to (80 is the default port
>>for HTTP). Start tcpdump, then run your code. After the failure, kill
>>tcpdump with control-C and the packets.dmp file will be in your home
>>directory. If you want to see the HTTP traffic in the file, use:
>>
>>$ sudo tcpdump -A -s 0 -r ~/webdavdump.dmp
>>
>>If this is an SSL connection, then the packet dump won't help diagnose
>>this problem because the HTTP traffic will be encrypted.
>>
>>- Jim
>>
>>On Jun 9, 2008, at 6:59 PM, Jeffrey Frabutt wrote:
>>
>>> Mark,
>>>
>>> Any chance you could suggest the best combination of options to
>>> tcpdump? I want to make sure I provide you with the appropriate data.
>>>
>>> Also, I tried canceling a download of a file I know for sure can be
>>> resumed and the resumeData was not nil and I was able to save it to
>>> a file and look at it and it looked okay. So obviously it's
>>> something with Rapidshare. I know for a fact that there are
>>> numerous download managers that can resume downloads from
>>> Rapidshare... but I guess they are doing it in an unconventional
>>> way. That said, I'd still like to try to figure out why
>>> NSURLDownload can't do the resume.
>>>
>>>
>>> On Jun 9, 2008, at 4:57 PM, Mark Pauley wrote:
>>>
>>>> Could you provide us with a tcpdump of this interaction? I'd be
>>>> interested to see if the server is responding with a failure and if
>>>> we're even trying to ask for a ranged-get.
>>>>
>>>> My money is on the server not allowing this functionality.
>>>>
>>>>
>>>> _Mark
>>>>
>>>> On Jun 7, 2008, at 11:53 AM, email@hidden wrote:
>>>>
>>>>> I'm working on a download utility and so far everything is coming
>>>>> along nicely. I'm now trying to implement cancel/resume
>>>>> functionality and have been testing against a rapidshare file.
>>>>> I've got a premium account so download resumption is supposed to
>>>>> be supported, however the download objects resumeData is always
>>>>> nil, which according to the documentation implies that the
>>>>> download can't be resumed. Is there any way of figuring out why
>>>>> this is? Does anyone know what NSURLDownload is expecting to get
>>>>> from the host that guarantees a file download can be resumed?
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Do not post admin requests to the list. They will be ignored.
>>>>> Macnetworkprog mailing list (email@hidden)
>>>>> Help/Unsubscribe/Update your Subscription:
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Macnetworkprog mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>>
> _______________________________________________
>Do not post admin requests to the list. They will be ignored.
>Macnetworkprog mailing list (email@hidden)
>Help/Unsubscribe/Update your Subscription:
>
>This email sent to email@hidden
>
>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macnetworkprog mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden