inetc plugin mangles URL and will not save file

BoscoBilly · 17th August 2009, 03:54

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

**** 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

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

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

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

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

Hi Takhir.
Any luck with those new Urls?

Takhir · 21st August 2009, 07:07

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

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

Excellent!

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.

Takhir · 21st August 2009, 19:39

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

Terrific!
Thanks again, Takhir.

mark.ruys · 15th January 2010, 10:58

Quote:

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.

Could you please post the modifications you made in the source. Or upload a Unicode compiled inet.dll. I keep getting URL Parts Error errors, even with the latest dll from nsis.sourceforge.net/Inetc_plug-in.

Thanks,

Mark

PS. The URL the installers tries to download is www.microsoft.com/downloads/info.aspx?na=90&p=&SrcDisplayLang=en&SrcCategoryId=&SrcFamilyId=0856eacb-4362-4b0d-8edd-aab15c5e04f5&u=http%3a%2f%2fdownload.microsoft.com%2fdownload%2f5%2f6%2f7%2f567758a3-759e-473e-bf8f-52154438565a%2fdotnetfx.exe

Takhir · 15th January 2010, 16:55

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

Quote:

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.

In the end I managed to get rid of the "URL Parts Error" error by adding "/END" to the inetc:get invocation (as documented, though I don't fully understand why).
I used the stable dll. So I guess my problem had nothing to do with this thread.

Takhir · 16th January 2010, 10:10

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

17th August 2009, 03:54	#1
BoscoBilly Junior Member Join Date: May 2009 Posts: 43	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.

21st August 2009, 18:52	#10
BoscoBilly Junior Member Join Date: May 2009 Posts: 43	Solved! Excellent! 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.

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

18th August 2009, 03:35	#2
BoscoBilly Junior Member Join Date: May 2009 Posts: 43	** 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.

18th August 2009, 17:54	#3
Takhir Major Dude Join Date: Feb 2004 Location: Moscow, Russia Posts: 1,222	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?

18th August 2009, 20:40	#4
BoscoBilly Junior Member Join Date: May 2009 Posts: 43	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.

19th August 2009, 16:23	#6
BoscoBilly Junior Member Join Date: May 2009 Posts: 43	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.

20th August 2009, 20:14	#7
BoscoBilly Junior Member Join Date: May 2009 Posts: 43	Hi Takhir. Any luck with those new Urls?

21st August 2009, 07:07	#8
Takhir Major Dude Join Date: Feb 2004 Location: Moscow, Russia Posts: 1,222	Excuse, Ð˜oscoBilly, I now in a time trouble, but will try to find time tonight and to check up your URLs.

21st August 2009, 19:39	#11
Takhir Major Dude Join Date: Feb 2004 Location: Moscow, Russia Posts: 1,222	Thanks! Yes, I'll also add 'marque' progress bar style for downloads with unknown file size and put package to wiki after this.

21st August 2009, 19:42	#12
BoscoBilly Junior Member Join Date: May 2009 Posts: 43	Terrific! Thanks again, Takhir.

15th January 2010, 16:55	#14
Takhir Major Dude Join Date: Feb 2004 Location: Moscow, Russia Posts: 1,222	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.

16th January 2010, 10:10	#16
Takhir Major Dude Join Date: Feb 2004 Location: Moscow, Russia Posts: 1,222	/END required because plug-in can download few files in a single requiest. But I am not sure if this feature was ever used.