BoscoBilly
17th August 2009 03:54 UTC

inetc plugin mangles URL and will not save file
Hello.
I am using the intec plugin to download a file on an amazon authenticated connection.
I am using an URL with a sig b64 hash, expire date and a couple of qry vars. It is URLencoded.
I create and pass the URL to inetc.
inetc, in 2 of 3 tries, receives an Access Forbidden or Bad Signature 403, in which case, no file is downloaded.
When it succeeds in getting the file, it "saves" an empty file.
I capture this url from the installer in debug by copy/paste from messagebox just b4 the get statement and when I type it in firefox or explorer, it works every time.
I am dependent upon this plugin and would much appreciate some help.
Thanks.

this is the simple 'get' I use:

inetc::get /CAPTION "Getting package...." /BANNER "Downloading files....." "$3" "$R7" /end
Pop $1
$3 is the URL and $R7 is the file to save to.

BoscoBilly
18th August 2009 03:35 UTC

**** UPDATE ************

The inetc plugin WILL save the file; it was my err that caused that problem.

However, inetc is fouling up my URL and preventing downloads by my installer. That is, the signed URL that is given to the inetc GET fails 2/3 times.
I am logging these URLs and, without exception, when I type the same URL into FF or IE, it downloads the file!

I really need some immediate help on this from Takhir as I am ready to launch and now have no reliable way to DL the App I am selling.

Takhir
18th August 2009 17:54 UTC

Can you give me sample URL which reproduces the situation? Do you have a direct connection to server or this is proxy/vpn/some_other specific configuration?

BoscoBilly
18th August 2009 20:40 UTC

Thanks for responding, Takhir.
I will prepare and send you an URL.
These are authenticated, access-control URLs with EXPIRE times (required).


I create these URLS on-demand to Amazon S3 specs.
Each URL works perfectly in a browser.
When passed through inetc::get, somehow the URL is corrupted about 2of 3 times, in an uneven distribution.
Sometimes 4 in a row are fine then 3 bad, etc.

The failures are 2 types of 403: Access Denied - in this case, this can be caused by an err in any part of the URL Qry var string from '?' to the right;
Signature does not match: - this occurs when either the sig part of the qry string is bad or the request part - i.e., the part b4 the '?' of the qry string.

It would seem that, depending on the URL inetc:get sees, it's processing will introduce input-dependent errors.

My connection to the source is direct Inet via an URL that you can type in any FF or IE browser from any computer with Inet access.

I will PM you the URL.

Takhir
19th August 2009 08:47 UTC

I downloaded a whole file 3 times and also started/cancelled download few times, all works like a dream. Attached version displays message box with cracked URL parts - I could see path/file name and signature fields in Extra, looks OK. Did you tested download from other LAN? What about using POST request (but I am not sure this may help :( )?

BoscoBilly
19th August 2009 16:23 UTC

Thanks a lot Takhir!
But did you get a chance to test the other 3 URLS I sent by PM?
There is one bad and 2 good.

BoscoBilly
20th August 2009 20:14 UTC

Hi Takhir.
Any luck with those new Urls?

Takhir
21st August 2009 07:07 UTC

Excuse, ИoscoBilly, I now in a time trouble, but will try to find time tonight and to check up your URLs.

Takhir
21st August 2009 17:38 UTC

I don't remember why I used URL escape sequences decoding in this client. Now looks better with your URLs. Please test.

BoscoBilly
21st August 2009 18:52 UTC

Solved!
Excellent!
:D
Works great!
Thanks for taking the time to fix this, Takhir.

Will you be posting the updated source as well?
As to this problem... I'm surprised no one else has mentioned this.

:up:

Takhir
21st August 2009 19:39 UTC

Thanks! Yes, I'll also add 'marque' progress bar style for downloads with unknown file size and put package to wiki after this.

BoscoBilly
21st August 2009 19:42 UTC

Terrific!
Thanks again, Takhir.

mark.ruys
15th January 2010 10:58 UTC

Unicode (URL Parts Error)

Originally posted by Takhir
I don't remember why I used URL escape sequences decoding in this client. Now looks better with your URLs. Please test.

Takhir
15th January 2010 16:55 UTC

May be Redxii used old sources for this... I am attaching unicode dll version built from Aug 22, 2009 sources, please let me know if this is OK, I'll put it to wiki this case.

mark.ruys
15th January 2010 18:34 UTC

Originally posted by Takhir
May be Redxii used old sources for this... I am attaching unicode dll version built from Aug 22, 2009 sources, please let me know if this is OK, I'll put it to wiki this case.

Takhir
16th January 2010 10:10 UTC

/END required because plug-in can download few files in a single requiest. But I am not sure if this feature was ever used.