Modify

Opened 14 years ago

Closed 14 years ago

Last modified 13 years ago

#1772 closed Bug (Works For Me)

InetGet reload from the remote site

Reported by: anonymous Owned by:
Milestone: Component: AutoIt
Version: 3.3.6.1 Severity: None
Keywords: Cc: fran@…

Description

I have searched the forum and found quite a few people have this problem, but I have not found any solutions either on the forum or in the "AutoIt issue tracker".

I'm using InetGet() to download a txt file just after calling a php page (that creates the file).

I've set the options to 1 (= Forces a reload from the remote site.), but it doesn't seem to work. I always end up with the first file I downloaded, and never with an updated one.

Even the file that is lying in my temporary internet files, is the newest one, but AutoIt is not using the latest file.

InetGet("http://www.rapidstudio.info/fran/listaff.txt", @TempDir & "\listaff.txt", 1, 1)

Thanx in advance!

Fran

Attachments (0)

Change History (10)

comment:1 Changed 14 years ago by Jon

  • Resolution set to Works For Me
  • Status changed from new to closed

comment:2 Changed 13 years ago by TheGeneral

I'm running AutoIt version 3.3.8.0 and got the same problem. I wrote a script to check a website's source code modification. I tried to use InetGet, InetRead and _InetGetSource (which uses InetRead with force reload parameter). I put all of these functions inside an infinite while loop, displaying the source. I executed the program with the correct IP for the hostname. Changing the hosts file (@WindowsDir\system32\drivers\etc) in order to redirect the hostname to localhost (127.0.0.1), the source code displayed does not vanish. Only when I reboot the program, it is possible to get a null source code.
It is not a Windows issue, my browser cannot load the page with disabled cache.

comment:3 Changed 13 years ago by Jpm

Not sure to understand, with the first script I get a file whose time is changing.
That does not mean it has been updated as the contain is the same.
Cannot you update the link so it will point to a real changing file.
Thanks

comment:4 Changed 13 years ago by Jpm

In fact I conduct experiment with some accessible file under www.autoitscript.com and it was successful provided you wait the end of the download.
The first example is asking for a background download so sometime is needed before completion.

my environment is 3.3.8.0 (Language:040C Keyboard:0000040C OS:WIN_7/Service Pack 1 CPU:X64 OS:X86)

comment:5 Changed 13 years ago by TheGeneral

I wrote an example script in order to prove that InetRead does get data from cache, even when it's set to force a reload.

http://pastebin.com/pLT0vJkf

In my PC, I get the same data from both InetRead. It should not happen after the hostname is redirected to localhost. The data should be null.
There are many threads of people complaining about this issue. I don't think it's an isolated problem.

comment:6 Changed 13 years ago by The_General

Well, I used a packet sniffer to check if two "GET requests" are done. They are. For some reason,the second request doesn't use the new Ip Address (Localhost).
But, when the program is re-executed (with hosts still implying in the redirection), it resolves autoitscript.com hostname as localhost. I wrote a similar one with WinHTTP. The same problem happens. I don't quite understand how the re-execution forces the hostname resolution to localhost.

comment:7 Changed 13 years ago by The_General

Just to be clear about the WinHTTP solution. I did two examples here, one that does work, giving a null source code, and one that does not.
Before running the examples, make sure you have the WinHTTP UDF. It can be found here: http://winhttp.origo.ethz.ch/wiki/winhttp

Example working:
http://pastebin.com/6SvHBjmH

Example not working:
http://pastebin.com/M9JQwJr0

comment:8 Changed 13 years ago by Jpm

Your not working example is producing a Virus warning

SettingsModifier:Win32/PossibleHostsFileHijack

as the modification of etc is detected by antivirus "MS Security essential"

comment:9 Changed 13 years ago by The_General

Yeah, I got the same problem here. I think the AV doesn't like redirecting google hostname.
I deactivated the AV, and got the same results. With google.com address (not working) the result is not null, but with autoitscript.com it's.
Do you think InetGet/InetRead should follow the hosts guideline, or it's not a proper way to test the forced reload option?
This question was raised when I was working in a code for detecting a webpage modification. I thought the redirection would simulate a change. The solution was the substitution of InetRead for WinHTTP. Now, I'm not really sure about that. It works for some urls but not for others.

comment:10 Changed 13 years ago by Jpm

No real idea, At least this ticket is No Bug for me.
For your simulation I am not an expert on such impact of what etc is doing
Sorry for not helping more

Guidelines for posting comments:

  • You cannot re-open a ticket but you may still leave a comment if you have additional information to add.
  • In-depth discussions should take place on the forum.

For more information see the full version of the ticket guidelines here.

Add Comment

Modify Ticket

Action
as closed The ticket will remain with no owner.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.