It would also provide yet another flag to the already-complex
protocol. Why not use the HTTP features that already exist?
- If a server returns a response with no Accept-Range, and the
transfer is then interrupted, don't try resuming.
- If we try resuming and we get status 200, truncate file.
Enviado desde mi iPod
El 23/06/2009, a las 01:08, David Anderson <[email protected]>
escribió:
It seems like any solution is going to involve a client change.
So what about my previous suggestion,
namely a <no_partial_transfer> flag in the <file_info>.
That would provide control at the server side, which is desirable.
-- DPA
Carl Christensen wrote:
I don't think libcurl distinguishes between a 206 & 200 (from this
message I
found from the main libcurl guy, although it's a two-year old
thread):
http://curl.haxx.se/mail/lib-2007-05/0011.html
it seems safer to just not let curl try to compress/decompress
(i.e. no gzip
in content headers) and treat it as any file (which can handle the
resumable
downloads) and then just decompress by the app after the file is
successfully
downloaded.
Carl Christensen [email protected] http://www.geocities.com/carlgt1
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
_______________________________________________
boinc_dev mailing list
[email protected]
http://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
