WsDmur.ocx - is written by me for update on my external WEB/FTP the server... Also will allow you download small files through http-proxy:8080, and to do it from the own programs! OCX is created by means MS VC 6.0 MFC SP5 and writing by using Winsock 2.2 API (see in MSDN) in asynchronous mode.

Features/Rrestrictions:
    - Update (i.e. the http-command PUT) (usual on the FTP-server) can be updated for files, which size does not exceed 1MB.
Example of a command: PUT ftp://uid:pwd@ftp.narod.ru/download/temp.zip
    - Downloads (i.e. the http-command GET) can is made from FTP and HTTP servers and  the size of files is limited 2,147,483,647 bytes, and in case loss of connections on the server, the attempts continue downloading can be made, if it's supported by servers certainly.
Example of a command: GET http://vfpdmur.narod.ru/download/wsdmur.zip
    - The port 21 (i.e. pure FTP) is not supported now, only HTTP/1.0 on ports: 80 or port for http-proxy
   - Authorizing neither on http-proxy nor on the server in ocx is not supported immediately, and in the present moment it is possible, as through inclusion in command (see example of a command PUT above), and with use of significance of a property, HeaderEx (see in section 'Properties' below), thus you can support it in the calling program according to your needs.
   - The Redirect in ocx is not supported also, however, as http-StatusCode (GetStatusCode ()), and returned datas (GetData ()) are accessible to you,  thus it can organize by you in the calling program.

Thus, I wrote it extremely under my conditions, and personally it works for me!

The brief description of the interface:
Methods:
BSTR LocalHostName() - returns a name of the local machine
BSTR LocalIP() - returns IP-address of the local machine 
BSTR RemoteHostIP() - returns IP-address of the remote server
BSTR GetData() - returns a portion of obtained datas
Long TotalBytesRecieved() - returns length of all obtained datas
Long SendData(BSTR Data) - sends a command on the server
Long ContentLength() - returns general(common) length of an obtained investment
EnumWsStates State() - returns a current state (see below)
long GetStatusCode() - returns StatusCode http-protocol (see "HTTP 1.0 Status Codes and Reason Phrases" in MSDN), if undefined, - 0
BOOL Stop() - send message FD_CLOSE to socket
Void AboutBox() - call the dialogue about the author OCX

Properties:
BSTR RemoteHost - name of the remote server. If the RemoteHost contains points, it is meant, that in a format of IP-address
Long RemotePort - port of connection to the remote server
Long LocalPort - local port, if not is given (i.e. 0), the port 1251 is used (in case client is not used)
BSTR LogFile - if is indicated, the protocol of events is output
BSTR FileName - if is indicated, the source file for command PUT meens, and the output file for command GET
BSTR HeaderEx -  if has value, will be added into http-header at once after a command. Can be used, for example for adding a line: "Proxy-authorization: basic UID:PWD" or other, parameters, not taken into account by me. If the significance of this property consists of several lines, an indication of a new line is the sequence of "\r\n", however end of the last line should not be "\r\n". Pay attention, that in case of adding a property Proxy-authorization, UID:PWD must be in coding in Base64, however in wsDmur.ocx not made any code conversions, therefore, in this case it will be necessary to use advantage of any external utility realizing similar code conversion. For example, on http://www.planet-source-code.com/xq/ASP/txtCodeId.1710/lngWId.3/qx/vb/scripts/ShowCode.htm by Yoni
see also http://www.rfc-editor.org/rfc/rfc2617.txt 

Events:
Void StateChanged() - arises on modification of a property State() (more correct method :-)
Void SendProgress(long bytesSent, long bytesRemaining) - arises on sending of the block of datas to the server
Void DataArrival(long bytesReceived, long lenHeader, long UpLoadCount) - arises on deriving of the block of datas by the client

typedef enum tagWsStates
{
	wsClosed			= 0,
	wsSetuping		= 1,
	wsListening		= 2,
	wsResolvingHost		= 3,
	wsHostResolved		= 4,
	wsConnectionPending	= 5,
	wsConnected		= 6,
	wsPreparationSending	= 7,
	wsSending		= 8,
	wsWaitingResponse		= 9,
	wsUnexpectedDisconnection	= 10,
	wsClosing		= 11,
	wsError			= 12,
} enumWsStates;

The "top" list of used dll:
Ws2_32.dll
Mfc42.dll
Msvcrt.dll
Kernel32.dll
User32.dll
Gui32.dll
Shell32.dll
Oleout32.dll
Msvcp60.dll

As addition you can download a code examples of use from
Http://vfpdmur.narod.ru/util_r.html :

wsdmurb.zip - VB
wsdmurf.zip - VFP
wsdmurc.zip - VC MFC
wsdmura.zip - VC ATL 

All 6.0 ver. + SP5 VS6

In a local network, as the example, calling may be such:
RemoteHost - LocalHost
RemotePort - 80
SendData ("GET /")
---
Detected problems of version 1,0,0,1 and fixed in version 2,0,0,1:

- Because of my fallacies, that the port 8080 is fixed for proxy, in the former version 1,0,0,1 it was rigidly registered in a code OCX
- As has appeared, in a case when in the first received http-header we have: Proxy-Connection: close and if is absent Content-Length an event FD_CLOSE can come from the proxy-server completely arbitrary... And irrespective of an amount of reading datas on obtained events FD_READ :-( In the present moment, on deriving an event FD_CLOSE the cycle "forced" reading of datas from the proxy-server is made, while the not empty block of sent datas will not be read yet, then socket is closed (you see we have received an event with a request FD_CLOSE). Such behaviour like allows to read all sent datas.

---
Detected problem of version 2,0,0,1:

However behaviour above results to a new problem, which consists that already after closing socket I nevertheless receive a portion of events FD_READ from the server, which actually I already have finished, that calls emerging in the log-file of events of a series of the messages of a type:

*** nnn FD_READ
*** Unexpected message FD_READ with empty lpSocketInfo
*** nnn FD_CLOSE
*** Unexpected message FD_CLOSE with empty lpSocketInfo

 I can not suppress writing to the log-file of the similar messages, as they can be caused also by other reasons :-( Is shorter, I think on it it is possible to not pay attention. Something reasonable solution I have not found yet : - (

---
About modifications in version 2,0,0,2:

After some meditations I have come to a conclusion, that the messages of a type "Unexpected message FD_READ/FD_CLOSE with empty lpSocketInfo" can be interesting only to developer. Besides I think, that it is all a feature proxy-server Squid/2.3. STABLE4, which I use (to check up on other servers there is no possibility at me)  ...That is why, by entering an internal logic variable has made output the similar messages to LogFile of events by conditional (by default is prohibited). However, it's possible determine that a similar situation has arisen by viewing a list of events in LogFile: in this case, after emerging an event FD_CLOSE follows a series of events FD_READ, which has really read datas from the server.

---
In version 2,0,0,3:

The problem connected with the outcome file (FileName and command GET) was closed after a modification of the State() on wsClosing or wsError, as result - difficulty of determination of a moment of a beginning of a possibility of work with the completely generated file of obtained datas. In version 2,0,0,3 the closing of the indicated file is made before the modification of a State() condition on wsClosing or wsError.

---
In version 2,0,0,4:

Is added the method long GetStatusCode () - returns StatusCode (see "HTTP 1.0 Status Codes and Reason Phrases" in MSDN)... I do not know why... but I really has missed it earlier.
...At last reliably to force http-proxy not use cache in a http-header the line is added:
"Pragma: no-cache"
Huge special thank Vasily V. Moshninov for the help, as to struggle with it!

---
In version 2,0,0,6:
- Is added property BSTR HeaderEx -  if has value, will be added into http-header at once after a command. Can be used, for example for adding a line: "Proxy-authorization: basic UID:PWD" or other, parameters, not taken into account by me.  
- Is added method - BOOL Stop() - send message FD_CLOSE to socket

---
In version 2,0,0,7 (12/31/2003) - the large number of essential changes was made to use wsDmur.ocx for remote access in network through modem/ISDN (including often breakaways of connections to a server):

- In a method SendData() the optional second BOOL continueDownload parameter is added to continue loading any file from its current state on the client. I.e. in the present moment the prototype of this method the following: long SendData (LPCTSTR Data, BOOL continueDownload = FALSE)
- The method BOOL Stop() witch was added in version 2,0,0,6 did not work unfortunately, right now it's works. Together with the new continueDownload parameter in a method SendData(), with value continueDownload = TRUE, has become possible to suspend/continue downloading at your option.
- Up to version 2,0,0,7 at a breakaway of connection with a server only one attempt of recovery connection and continuation of downloading was produced. In case of the remote connection through modem/ISDN it as a matter of fact did not work. In the present version a lot of improvements is entered. Below the list of changes:

Properties:
- long MaxRecoveryConnect - The maximum count of repeated attempts of connections in case of breakaway (if 0 any attempts of repeated connections not make, and the execution stops)
- long TimeOutRecoveryConnect - time interval (in milliseconds) waiting before each subsequent repeated attempt of connection  is made in case of breakaway connection (in case MaxRecoveryConnect > 0 only)
- VARIANT_BOOL ShowErrMsg - flag of output the dialog-message by means ocx in case of any errors. If this value is fase, any dialog-messages about errors does not arise. In this case, the handle of state of loading is laid completely to the program, which use ocx, i.e. on control event StateChanged() and analysis of a status obtained through the method enumWsStates State().
- In enum enumWsStates the new state wsWaitingRecoveryConnect = 13 is added, arise before each attempt of recovery connection (at beginning waiting of time TimeOutRecoveryConnect for the subsequent attempt of connection)

Methods:
- The second parameter for a method long SendData([in] BSTR Data, [in, defaultvalue (VARIANT_FALSE)] VARIANT_BOOL continueDownload) is added, it allows to fulfil downloading any file "from current size" on the client, i.e. make starting "from byte, not loaded from a server yet", and the execution time of such repeated attempt completely depends only on your desires :-) 
- The method VARIANT_BOOL GetErrorInfo([out] long* errCode, [out] BSTR* errMsg), allows to receive the errorcode/errormessage of last WinSocket-error which has arisen in the time of use ocx.
- method VARIANT_BOOL Stop() now works (because of replace type boolean, inserted by MFC-wizard instead of required type VARIANT_BOOL)
- long GetInitialFileLength() - in case continueDownload=TRUE, return initial length of clients file in bytes (-1 if not defined).

Pay attention! The introduction of additional possibilities has complicated the code of ocx-client slightly, therefore I advise to view code-examples in detailed, which can be downloaded from my site: http://vfpdev.narod.ru/util_e.html and just for version 2,0,0,7

It is necessary also to mark, that right now I have not possibility to test job of version 2,0,0,7 on upload through http-proxy server (initially this of ocx was written for upload/download of files through proxy-server Squid/2.3. STABLE4)... I certainly tried anything "to not spoil" from previous, however I'm not sure, that for me it was received. Therefore I recommend to use version 2,0,0,7 on download (for not upload) through the http-protocol only...

As I hope, the series of last changes will allow you to write yours "really operable/reliable" programs for downloading of files through http-protocol! :-) 

Best regards.
Michael Drozdov, ICS Soft, Perm, Russia
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mailto:Drozdov@ics.perm.su
My Page:  http://vfpdmur.narod.ru/
ICS Page: http://ics.perm.ru/ [on Russian]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~