I tried using SOCKS4 and SOCKS5 protocols, and they all fail, too. Not sure what else I can do as far as configuring VisualCron.

Thanks for the feedback. We are still testing this and will get back to you soon.

---

OK, thanks. I await with bated breath. :-)

Rebeccah

Rebecca,

we did try various proxies with success. We would like you to do the same test as our test but as you probable *have to use* your proxy the test might not work for you.

We tested with a software proxy:

http://www.canpub.com/teammpg/de/proxyde1/ 

We downloaded and used the following parameters:

proxy_11 -t 2000 localhost 80

We changed the HTTP Task to use HTTP Proxy and port 2000.

---

I will play with this software proxy a bit, but in the meanwhile:
It looks like the two main differences between IE and VisualCron as a client, are:
IE uses HTTP 1.0 and the Proxy-Connection header value Keep-Alive
VC uses HTTP 1.1 and the Proxy-Connection header value Close

According to what I'm finding while researching this, the Proxy-Connection header is *not* standards-compliant, and not all servers support it.

http://homepages.tesco.n...y-connection-header.html 
"its existence imposes a requirement upon HTTP servers such that no proxy HTTP server can be standards-conforming in practice"
"By default, an HTTP version 1.0 connection is non-persistent and an HTTP version 1.1 connection is persistent. The Proxy-Connection: header is intended as a mechanism for negotiating the non-default behaviour:
A client using HTTP 1.0 to talk to a proxy server can send Proxy-Connection: keep-alive in a request message to request that the server treat the connection as a persistent connection, if it is capable of doing so.
...
Note that this is faulty protocol design that is prone to error, as RFC 2616 § 19.6.2 explains. The client cannot know that a proxy server that only understands HTTP 1.0 will not simply pass the header through, and thus cannot know that the header will be processed by the immediately downstream server (where it needs to be processed in order for connection negotiation to work).

A client using HTTP 1.1 to talk to a proxy server can send Proxy-Connection: close in a request message to inform the server that it will be closing the connection after this transaction. "

....

"The consequence of this is that, despite the fact that it is contrary to RFC 2616 § 4.5, proxy servers must treat the Proxy-Connection: header not as an entity header, but as a general header. In HTTP 1.1 requests, they must treat it as they would treat the Connection: header; and in HTTP 1.0 and earlier requests, they must ignore it and throw it away. Neither is how they would treat an entity header. "

It may be that the proxy servers you have been testing with are RFC 2616 § 4.5-compliant, and pass the Proxy-Connection: header through as an entity header, whereas our proxy server treats it like a Connection: general header.

According to this web page: http://www.http-stats.com/Proxy-Connection 
Only the following servers return the Proxy-Connection header:
Microsoft-IIS
squid
Apache
Mikrotik HttpProxy
Asroc Intelligent Security Filter 4.1.8
BigIP
IS
MuseProxy

So, while I'm playing with the proxy server that you have pointed me to, perhaps you could get your hands on one of these to test with? Unfortunately, the article doesn't state which servers not only return the header, but also treat it like a Connection: header to modify the default behavior of the HTTP 1.0 vs 1.1 connection.

I'm thinking the simplest thing in the end would be to have an additional configuration option in your Proxy settings, where the user can specify whether or not to set a Proxy-Connection: header value, and if so, what the value should be (Keep-Alive or Close).

Rebeccah

Maybe I'm missing something, but in this proxy application I don't see any way to configure authentication.

Rebeccah

OK, I've had it. I've tried several proxy servers, but our corporate security settings won't let me install (most of) them or use (any of) them. I can't get the browser on the computer in question to connect to any of them AT ALL, whether installed locally or on another computer in the domain. It has to connect to our corporate proxy server.

If it is of any help, our corporate proxy server is doing NTLM authentication. If you haven't tried testing VisualCron's proxy connection capabilities against 3proxy, I suggest you do - it is free, small (command-line), and will do NTLM authentication. http://www.3proxy.ru/  It's a SourceForge project. That said, I still don't know how it handles the Proxy-Connection: header.

Caution: Some antivirus programs will detect it as a trojan, because I guess malware users find it easy to integrate into their back doors. The AV on our server won't let me install it, but on my laptop it will (IE on my laptop is also permitted to connect to a localhost proxy server, whereas on the server it is not).

Rebeccah

It also occurs to me that perhaps I may have to have a user-agent of IE to be able to connect to our proxy server. I can't remember whether or not VisualCron offers an option to specify the user-agent.

Rebeccah

Finally found a proxy server I can install on my machine - cntml.

And after a lot of trial and error, and then retrying the things I did before without the proxy server, I realize a couple of things:

1. My original thought was right, that it's my web server that was denying authorization because of the user being IUSR_TEMPLATE
2. My subsequent thought of not getting through the corporate proxy server was wrong. I though this because I saw the client-server communication end after one request and response, but didn't quite grasp that the corporate proxy server NTLM challenge and response was then happening with the *next* connection.
3. I have subsequently found out that NTLM authentication at the web server level isn't supposed to work through a proxy server, because it's a one-hop, connection-specific authentication.
4. Which brings up the question of how IE manages to get through OK, with popup prompts for credentials?
5. And furthermore, why am I in fact successfully logging on to my web server as IUSR_TEMPLATE?

If, indeed, our corporate proxy server is MS ISA, do it and IE take advantage of some proprietary understanding of each other? So that the proxy server actually logs onto the remote web server (IIS) using NTLM? But how does IE know to popup a prompt, how does it submit the info back to the MS proxy server, and why couldn't VC simulate that? More research to do with IE...

Rebeccah

Here is the behavior I see with IE:

IE conversation:
1. IE sends request to proxy server
2. Proxy server returns 407 authentication required
3. IE sends request with proxy-authorization string
4. Web server returns 407 authentication required
5. IE sends request with different proxy-authorization string
7. Proxy server returns 407 authentication required
8. IE sends request with original (proxy server) authorization string
9. Web server returns 407 authentication required
10. IE sends request with a new web server proxy-authorization string, different from the first one
11. Web server returns 401 unauthorized with proxy-support: session-based-authentication
and www-authenticate: negotiate
and www-authenticate: ntlm
12. IE sends request with authorization (NOT proxy-authorization) string
13. Web server returns 401 unauthorized and a new www-authenticate string
14. IE sends rquest with new authorization string
15. Web server returns 302 moved temporarily (redirect)

New connection:
1. IE sends request to proxy server
2. Proxy server returns 407 authentication required
3. IE sends request with proxy-authorization string
4. Web server returns 407 authentication required
11. Web server returns 401 unauthorized with proxy-support: session-based-authentication
and www-authenticate: negotiate
and www-authenticate: ntlm
12. IE sends request with authorization (NOT proxy-authorization) string
13. Web server returns 401 unauthorized and a new www-authenticate string
14. IE sends rquest with new authorization string
15. Web server returns 302 moved temporarily (redirect)

Connection 3:
1. IE sends request to proxy server
2. Proxy server returns 407 authentication required
3. IE sends request with proxy-authorization string
4. Web server returns 407 authentication required
11. Web server returns 401 unauthorized with proxy-support: session-based-authentication
and www-authenticate: negotiate
and www-authenticate: ntlm
12. IE sends request with authorization (NOT proxy-authorization) string
13. Web server returns 401 unauthorized and a new www-authenticate string
14. IE sends rquest with new authorization string
15. Web server returns 200 OK and a jsessionid cookie

more connections follow similar to the last one, to fetch the different resources on the page.



VisualCron, OTOH:

1. VC sends request to proxy server
2. Proxy server returns 407 authentication required

Connection 2:
1. VC sends proxy-authorization string
2. Web server returns 407 authentication required
3. VC sends request with new proxy-authorization string
4. Web server sends 401 unauthorized with proxy-support: session-based-authentication
and www-authenticate: negotiate
and www-authenticate: ntlm

Connection 3:
1. VC sends authorization string
2. Proxy server sends 407 authentication required

Connection 4:
1. VC sends request with the same authorization string
and the authentication string duplicated in the proxy-authorization field
2. Web server returns 407 authentication required
3. VC sends request with new authorization and proxy-authorization strings
4. Web server returns 401 unauthorized with proxy-support: session-based-authentication
and www-authenticate: negotiate
and www-authenticate: ntlm

Connection 5:
1. VC sends request with a new authorization string
2. Proxy server returns 407 authentication required
3. VC sends request with proxy-authorization string same as in connection 4
and authorization string same as in connection 5
4. Web server returns 407 authentication required
5. VC sends request with the same authorization string and a new proxy-authorization string
6. Web server returns 401 unauthorized with proxy-support: session-based-authentication
and www-authenticate: negotiate
and www-authenticate: ntlm


So it looks like what is happening is that then NTLM authentication does not succeed, the web server is falling back to session-based authentication, but VC is not responding to that.

Rebeccah

P.S.
A possibly relevant MS ISA article: http://support.microsoft.com/kb/312176 
A possibly relevant Apache mod-proxy bug thread: https://issues.apache.or...la/show_bug.cgi?id=44110  "...for historical reasons and completely blanked out the little factlet that NTLM requires KeepAlive/HTTP1.1 in order to operate. Once I removed those settings it started working."
A possibly relevant article on the HTTP header Proxy-Support: Session-based authentication: https://kb.bluecoat.com/...;id=KB1420&actp=LIST 

Hi Rebeccah,

thank you for your testing and comments.

You can change Agent in VisualCron. We will see about changing HTTP mode and Keep-Alive settings and get back to you.

---

The other thing that seems important, if you're not already doing it and getting cut off by the lack of keep-alive, is that proxy-support: session-based-authentication header, which tells you it's the web server and not the proxy server that is requesting authentication.

Turns out the user-agent didn't matter after all.

Rebeccah

Please test this version:

http://neteject.com/down...Cron/VisualCron5.7.0.exe 

Try with default settings first. Then you can alter HTTP protocol version, KeepAlive, AutoRedirect value.

Please note that this version adds some heavy debug logging to file which we will remove for final version. This is just for testing. Please let us know.

---

Thanks, I'll give it a try. Do I just install it on top of the existing one? Do I need to stop/restart the service? Do I need to enter the activation code?

Rebeccah

Just install over on top of old. You do not need to enter any new activation code.

---

If this version does not help you I recommend going back to previous version by uninstalling this and then install previous.

---

Do I need to install it both on the server machine and on the client machine?

No luck. It's still failing, and looking at the beginning of the WireShark trace, it's still setting Proxy-Connection: Close, and it's still terminating the first connection after one request/response. I used the client on the same machine as the server, so I didn't have to worry about whether client and server are the same version.

Oh, and I didn't see any change to the UI at all. Maybe you accidentally recompiled the previous version with the new version number? Or maybe I need to create a whole new http task, rather than just retrying an existing one. I'll be back.

Rebeccah

Nope. Even creating a new HTTP task, I don't see any options for setting HTTP protocol version, KeepAlive, or AutoRedirect value.

Rebeccah

It was really late for us in Sweden yesterday so we managed to mix up the files. We will provide a new link later today. Sorry for any inconvience.

---

No problem. It's late for me now. Going home to go to bed. :-)

Rebeccah

Please try downloading using same url.

---

OK, well we're making some progress. Correction to my original post. There is no error output. The standard output starts with a bunch of blank characters, so I didn't see it at first.

Hooray, there's my web page!

Thanks a bunch, guys!

Rebeccah

Which setting made it work for you?

---

Defaults - HTTP 1.1, keep-alive, allow autoredirect, 600sec timeout

I presume that my users will need to update their VC clients to see these settings. If they don't, will the defaults apply?

Rebeccah