Problem with "1-shot" download and inetget

[Datenshi]

I'm having problems figuring out a solution for RapidQueuer(example scripts forum), The issue was reported here #694876, and tests were reported on to page 8 of that thread.

However, in short the problem is, when used, InetGet does not support a possibility to manipulate the function and/or make decisions based on server header, before initiating the download. What would be an easy solution was if File name(Content-Disposition) and File size(Content-Length) information could be reached before deciding to write file to disk.

To further complicate things in my situation, Rapidshare allows only 1-shot connections, meaning you can only initiate the download once in order for it to work properly(generate RS point for the uploader). If i would choose to ignore getting file size before the download it would mean a great loss of Download Progress information, and i would be unable to compare the file size with a file already on disk, which in turn would mean no option of automatically deciding whether or not to overwrite.

The current method(bugged) is that i send InetGetSize() then do the "overwrite" decisions and use that variable for download progress and information, when everything checks out ill continue and initiate an InetGet on the file. This will download the file, but this means I'll connect to the server twice and wont be generating an RS point for the uploader.

I'm looking for ideas, and possible solutions to this problem and figure there's a bigger chance of getting help in the help forum then in my thread.

Obtained using HTTP Live Headers, FF Addon:

Client Header

POST /files/353535353/35533535/test.rar HTTP/1.1
Host: rs744tl2.rapidshare.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.11) Gecko/2009060215 Firefox/3.0.11 (.NET CLR 3.5.30729)
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://rs744.rapidshare.com/files/35353535/test.rar
Content-Type: application/x-www-form-urlencoded
Content-Length: 19
mirror=on&x=65&y=68

Server Header

HTTP/1.x 200 OK
Date: Tue, 16 Jun 2009 17:18:33 GMT
Connection: close
Content-Type: application/octet-stream
Accept-Ranges: bytes
Content-Disposition: Attachment; filename=test.rar
Content-Length: 5650015

Edited July 17, 2009 by Datenshi

[Datenshi]

I actually got this solved by finding out an alternative way using Rapidshare API, which proves to be much better actually then any another way. It should still be considered a workaround tho since i was lucky that RS published their API. Others with similar situations might not be.

Edited July 17, 2009 by Datenshi