"Clive George" <clive@x...> wrote in message 
news:45c8eeb6$0$8727$ed2619ec@p......
> "Alex Krawarik [MSFT]" <alexkr@o...> wrote in message 
> news:OwpAlBiSHHA.2212@T......
>>>> Not known, no.
>>>
>>> What would be the best way of making it known :-)
>>
>> A stand-alone repro so the product team could investigate the behavior, 
>> and perhaps issue a fix if necessary or provide some other guidance. We 
>> use IIS on the server-side for testing, so perhaps the first step might 
>> be to see if your scenario repros if you issue your HTTP requests to an 
>> IIS 5.0 or 6.0 (or 7.0!) box ? If so, then all we'd need is your basic 
>> code and config.
>
> OK. I'm afraid I'm not too good with IIS, but I've found a box to play 
> with and am doing so.
>
> A "stand-alone repro" isn't going to be easy, because it relies on a slow 
> connection. Are you able to arrange such a thing? Over the VPN I'm using, 
> I can get it to fail about 1 in 20 times if I get the timing right, and 
> I've been using a keepalive timeout of 2 seconds on the server side to 
> stop it taking forever
>
> I've got keepalive turned on, and have turned the connection timeout to 2 
> seconds. Except that's not happening. Where can I do this? I need the 
> server to drop the connection before the client in order to demonstrate 
> the problem, and I can't get the server to drop the connection :-( Any 
> ideas?
>
> (it's a lot easier to demonstrate with apache :-) )

Further to this : IIS is behaving differently to apache. The client kills 
the connection (RST, not FIN), a minute after the POST request when it came 
back from IIS. Any idea why it does this? It would be an acceptable 
get-round if I could get it to do it (bump the server side timeout time to > 
the client side, which would mean the client would always timeout first and 
thus not get the opportunity to experience the problem I'm seeing).

cheers,
clive