In article <44**********************@news.optusnet.com.au>,
ma***@healey.com.au writes...
I am curious about why are you having to mess with a proxy at all?
I thought your client app would specify a web address, for either a web
page or a web service, and make its request. If there is some proxy-stuff
going on behind the scenes to get you connected to that address, so what?
If one of the users enters www.google.com in a browser, presumably they
get taken to that site, regardless of the hoops in between. How is your
app different?
I would actually like to know, since I am embarking on some corporate web
development, and may be running through proxies in some cases.
This also interests me as that is ment to be one of the big features of
.Net. I had lots of trouble trying to use the Internet transfer controll in
VB6
to get data to or from a web server when ever a proxy got involved. I spent
hours in the late 90's working out the WinInet API to get it to do as you
suggest.
I have moved to 2005 for new stuff that I am working on but have not had to
do any web services yet, I just assumed all that stuff was sorted out.
I found www.vbip.com the best place for all this stuff.
Thanks for the link Max.
As to proxy and autoproxy, it is relevant to all flavours of VB, its
just a bit harder with VB.NET because you can't just bring in a COM
object to help.
Heres a quick synopsis of proxy:
Direct connection: exactly what it says. If your VB app needs to access
a URL it connects to the server directly and gets it. This isn't really
a problem for the home user or small office with a few workstations, but
it can result in unnecessary multiple downloads of the same file in a
larger setup. Imagine a small group of, say, 5 stockbrokers in an office
sharing a single 128kb/s ISDN feed. Every morning at 9am they all look
at the stock exchange home page to see the market news. Without proxy it
will take 5 times as long as it should to retrieve the page as all 5 of
them will be trying to pull it down the 128k feed at the same time.
Hard-coded proxy: all URLs are downloaded from the same proxy server.
This helps eliminate the problem of multiple downloads. With a proxy
server in the office the file would be pulled down the slow 128k link
once, stored in a cache, and shared out among the 5 brokers at 10, 100
or 1000Mb/s. In a small to medium site a single hard-coded proxy address
is OK, but in large operations (mine has 100,000 users or more in it) a
single proxy server would itself become a bottleneck. With a hard-coded
proxy the address and port of the proxy server are recorded in the
registry.
Autoproxy: Instead of recording an address and port for a proxy server
in the registry, the URL of a file that contains advanced proxy
information is recorded. There is often no actual proxy address or port
available in the registry. Instead a javascript file, usually named
autoproxy.pac, is automatically downloaded the first time a URL is
requested. The FindProxyForURL() method is called in this javascript
with the desired URL as a parameter and it returns the correct proxy
address and port to use with that URL. This allows multiple proxy
servers to be run by the organisation, each optimised for a particular
kind of information. For URLs inside the local Intranet DIRECT might be
returned by FindProxyForURL(), allowing for direct access to files that
do not have to be retrieved over slow links. Information from different
departments might be obtained from that department's own proxy server
while Internet files may be obtained through one or more proxy servers
shared by the whole organisation.
My own organisation has hundreds of thousands of users, thousands of
sites and dozens of departmental Intranets. It is a very big site, but
fairly typical of very large multinational companies. Because of the
size and complexity of the organisation autoproxy is used on nearly all
workstations.
An added advantage of proxy servers is they can be set up to require
authentication. That means people inside an organisation have no trouble
accessing local files directly, but a username and password is needed
before they can access files on the Internet, or perhaps files from
other departments. This can have immense productivity implications, both
positive and negative.
If you are a person who only uses Internet Explorer, proxy and autoproxy
are magical background helpers that speed your data flow.
If you are a programmer, proxy and autoproxy are industrial grade
headaches that stop your application getting to the data it needs
without a lot of extra work.
The trick is finding out what kind of proxy system is in use, if any,
and tailoring the data access accordingly.
Direct connection: no worries. It just works.
Hard-coded proxy is a little harder: you can find details of the hard-
coded proxy address and port in the registry under
HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Internet
Settings]
"ProxyEnable"=dword:00000001
"ProxyServer"="Proxy.Mycompany.com:8080"
VB has ways of obtaining this information from the registry, so its just
a matter of reading it and using information with your objects as Jan
suggested.
Autoproxy is harder still. There is often no hard-coded proxy server or
port at all in the registry, instead the location of the autoproxy
script is available:
[HKEY_CURRENT_USER\Software\Microsoft\Windows\Curre ntVersion\Internet
Settings]
AutoConfigProxy=wininet.dll
AutoConfigURL=http://autoproxy.mycompany.com
Knowing WHERE the information lives is useful, but it is up to YOU the
programmer to parse the autoproxy.pac file that lives there for each URL
and set up a proxy on your objects accordingly.
A complicating factor is that a proxy server often requires
authentication details. Internet Explorer simply pops up a
username/password dialog when this occurs. Your program will have to
deal with this situation automatically.
So your program may need to detect the kind of proxy in use and act
accordingly. In the "worst case" it may need to parse a javascript file
to determine the appropriate proxy server and deal with user
authentication when it connects.
Oh, and just to cap it off, the information in the autoproxy.pac file
may change from access to access. Suppose a proxy server goes down for
maintenance or fails. The network administrator can change the data flow
throughout the organisation simply by changing a single line in
autoproxy.pac. Ideally your program has to be able to deal with a
dynamic network environment, detect failures, reload autoproxy.pac and
reconfigure proxy on its objects accordingly. Second place goes to the
program that crashes and has to be restarted to reload up to date proxy
information when a network reconfiguration occurs.
I hope this helps some people get to grips with proxy and autoproxy.
I've tried to keep my discussion generic so it will apply to all
flavours of VB. Have a great day everyone.
--
DM
personal opinion only