QUOTE (GetRight-Michael @ Aug 13 2007, 10:09 PM)

One of the biggest difficulties with Rapidshare is their URLs all expire quite quickly (minutes, many an hour).
So when you add a file, you can't wait to actually download it later--by the time you do, the URL usually has expired. I keep working, but there's not a good way around that.
Hi Michael,
I traced the TCP session, and it seems Getright does not interpret correctly the "Redirect" directive the Web server gives.
Basically in Rapidshare exists the possibility to bypass all the selections and clicks, and get directly the file. This is available to paying users that can configure their profile. Once a user have set up the DIRECT LINK option GetRight stop to work.
Here is what Happen:
We pass the URL to getright, and Getright
SEND the following:
GET /files/999999999/Demo.avi HTTP/1.1
Host: rapidshare.com
User-Agent: GetRight/6.3 (Pro)
Accept: */*
Cookie: user=12345-%31%32%33%34%35%36
Referer:
http://rapidshare.com/files/999999999/index.htmlAccept-Encoding:
Pragma: no-cache
Cache-Control: no-cache
and then GetRight
RECEIVE from the Site the following answer:
HTTP/1.1 302 Moved Temporarily
P3P: CP="ALL DSP COR CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa CONa TELa OUR STP UNI NAV STA PRE"
Date: Tue, 21 Aug 2007 17:24:43 GMT
Connection: close
Accept-Ranges: bytes
Location: http://rs169l3.rapidshare.com/files/999999999/Demo.aviContent-Length: 0
Note that the web server try to redirect Getright using the
Location: directive.
at this point, GetRight does not understand what to do and suddenly stops to communicate, and create a Demo.avi of 0 bytes !!!

On the contrary
THIS IS WHAT GETRIGHT SHOULD HAVE SENT just after exchanging the last message using the URL parsed in Location Parameter:
GET /files/999999999/Demo.avi HTTP/1.1
Accept: */*
Accept-Language: en-gb,en-us;q=0.5
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 1.1.4322)
Host: rs175l3.rapidshare.com
Proxy-Connection: Keep-Alive
Cookie: user=12345-%31%32%33%34%35%36
and the web site would have answered:
HTTP/1.1 200 OK
Date: Tue, 21 Aug 2007 17:24:43 GMT
Connection: close
Content-Type: application/octet-stream
Accept-Ranges: bytes
Content-Disposition: Attachment; filename=Demo.avi
Content-Length: 23080162
RIFF............... <<----- Binary data of the file... for FTP transfer...
So, it is easy now for you fix once for all the BUG. This did not happen on the old version.
I hope to see soon the updated version.
Cheers.
Roberto