home *** CD-ROM | disk | FTP | other *** search
- --------------------------------------------------------------------------------
-
- Finished
- --------------------------------------------------------------------------------
- Type : Bug
- Fixed in : 1.10.007
- Fixed on : 12-01-99
- Reported by : Scott Brown
- Reported on : 12-01-99
- Short description : WebUtil erasing a directory even though IFMOD feature is turned on
- Author's notes : It turned out that according to the
- documentation, the proper verb was IF_MOD. I
- thought it was "IFMOD" and the source code
- expected "MOD_ONLY". In order to remain
- consistent with the FTP verbs, the correct verb
- is now IFMOD. The documentation has been updated,
- the sources have been changed, and my memory has
- been updated as well ;-)
-
- Type : Bug
- Fixed in : 1.10.007
- Fixed on : 12-01-99
- Reported by : Scott Brown
- Reported on : 12-01-99
- Short description : %20 tokens in url's still causing problem
- Long description : Scott reports:
-
- "It would seem that any conversation with a HTTP
- server which refers to a file
- with a %'d character in it results in file not
- found messages... I've got logs
- full of HTTP 404's:
-
- 09-01-99 18:21:00 Connection establishedwith
- http://eds-jokelist.com
- 09-01-99 18:21:02 Unable to find Courtney Love
- Stinks.mp3
- 09-01-99 18:21:02 Server reported: HTTP/1.1 404
- Not Found
-
- I think that if you revert to your old handling,
- BUT fix the filename that is
- used to write out the file to disk, that you
- would have this sucker licked."
- Author's notes : I have not double checked my fix, because my
- internet provider was busy all evening...<sigh>
-
- Type : Bug
- Fixed in : 1.10.007
- Fixed on : 15-01-99
- Reported by : Dallas Hinton
- Reported on : 15-01-99
- Short description : Error incorrectly logged
- Long description : FTP error 530 indicates that the server is busy
- and that the user should try back in a few
- minutes. WebUtil logs this error as "User name
- incorrect".
- Author's notes : Error code 530 means "not logged in". This error
- can be reported for a variety of reasons. WebUtil
- will report "Not logged in" and the user will
- have to consult the log file for details about
- why.
-
- Type : Bug
- Fixed in : 1.10.006
- Fixed on : 14-11-98
- Reported by : Scott Brown
- Reported on : 07-11-98
- Short description : WebUtil is not "finishing" closing a socket.
- Long description : Netstat -s reports :
-
- 192 STREAM 4962 3265
- 207.195.92.151 CLOSE_WAIT
- 156 STREAM 4961 3262
- 207.195.92.151 CLOSE_WAIT
- 176 STREAM 4960 3261
- 207.195.92.151 CLOSE_WAIT
- 177 STREAM 4959 3259
- 207.195.92.151 CLOSE_WAIT
- 92 STREAM 4958 3258
- 207.195.92.151 CLOSE_WAIT
- 183 STREAM 4957 3257
- 207.195.92.151 CLOSE_WAIT
- 194 STREAM 4956 3256
- 207.195.92.151 CLOSE_WAIT
- 169 STREAM 4955 3255
- 207.195.92.151 CLOSE_WAIT
-
- All of the sockets with the CLOSE_WAIT status
- clear when WebUtil exits.
- Author's notes : It turns out that the data sockets were not being
- closed.
-
- Type : Bug
- Fixed in : 1.10.006
- Fixed on : 14-11-98
- Reported by : Scott Brown
- Reported on : 14-11-98
- Short description : WebUtil is not parsing %xx tokens in HTML code.
- Long description : Scott reports:
-
- "Problem #1: WU gives up in the middle of HTTP
- transfers and complains something
- like this:
-
- Downloading Clean%20The%20Aquarium.mp3 989498
- bytes
- Unable to complete dProcessing task Process
- level(s)
- Clean%20The%20AquariProce
- Connecting ...
- Connection established
- Retrieving file header information
-
- Problem #2: The files being received from the
- server contain "%20" indicating
- spaces in the filename (see the above example).
- The file that is written
- contains %20 as text in the filename, rather than
- the space character. (this
- is a common problem with NS404 as well... only
- (ugh) MSIE seems to process it
- right from what I've seen)."
-
- Type : Bug
- Fixed in : 1.10.006
- Fixed on : 04-01-99
- Reported by : "Frank Koehler" <koehler@planet-interkom.de>
- Reported on : 08-12-98
- Short description : WebUtil does not work with a proxy server
- Author's notes : It took me some time to figure out how to use a
- proxy server. Now that I know how, it amazes me
- (actually it depresses me) that it too me so
- long, because it's actually very very simple ;-)
-
- I have added a new verb for a proxy server to the
- [MAIN] block of the INI file, namely:
-
- PROXY=[(ip)address of proxy server]:[port number
- for proxy server]
-
- Example:
-
- PROXY_URL=myproxy.allfix.com:8080
-
- I would appreciate it if everyone who has a proxy
- server would give it a try ;-))
-
- Please note that ALLFIX currently only supports
- proxy servers for the HTTP protocol.
-
- Type : Bug
- Fixed in : 1.10.006
- Fixed on : 18-12-98
- Reported by : (I forgot)
- Reported on : 18-12-98
- Short description : Unable to upload files larger then +/- 12kb
- Author's notes : This particular problem only occured in the
- Windows version of WebUtil.
-
- Type : Bug
- Fixed in : 1.10.005
- Fixed on : 22-10-98
- Reported by : Harald Harms
- Reported on : 20-10-98
- Short description : Remove the restriction on the lower limit of the LIST_DELAY.
-
- Type : Bug
- Fixed in : 1.10.005
- Fixed on : 22-10-98
- Reported by : Scott Brown
- Reported on : 21-10-98
- Short description : Connection attempts are not being logged in the DEBUG.LOG file
-
- Type : Bug
- Fixed in : 1.10.004
- Fixed on : 09-10-98
- Reported by : Scott Brown
- Reported on : 07-10-98
- Short description : Errors in INI file difficult to find
- Long description : When there is an error in the INI file, WebUtil
- flashes an error message on the screen real
- quickly, and then exists. This makes it very
- difficult to determine where the error is.
- Author's notes : The error message that WebUtil displayed also
- reports the line number on which the problem
- occured. This number was incorrect.
-
- Type : Bug
- Fixed in : 1.10.004
- Fixed on : 09-10-98
- Reported by : Scott Brown
- Reported on : 07-10-98
- Short description : Not able to download URLs that do not specify a filename
- Long description : A URL such as the following:
-
- http://www.silverpoint.com/leo/lia/icon/construct/
-
- is a valid URL, however, WebUtil will not
- download it until the filename is specified.
- WebUtil should be able to figure this out by
- itself since the URL is valid.
- Author's notes : This particular problem did not have anything to
- do with not being able to download an URL if the
- filename was not specified. The actual problem
- had to do with the routine that created a dummy
- filename based on the URL (since the filename is,
- in this case, not known). The filename created
- could not be created on the harddrive, hence the
- error that WebUtil was unable to download the
- file.
-
- Type : Bug
- Fixed in : 1.10.004
- Fixed on : 09-10-98
- Reported by : Harald Harms
- Reported on : 09-10-98
- Short description : Debug log file not closed properly under certain conditions
- Long description : If WebUtil was not successful logging into an FTP
- server, then the DEBUG log file would not be
- closed properly. This could result in the last
- data written to the file to be lost since the
- write buffers may not be flushed yet. This may
- also cause the appearance that WebUtil aborted
- before finishing all the tasks.
-
- Type : Bug
- Fixed in : 1.10.004
- Fixed on : 12-10-98
- Reported by : Harald Harms
- Reported on : 11-10-98
- Short description : Make retrieving a LIST more reliable
- Long description : The problem that I have attempted to solve is the
- fact that WebUtil apparently does not collect all
- of the LIST data, before starting with
- downloading files. This results in the problem
- that not all of the files are downloaded in one
- session.
- Author's notes : One possibility that I had not considerd earlier
- is to simply continue to wait for LIST data if
- the last textual line received is not complete.
-
- See, WebUtil receives the data in binary format,
- stuffing it all in a buffer and then parsing it
- later. However, since each line must be
- terminated with a carriage return line feed
- combination (or only one of them), it's quite
- easy to determine whether the last line is
- complete.
-
- There is still a chance that WebUtil does not
- wait long enough to receive all of the data.
- However, that chance should be much smaller now
- that this extra control mechanism has been built
- in.
-
- Type : Bug
- Fixed in : 1.10.004
- Fixed on : 16-10-98
- Reported by : Dallas Hinton
- Reported on : 15-10-98
- Short description : Experiment with 5 second delays in the LIST routines
- Long description : Dallas checks about 20 directories on an FTP file
- on a regular basis. WebUtil takes about 7 minutes
- to download the few files that are found. It
- spends about 5 of those 7 minutes waiting for
- LIST data for empty directories, due to the 15
- second delay.
- Author's notes : I have reduced the delay to 5 seconds, hoping
- that it will not be too short.
-
- Type : Bug
- Fixed in : 1.10.004
- Fixed on : 16-10-98
- Reported by : Gary Gilmore
- Reported on : 16-10-98
- Short description : The default location on an 800x600 screen is not correct
- Long description : The default location on an 800x600 of the WebUtil
- screen is off to the right, such that only the
- left half of the WebUtil screen is visible.
-
- Type : Bug
- Fixed in : 1.10.003
- Fixed on : 28-08-98
- Reported by : Darryl Gregorash
- Reported on : 25-08-98
- Short description : A "LIST" command always results in a 15 second delay
- Author's notes : It was possible for this to occur if the 226
- response took longer than 15 seconds to be
- received. What WEBUTIL will now do is wait up to
- 15 seconds for the first data to arrive. Then it
- will read the data out and also check the status
- of the control channel. If there is no more data
- to read, and the 226 response has been received,
- it will assume that the LIST data has been
- received in full.
-
- Type : Bug
- Fixed in : 1.10.002
- Fixed on : 17-08-98
- Reported by : Darryl Gregorash
- Reported on : 15-08-98
- Short description : Unusually large delay in performing the LIST command
- Long description : Darryl reports:
-
- "There is an excessive delay between
- acknowledging the "150" response and
- the "226" response to a LIST command.
-
- 15-08-98 02:15:38 TCP/IP debug log
- 15-08-98 02:15:38
- --------------------------------------------------
- ---------
- 15-08-98 02:15:38 R 220 nwstar.com FTP server
- (PowerWeb version 4.04r6)
- ready.
- 15-08-98 02:15:38 S USER 140.101
- 15-08-98 02:15:38 R 331 Password required for
- 140.101
- [snip]
- 15-08-98 02:15:40 R 227 Entering Passive Mode
- (207,195,92,151,15,206)
- 15-08-98 02:15:40 S LIST
- 15-08-98 02:15:40 R 150 Opening ASCII mode data
- connection for /bin/ls
- 15-08-98 02:17:40 R 226 Transfer complete.
- [snip]
-
- I was watching this in PMLM, the SIO line
- monitor, and the two server
- responses arrived within fractions of a second of
- each other;
- nevertheless, WU needed 2 full minutes to
- understand that the "transfer
- complete" response had arrived."
- Author's notes : It is necessary to wait a short delay after
- giving the LIST command. I have found that the
- 226 response can come back really quickly, even
- though the data has not been received yet. In
- build 1, the WebUtil would wait up to 2 minutes
- for the data to arrive. If the results of the
- LIST is empty, then that means WebUtil would wait
- the full 2 minutes before aborting the LIST. I
- have reduced that delay to 15 seconds. I feel
- that this is a good tradeoff between reliability
- and usability.
-
- Type : Bug
- Fixed in : 1.10.002
- Fixed on : 17-08-98
- Reported by : Scott Brown
- Reported on : 17-08-98
- Short description : Screen display incorrect in 50 line mode
-
- Type : Bug
- Fixed in : 1.10.001
- Fixed on : 14-08-98
- Reported by : Harald Harms
- Reported on : 21-07-98
- Short description : Reinitialize the socket when retrying an FTP login
- Long description : Retrying a connection does not always work
- properly. The function exits almost immediately.
- Reinitializing the entire socket might be the
- only way to fix this.
-
- Type : Bug
- Fixed in : 1.10.001
- Fixed on : 14-08-98
- Reported by : Darryl Gregorash
- Reported on : 30-07-98
- Short description : Connection made and then broken
- Long description : Darryl reports:
-
- "Everything has been running very well except for
- one instance of this:
-
- 23-07-98 07:45:32 Processing task NEC140
- 23-07-98 07:45:32 Establishing connection
- 23-07-98 07:45:32 Connection established with
- ftp.nwstar.com
- 23-07-98 07:47:32 Unable to establish connection
- with ftp.nwstar.com
- 23-07-98 07:47:36 Establishing connection (try 2)
- 23-07-98 07:47:36 Connection established with
- ftp.nwstar.com
- 23-07-98 07:47:36 Unable to establish connection
- with ftp.nwstar.com
- 23-07-98 07:47:38 Establishing connection (try 3)
- 23-07-98 07:47:38 Connection established with
- ftp.nwstar.com
- 23-07-98 07:47:38 Unable to establish connection
- with ftp.nwstar.com
- 23-07-98 07:47:42 Establishing connection (try 4)
- 23-07-98 07:47:42 Connection established with
- ftp.nwstar.com
- 23-07-98 07:47:42 Unable to establish connection
- with ftp.nwstar.com
- 23-07-98 07:47:44 Establishing connection (try 5)
- 23-07-98 07:47:44 Connection established with
- ftp.nwstar.com
- 23-07-98 07:47:44 Unable to establish connection
- with ftp.nwstar.com
- 23-07-98 07:47:48 Processing task RC17
-
- Perhaps the logged times are innacurate, as it
- seems unlikely that WU
- should attempt the connection, discover that it
- was established, and
- then for some reason claim that it was not
- established, all in the space
- of less than a second."
- Author's notes : What is going wrong is that a socket connection
- has been made with the server, however, the
- server can not accept the connection. WebUtil
- reports that the connection has been made, but
- when checking the result code, it finds that it
- can not continue, and therefore, reports unable
- to establish connection.
-
- Nothing really wrong here, except that the
- "Connection established" message should be
- displayed after checking the result code, and not
- before.
-
- Type : Bug
- Fixed in : 1.10.001
- Fixed on : 14-08-98
- Reported by : Harald Harms
- Reported on : 14-08-98
- Short description : LIST routines sometimes did not wait for data
- Long description : The LIST routines which are used to get a list of
- the files on the FTP site sometimes did not wait
- for data, before aborting. The routines will now
- wait up to 2 minutes for the server to start
- sending data.
-
- Type : Request for change
- Fixed in : 1.10.006
- Fixed on : 04-01-99
- Reported by : Scott Brown
- Reported on : 27-12-98
- Short description : Set an error level when one or more files has been downloaded
- Author's notes : WebUtil will exit with the following errorlevels:
-
- 0 - no files downloaded nor uploaded
- 1 - 1 or more files downloaded via HTTP or FTP
- 2 - 1 or more files uploaded via HTTP or FTP
- 3 - 1 or more files uploaded and 1 or more
- files downloaded via HTTP or FTP.
-
- This particular feature is not available in the
- Windows version!
-
- Type : Request for change
- Fixed in : 1.10.005
- Fixed on : 23-10-98
- Reported by : Dallas Hinton
- Reported on : 21-10-98
- Short description : Add warnings for unavailable features to log file
- Long description : Dallas reports:
-
- "BTW, could you arrange for the log to show that
- a file was not auto-deleted
- because of non-registration? At the moment,
- there's nothing to show that -- it
- looks as if the files *were* deleted. Thanks!?"
-
- Type : Request for change
- Fixed in : 1.10.004
- Fixed on : 12-10-98
- Reported by : Bob Seaborn, Scott Brown
- Reported on : 25-08-98
- Short description : Add a user definable delay to the FTP transfers
- Author's notes : The delay that WebUtil waits for the LIST results
- has been made user definable with a optional
- verb, namely LIST_DELAY, which can be specified
- for each FTP block. The default value is 15
- seconds and you can NOT specify a value less than
- that (since that will most likely only cause
- problems and I want to protect you from yourself
- (yes You Scott ;-)).
-
- Type : Request for change
- Fixed in : 1.10.004
- Fixed on : 09-10-98
- Reported by : Scott Drake
- Reported on : 06-10-98
- Short description : Offer the ability to designate alternative FTP and HTTP ports
- Long description : You can use the PORT verb in the INI file to
- specify alternative port numbers for each HTTP or
- FTP sites. The default values are 80 and 21,
- respectively. This verb is not required.
-
- Type : Request for change
- Fixed in : 1.10.004
- Fixed on : 09-10-98
- Reported by : Scott Brown
- Reported on : 07-10-98
- Short description : Assume .INI if no extension is specified for alternative INI files on the commandline
-
- Type : Request for change
- Fixed in : 1.10.004
- Fixed on : 12-10-98
- Reported by : Darryl Gregorash
- Reported on : 11-10-98
- Short description : Retry a put or get action if a data channel could not be established.
- Author's notes : WebUtil will try to set up a data connection
- three times. I have not been able to test this
- out, because, as you will understand, nothing
- goes wrong when you try testing ;-) In other
- words, no attempts to establish a data session
- failed ;-)
-
- One other note: performing a LIST on the server
- also requires setting up a data connection.
- WebUtil will also retry that 3 times, if
- necessary.
-
- Type : Request for change
- Fixed in : 1.10.001
- Fixed on : 14-08-98
- Reported by : Darryl Gregorash
- Reported on : 21-07-98
- Short description : Make the login retry delay (FTP) user definable
- Long description : A new verb has been added, namely, RETRY_DELAY,
- which can be used to specify the number of
- seconds that WebUtil should wait before
- attempting to make another connection.
-
- Type : Request for change
- Fixed in : 1.10.001
- Fixed on : 14-08-98
- Reported by : Darryl Gregorash, Bob Seaborn
- Reported on : 21-07-98
- Short description : Make it possible to log all of the server responses and all commands to the servers
- Author's notes : A new verb has been added, namely, DEBUG_LOG
- which can be added to the [MAIN] block. The debug
- log contains all the commands sent to and
- received from the server. The commands sent are
- preceeded with the letter 'S' and the commands
- received are preceeded with the letter 'R'.
-
- Type : Request for change
- Fixed in : 1.10.001
- Fixed on : 14-08-98
- Reported by : Bob Seaborn
- Reported on : 21-07-98
- Short description : Utilize more of the screen so that the user can better see what is going on
-
- Type : Request for change
- Fixed in : 1.10.001
- Fixed on : 14-08-98
- Reported by : Bob Seaborn
- Reported on : 05-08-98
- Short description : Offer the ability to specify IP addresses instead of URL's
- Author's notes : You can now specify an IP address instead of a
- URL for both the HTTP and the FTP URLs.
-
- --------------------------------------------------------------------------------
- 31 items
-
- Leave
- --------------------------------------------------------------------------------
- Type : Bug
- Fixed in : 1.10.007
- Fixed on : 15-01-99
- Reported by : Ben Hamilton <Ben.Hamilton@compconn.net>
- Reported on : 24-11-98
- Short description : Problem uploading zero byte semaphore file
- Author's notes : Unable to reproduce this problem due to other
- problems with the ftp server.
-
- --------------------------------------------------------------------------------
- 1 items
-
- New
- --------------------------------------------------------------------------------
- Type : Bug
- Fixed in : 1.10.
- Fixed on :
- Reported by : Fransisco Romero
- Reported on : 07-01-99
- Short description : The positioning of WebUtil should be changed.
- Long description : The ability to synchronize directories should be
- emphasized along with the easy of use. Right now
- it looks like "just another" web gathering tool.
-
- Type : Bug
- Fixed in : 1.10.
- Fixed on :
- Reported by : Harald Harms
- Reported on : 15-01-99
- Short description : Design an icon for the Windows version of WebUtil
-
- --------------------------------------------------------------------------------
- 2 items
-