Re: NSURLDownload and resuming a download
Re: NSURLDownload and resuming a download
- Subject: Re: NSURLDownload and resuming a download
- From: Jens Alfke <email@hidden>
- Date: Thu, 12 Jun 2008 11:14:42 -0700
On 12 Jun '08, at 9:46 AM, email@hidden wrote:
Here is the header info of the request from Rapidshare (which Safari
is unable to resume and will always start from the beginning):
I think the problem is that RapidShare's response doesn't include an
ETag or Last-Modified header. Without those, the client can't do a
conditional GET. And trying to resume a download without using a
conditional GET is dangerous, because you can't tell if the resource
you're downloading now is the same version as the one you partially
downloaded before; so you might end up with a chimera.
I looked through the HTTP 1.1 RFC and didn't see anything about a
requirement that a server MUST send an ETag if it sends an Accept-
Ranges:; but I think that's because there are other valid uses of byte-
range GETs than resuming downloads, and the ETag might not be needed
for those.
I did find this passage:
If a client has a partial copy of an entity in its cache, and wishes
to have an up-to-date copy of the entire entity in its cache, it
could use the Range request-header with a conditional GET (using
either or both of If-Unmodified-Since and If-Match.) However, if the
condition fails because the entity has been modified, the client
would then have to make a second request to obtain the entire
current entity-body. [1]
—Jens
[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.27
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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