Forum Moderators: open
We've had a web server that is on an Air Force base for a few years and worked fine. We use NTLM to
access it. In our latest version we have switched to Sun java and we now use an application which is java based (not a browser)to access the web site.
We first put everything on our test servers (at our facility)and have the people at the Air Force base test it. We also test it from our work location and from home etc. We can all get to it but the people at the Air Force base can't. They can bring up
the application and they get the login prompt. It's when they hit the "Login" button that it hangs.
From looking at the log files on the web server I can see as we access the site that we are using a lot of GETs and then switch to the POST method. When I look at their (Air Force) connection I see all the GETs and the 1st POST and then it just hangs. Do you know if the POST method could be blocked by a proxies or firewall?. We can't find out about their firewalls etc ..they won't tell us.
These are the entries in our logs. The first is us accessing it and everything works. The second is them and it hangs.
Any help you can provide would be appreciated.
Pat.
x.x.x.x one of our systems connecting to the web server.
y.y.y.y the web server
z.z.z.z the Air Force
2004-05-28 13:46:04 x.x.x.x - y.y.y.y 443 GET /name/OperatorMessage/OperMsg.txt - 401 Java/1.4.2_04
2004-05-28 13:46:04 x.x.x.x Domain\username x.x.x.x 443 GET /name/OperatorMessage/OperMsg.txt - 404 Java/1.4.2_04
2004-05-28 13:46:04 x.x.x.x - y.y.y.y 443 POST /scripts/ops20/Fetch.dll userFetch 401 Java/1.4.2_04
2004-05-28 13:46:05 x.x.x.x Domain\username x.x.x.x 443 POST /scripts/name/Fetch.dll userFetch 200 Java/1.4.2_04
2004-05-28 13:44:06 z.z.z.z Domain\username x.x.x.x 443 GET /name/OperatorMessage/OperMsg.txt - 404 Java/1.4.2_04
2004-05-28 13:44:06 z.z.z.z - x.x.x.x 443 POST /scripts/name/Fetch.dll userFetch 401 Java/1.4.2_04
Yes, a firewall can be configured to block a POST. But if their firewall blocked it, then I don't think you would see it on your server logs because their browser would not execute it in the first place.
I notice in your log entry that your attempt includes the directory /ops20 in the URL and theirs doesn't. Is that a useful clue?
Hey, I didn't know that. I always thought firewalls only block/permit all traffic to/from certain IP numbers and/or ports. It would explain a problem I've been pulling my hair out about...
But could they (or would it make any sense) to just block the return from their POST?
If they ate not blocking it at the firewall any ideas as why they don't follow up the first POST with the second one that would have the authentication in it?
Could a proxy be effecting it?
Pat.
