Re: [2/2] rpcrt4: Clear the connection pool when closing an http connection.
On 09/04/13 15:01, Hans Leidekker wrote:
--- dlls/rpcrt4/rpc_transport.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/dlls/rpcrt4/rpc_transport.c b/dlls/rpcrt4/rpc_transport.c index d0857fa..1eb0151 100644 --- a/dlls/rpcrt4/rpc_transport.c +++ b/dlls/rpcrt4/rpc_transport.c @@ -3234,6 +3234,8 @@ static int rpcrt4_ncacn_http_close(RpcConnection *Connection) HeapFree(GetProcessHeap(), 0, httpc->servername); httpc->servername = NULL;
+ /* don't allow this connection to be reused */ + InternetSetOptionW(NULL, INTERNET_OPTION_SETTINGS_CHANGED, NULL, 0);
There must be a better way to do that than removing all existing wininet cached connections to all hosts. Removing INTERNET_FLAG_KEEP_CONNECTION from HttpOpenRequest call would be a good start... Jacek
On Wed, 2013-09-04 at 15:28 +0200, Jacek Caban wrote:
On 09/04/13 15:01, Hans Leidekker wrote:
--- dlls/rpcrt4/rpc_transport.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/dlls/rpcrt4/rpc_transport.c b/dlls/rpcrt4/rpc_transport.c index d0857fa..1eb0151 100644 --- a/dlls/rpcrt4/rpc_transport.c +++ b/dlls/rpcrt4/rpc_transport.c @@ -3234,6 +3234,8 @@ static int rpcrt4_ncacn_http_close(RpcConnection *Connection) HeapFree(GetProcessHeap(), 0, httpc->servername); httpc->servername = NULL;
+ /* don't allow this connection to be reused */ + InternetSetOptionW(NULL, INTERNET_OPTION_SETTINGS_CHANGED, NULL, 0);
There must be a better way to do that than removing all existing wininet cached connections to all hosts. Removing INTERNET_FLAG_KEEP_CONNECTION from HttpOpenRequest call would be a good start...
We can't do that, it breaks NTLM and Negotiate.
On 09/04/13 15:36, Hans Leidekker wrote:
On Wed, 2013-09-04 at 15:28 +0200, Jacek Caban wrote:
On 09/04/13 15:01, Hans Leidekker wrote:
--- dlls/rpcrt4/rpc_transport.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/dlls/rpcrt4/rpc_transport.c b/dlls/rpcrt4/rpc_transport.c index d0857fa..1eb0151 100644 --- a/dlls/rpcrt4/rpc_transport.c +++ b/dlls/rpcrt4/rpc_transport.c @@ -3234,6 +3234,8 @@ static int rpcrt4_ncacn_http_close(RpcConnection *Connection) HeapFree(GetProcessHeap(), 0, httpc->servername); httpc->servername = NULL;
+ /* don't allow this connection to be reused */ + InternetSetOptionW(NULL, INTERNET_OPTION_SETTINGS_CHANGED, NULL, 0); There must be a better way to do that than removing all existing wininet cached connections to all hosts. Removing INTERNET_FLAG_KEEP_CONNECTION from HttpOpenRequest call would be a good start... We can't do that, it breaks NTLM and Negotiate.
Hmm, right. Thinking more about this, I don't see how this connection could be reused. RPC over HTTP shouldn't reach the end of the stream, so it can't be reused once the connection is established, even if client closes the handle. If it is, that's probably a bug in wininet. When did you see this to happen? Jacek
On Wed, 2013-09-04 at 18:16 +0200, Jacek Caban wrote:
On 09/04/13 15:36, Hans Leidekker wrote:
On Wed, 2013-09-04 at 15:28 +0200, Jacek Caban wrote:
On 09/04/13 15:01, Hans Leidekker wrote:
+ /* don't allow this connection to be reused */ + InternetSetOptionW(NULL, INTERNET_OPTION_SETTINGS_CHANGED, NULL, 0); There must be a better way to do that than removing all existing wininet cached connections to all hosts. Removing INTERNET_FLAG_KEEP_CONNECTION from HttpOpenRequest call would be a good start... We can't do that, it breaks NTLM and Negotiate.
Hmm, right. Thinking more about this, I don't see how this connection could be reused. RPC over HTTP shouldn't reach the end of the stream, so it can't be reused once the connection is established, even if client closes the handle. If it is, that's probably a bug in wininet. When did you see this to happen?
It happens when Outlook connects to Exchange, closes the connection and then reconnects. I didn't trust wininet either and wrote a standalone test to mimic the consecutive connects. It showed that wininet is right in reusing the connection, though I didn't perform any reads or writes. You say that reuse depends on reaching end of stream, so this might actually be a variation of the other bug, which is that in chunked mode we can't know whether we reached end of stream.
participants (2)
-
Hans Leidekker -
Jacek Caban