In our organization, we have hundreds of proxies and over 20 pac files. I am intending on running RMA on a group of remote systems, and want to monitor pac file download times. As HTTP is not supported on RMA, I have to use the URL test.
For the URL test, I am specifying:
Service: HTTP
Server: 10.10.10.10
Port : 8000
Path file : http://proxy.abc.com:8000
It was failing, so I captured it with Wireshark. I found the following:
GET /http://proxy.abc.com:8000
It works fine with the HTTP test method, because the GET request appears to be formulated differently. After the TCP connect I see:
GET http://proxy.abc.com:8000
1) How do I get rid of this "/" between the get and the path?
2) Also, are there any plans to allow the URL test to utilize the proxies.lst. This is hurting me as well, because I want to test URLs through different proxies. Is there a workaround?
Issue with URL Testing of proxy autoconfig
Path file : http://proxy.abc.com:8000 ?
Actually proxy.abc.com should be specified in "Server" field.
8000 should be put in Port field.
Path/File should be empty.
Then HostMonitor will use URL http://proxy.abc.com:8000
Slash before URL should not be sent...
What Windows do you use?
Service Pack? Internet Explorer?
HostMonitor version? RMA?
H'm, HTTP test allows you to use different proxies for the same URL but if you need to use agent for this, then you need 2 agents. Or we need to implement HTTP test for RMA...
Regards
Alex
Actually proxy.abc.com should be specified in "Server" field.
8000 should be put in Port field.
Path/File should be empty.
Then HostMonitor will use URL http://proxy.abc.com:8000
Slash before URL should not be sent...
What Windows do you use?
Service Pack? Internet Explorer?
HostMonitor version? RMA?
through different proxies using the same RMA? without using HostMonitor?Also, are there any plans to allow the URL test to utilize the proxies.lst. This is hurting me as well, because I want to test URLs through different proxies. Is there a workaround?
H'm, HTTP test allows you to use different proxies for the same URL but if you need to use agent for this, then you need 2 agents. Or we need to implement HTTP test for RMA...
Regards
Alex
If I just specify the pac file for the server and port, I won't be testing the download of the pac through a given proxy server. I will be testing from any one of a group of load balanced proxy servers. I want to be more deterministic in my testing. In addition, our pac files are downloaded from different places on the network (through the proxy) and then delivered to the client. I want to ensure that there are no issues in this particular leg of the process.
I did get it working with the HTTP test. To be able to download a pac file from a specific proxy (for the HTTP test), I specify the proxy from my proxies.lst file. As you can imagine I have quite a few server/port entried in there. For the URL, I use the value that would be found in the automatic configuration script entry of the browser, which in this particular case is http://proxy.abc.com:8000 - obviously, I sanitized this value
.
So, when I set up the URL test, I do have the server as the specific proxy that I want to download the pac file through, as well as the port (8000). For the Path/file, I have http://proxy.abc.com:8000. Using what I have below, "almost" produces the same result as the HTTP test, with the exception that URL test throws in the "/" after the "GET". This causes the proxy to return a 400 code. If I could get rid of the "/", I would probably be OK.
This is running on VMWARE/WIndows Server 2003 R2, 64 bit, service pack 2. Gulp.... It has IE6... However, I seem to get the same results with Win7 and IE8.
Yeah, I would like to be able to test through different proxies with the RMA for direct/through proxy testing to a URL such as Google. Since we have a pool of proxies, I would like to be able to measure each one individually. I really wish that the HTTP test was available for RMA.
I did get it working with the HTTP test. To be able to download a pac file from a specific proxy (for the HTTP test), I specify the proxy from my proxies.lst file. As you can imagine I have quite a few server/port entried in there. For the URL, I use the value that would be found in the automatic configuration script entry of the browser, which in this particular case is http://proxy.abc.com:8000 - obviously, I sanitized this value
.So, when I set up the URL test, I do have the server as the specific proxy that I want to download the pac file through, as well as the port (8000). For the Path/file, I have http://proxy.abc.com:8000. Using what I have below, "almost" produces the same result as the HTTP test, with the exception that URL test throws in the "/" after the "GET". This causes the proxy to return a 400 code. If I could get rid of the "/", I would probably be OK.
This is running on VMWARE/WIndows Server 2003 R2, 64 bit, service pack 2. Gulp.... It has IE6... However, I seem to get the same results with Win7 and IE8.
Yeah, I would like to be able to test through different proxies with the RMA for direct/through proxy testing to a URL such as Google. Since we have a pool of proxies, I would like to be able to measure each one individually. I really wish that the HTTP test was available for RMA.
I am thinking that if I could somehow eliminate the "/", I would be able to test through proxies to external URLs. It would most likely be a way of being able to use different proxies through the URL test (thereby overcoming the limitation of having to use the system wide registry setting or named proxy, etc). Granted, this might not work for HTTPS Connect, etc. but it would still be very helpful for my needs.
Right now, I am trying to experiment with WGET, but the most recent Windows build does not support the proxy parameter and relies on a system level variable. While this works when one test is run, it can create a huge issue if mutliple tests are run simultaneously. It isn't scalable.
Right now, I am trying to experiment with WGET, but the most recent Windows build does not support the proxy parameter and relies on a system level variable. While this works when one test is run, it can create a huge issue if mutliple tests are run simultaneously. It isn't scalable.
Oh, I see.So, when I set up the URL test, I do have the server as the specific proxy that I want to download the pac file through, as well as the port (8000). For the Path/file, I have http://proxy.abc.com:8000. Using what I have below, "almost" produces the same result as the HTTP test, with the exception that URL test throws in the "/" after the "GET". This causes the proxy to return a 400 code. If I could get rid of the "/", I would probably be OK
Theoretically we can change this but such modification may lead to problems for other customers that use URL tests for long time. Not sure what solution will be good for everybody
May be we can check for "http://" string within path...
Regards
Alex
Long term, I am wondering whether this behavior could be something that could be toggled on/off in the .ini (URL options). Maybe the default option is to place a "/" for the URL test to maintain backwards compatibility. If someone were to turn this setting off, they could still put a "/" in the Path string to behave in this manner.
Anyway, if you have any short term suggestions or thoughts, I would greatly appreciate it.
Thanks,
Tom
Anyway, if you have any short term suggestions or thoughts, I would greatly appreciate it.
Thanks,
Tom
You may try this update: www.ks-soft.net/download/hm913d.zip
Please check your license using menu Help->Update check, update to official release 9.12 then download 913d ("special version just for you"), unzip files and replace hostmon.exe and rcc.exe modules
Regards
Alex
Please check your license using menu Help->Update check, update to official release 9.12 then download 913d ("special version just for you"), unzip files and replace hostmon.exe and rcc.exe modules
Regards
Alex
