|Subject:||Re: Microsoft ISA 2004 firewall and IdHTTP.Post / Connect / Connected|
|Posted by:||Remy Lebeau (Indy Team) (firstname.lastname@example.org)|
|Date:||Mon, 14 Aug 2006|
"Andrew Fiddian-Green" <nn@dd> wrote in message
> Before starting a lengthy upload process with TIdHTTP.Post using
> SSL I would like to do a fast pre- check "ping" to determine which of
> the client machine's local addresses will (most likely) result in success.
Theonly reliable way to do that is to make multiple Get/Post requests to the
same server, manually binding each request to a different IP each time.
Otherwise, the IP will be random each time, and can change between requests,
even between the "ping" and the actual upload. Binding the socket
beforehandl is the other reliable way to control that.
> At present I use HTTP.Connect() followed by a test for HTTP.Connected
> to confirm if the client can establish a TCP connection to the server
There is no need to call Connected(). Connect() will throw an exeption if
it fails. You shouldn't be calling Connect() directly, though, since
Get/Post() call that internally, and thus could disconnect the socket and
> and if this works I proceed with the full blown HTTP.Post (see code below)
If you are going to perform Connect() and Post() operations separately, then
you may as well not even use TIdHTTP at all. It is not designed for that.
Why do you need to ping at all, though? If you perform the Post() from the
beginning, you will know immediately whether it is going to connect or not,
and if it does connect then it can simply finish its work automatically. So
how does the pinging actually benefit you? Chances are, the OS will be able
to route the connection better than you can anyway, since it knows the
routing tables of each IP address and can determine the best way to reach a
given destination IP.
> In the majority of network configurations my code seems to work fine,
> but I discovered that if the client is behind a Microsoft ISA 2004
> firewall the HTTP.Connect() and HTTP.Connected test always fails
> -- even though the firewall is configured to pass HTTP calls.
Pinging IPs will not help address that very well.
How EXACTLY is the firewall configured? Are you absolutely sure that it is
going to allow HTTP traffic on all local IPs?
> I suppose this is because HTTP.Connect() works below the HTTP
> level, and the firewall won't actually allow the connection until it
> "knows" that it is carrying an HTTP payload.
Not necessarily. Most firewalls and routers look at the Port numbers only.
HTTP ports are standardized - 80 and 8080. If an outbound connection is
attempting to connect to a remote server on port 80/8080, then they assume
the connection is meant for HTTP, and will allow the connection to proceed.
If they want to look at the payload later to verify that the data is
actually HTTP, they can do that if desired, but that is handled separately.
Microsoft ISA 2004 firewall and IdHTTP.Post / Connect / Connected posted by Andrew Fiddian-Green on Mon, 14 Aug 2006