If the remote server has closed the connection, this will happen.
If you wait too long to send data, the server may give up and close the
idle connection. I am not certain this is what you are seeing, but it's
a reasonable guess.
1) at time t, isa created a connection to the target server and forwarded
the data to it. the web-filter initiated this by reacting to
forward_raw_data_completed notification and invoking a writeserver api. the
http message that was sent had this in the http header:
Keep-Alive: 300\r\n
2. at time t+7 minutes later, the web filter got an
sf_forward_raw_data_completed notification again (after sending
sf_forward_raw_data) with the same filter context as #1 above. the
Writeserver API now tried to reuse the same connection that was set up in #1
above, and the target server (http) promptly sent back a tcp rst. this then
resulted in the error 64 that was seen on the client.
the connection management with the target web server isn't in the web
filter's hands (from what i can understand from the sdk documentation).
questions:
1) why is isa not closing down the connection after 5 minutes. this was the
last keep alive value that the isa sent to the server in the last message
2. the target server seem to be doing the right thing - i.e. closing down
the connection. can the web filter control this behavior in any way?