dotnet / wcf Goto Github PK

In HttpChannelUtilities.CreateRequestTimedOutMessage, the timeout value that was used when a request timed out is not available so the value 1000ms is used instead.

In HttpChannelFactory<TChannel>.GetHttpRequestMessageAsync, only a CancellationToken is passed in. When using manual addressing, a call is made to CreateAndOpenTokenProviders which requires a timeout. As the timeout isn't available, the value of 1 minute is used.

    if (this.ManualAddressing)
    {
        TimeoutHelper timeoutHelper = new TimeoutHelper(TimeSpan.FromMinutes(1));
        this.Factory.CreateAndOpenTokenProviders(to, via, _channelParameters, timeoutHelper.RemainingTime(),
            out httpClientTokenProvider);
    }

Two possible solutions come to mind, I'm sure there are others 😃

1. Pass a TimeoutHelper to GetHttpRequestMessageAsync as that contains a CancellationToken as well as the remaining time. This will work for the call to CreateAndOpenTokenProviders as well as the code that follows which requires a CancellationToken.
2. Modify CreateAndOpenTokenProviders to use a CancellationToken. This will require making changes in further called code. This may not be possible depending on how the timeout is currently used as a CancellationToken might not be compatible.

In order to avoid parsing the wsdl myself, I'm using Silverlight SDK Microsoft.ServiceReference.dll to get the Silverlight generated proxy that I modify then before generating it.

I don't want to use svcutil that can only generate a file as far as I know.

However, I would like to remove my dependence to Silverlight. So I would love to see a such method here.

Thanks

Matthieu

From PR #22. Once a fix for https://github.com/dotnet/corefx/issues/963 is in, we should pull in a similar change. Today, nuget package restore would fail when behind a corporate firewall.

Thanks @PatrickMcDonald for the heads up!

PlatformNotSupportedException is thrown is if any Http binding attempts to use AuthenticationSchemes.NTLM

DnsEndpointIdentity currently throws PlatformNotSupportedException.

Add support for WebSockets in NetHttpBinding

This needs more investigation on whether we're trying to dispose HttpClient while still using it or if there is a other race condition inside HttpClient cleanup itself.

The following scenario (pseudo-code) produces numerous native memory leaks. Note that the memory only leaks if there is a race condition (e.g. the channel factory or the channel are being used while the channel factory is being closed).

Thread A:
  if(factory_A == null) {
      factory = factory_A = new ChannelFactory();
  }
  channel = factory.CreateChannel();
  channel.Use();
  channel.Close();

Thread B:
  factory = factory_A;
  factory_A = null;
  factory.Close();
  sleep();
  goto start;

This is a valid scenario for WCF. The workaround is to avoid doing this scenario.
Here are the top call stacks:

+ 436423360 ( 458918560 - 22495200)  27847 allocs BackTrace3CB2363D
+   26482 (  27847 -   1365) BackTrace3CB2363D allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 webio!WaCreateEndpointManager+30 (d:\9147\net\webio\core\epmgr.c, 204)
 webio!WapCreateSession+8E (d:\9147\net\webio\core\session.c, 258)
 webio!WapCreateSessionHandle+9F (d:\9147\net\webio\core\session.c, 558)
 webio!WebCreateSession+E (d:\9147\net\webio\core\session.c, 1258)
 winhttp!WinHttpSendRequest+6A4 (d:\9147\net\winhttp\api\sendapi.cxx, 218)
 <no module>!???+0 : 7FFCDE65B579

+ 108893984 ( 114506864 - 5612880)  27847 allocs BackTrace3CB237BD
+   26482 (  27847 -   1365) BackTrace3CB237BD allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 webio!WaCreateCookieJar+3D (d:\9147\net\webio\cookies\cookiejar.c, 5447)
 webio!WapCreateSession+AC (d:\9147\net\webio\core\session.c, 281)
 webio!WapCreateSessionHandle+9F (d:\9147\net\webio\core\session.c, 558)
 webio!WebCreateSession+E (d:\9147\net\webio\core\session.c, 1258)
 winhttp!WinHttpSendRequest+6A4 (d:\9147\net\winhttp\api\sendapi.cxx, 218)
 <no module>!???+0 : 7FFCDE65B579

+ 83259408 ( 87550968 - 4291560)  27847 allocs BackTrace3CB2387D
+   26482 (  27847 -   1365) BackTrace3CB2387D allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 webio!WaCreateDnsCache+3C (d:\9147\net\webio\util\dnsquery.c, 1393)
 webio!WapCreateSession+BE (d:\9147\net\webio\core\session.c, 288)
 webio!WapCreateSessionHandle+9F (d:\9147\net\webio\core\session.c, 558)
 webio!WebCreateSession+E (d:\9147\net\webio\core\session.c, 1258)
 winhttp!WinHttpSendRequest+6A4 (d:\9147\net\winhttp\api\sendapi.cxx, 218)
 <no module>!???+0 : 7FFCDE65B579

+ 12711360 ( 13366560 - 655200)  27847 allocs BackTrace3C8F69BD
+   26482 (  27847 -   1365) BackTrace3C8F69BD allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 winhttp!WinHttpOpen+1DF (d:\9147\net\winhttp\api\inetapiw.cxx, 1344)
 <no module>!???+0 : 7FFCDE6525E8

+ 8474240 ( 8911040 - 436800)  27847 allocs BackTrace3CB239FD
+   26482 (  27847 -   1365) BackTrace3CB239FD allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 ntdll!TpAllocTimer+88 (d:\9141\minkernel\threadpool\ntdll\timer.c, 1550)
 KERNELBASE!CreateThreadpoolTimer+18 (d:\9147\minkernel\threadpool\kernel32\threadpool.c, 165)
 webio!WaCreateTimer+5F (d:\9147\net\webio\util\timer.c, 258)
 webio!WaCreateDnsCache+A0 (d:\9147\net\webio\util\dnsquery.c, 1425)
 webio!WapCreateSession+BE (d:\9147\net\webio\core\session.c, 288)
 webio!WapCreateSessionHandle+9F (d:\9147\net\webio\core\session.c, 558)
 webio!WebCreateSession+E (d:\9147\net\webio\core\session.c, 1258)
 winhttp!WinHttpSendRequest+6A4 (d:\9147\net\winhttp\api\sendapi.cxx, 218)
 <no module>!???+0 : 7FFCDE65B579

+ 8474240 ( 8911040 - 436800)  27847 allocs BackTrace3CB236FD
+   26482 (  27847 -   1365) BackTrace3CB236FD allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 ntdll!TpAllocTimer+88 (d:\9141\minkernel\threadpool\ntdll\timer.c, 1550)
 KERNELBASE!CreateThreadpoolTimer+18 (d:\9147\minkernel\threadpool\kernel32\threadpool.c, 165)
 webio!WaCreateSettableTimer+3E (d:\9147\net\webio\util\timer.c, 333)
 webio!WaCreateEndpointManager+C9 (d:\9147\net\webio\core\epmgr.c, 248)
 webio!WapCreateSession+8E (d:\9147\net\webio\core\session.c, 258)
 webio!WapCreateSessionHandle+9F (d:\9147\net\webio\core\session.c, 558)
 webio!WebCreateSession+E (d:\9147\net\webio\core\session.c, 1258)
 winhttp!WinHttpSendRequest+6A4 (d:\9147\net\winhttp\api\sendapi.cxx, 218)
 <no module>!???+0 : 7FFCDE65B579

+ 8474240 ( 8911040 - 436800)  27847 allocs BackTrace3C90C0FD
+   26482 (  27847 -   1365) BackTrace3C90C0FD allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 ntdll!TpAllocTimer+88 (d:\9141\minkernel\threadpool\ntdll\timer.c, 1550)
 KERNELBASE!CreateThreadpoolTimer+18 (d:\9147\minkernel\threadpool\kernel32\threadpool.c, 165)
 winhttp!WxCreateThreadpoolTimer+5B (d:\9147\inetcore\inetcommon\wxlib\wx_threadpool.cpp, 148)
 winhttp!WinHttpClientSession::FinalConstruct+24 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 2689)
 winhttp!WinHttpClientSession::CreateInstance+74 (d:\9147\inetcore\inetcommon\proxylib\inc\wxp_winhttpclient.h, 34)
 winhttp!WinHttpClientResolver::Initialize+95 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 1392)
 winhttp!WinHttpClientResolver::CreateInstance+89 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 2639)
 winhttp!CreateWinHttpClientResolverInstance+4B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 891)
 winhttp!CreateAutoProxyForWinHttp+67 (d:\9147\net\winhttp\proxy\proxyhelper.cpp, 199)
 winhttp!WxProxyManager::Initialize+456F7 (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 829)
 winhttp!WxProxyManager::CreateInstance+67 (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 1966)
 winhttp!CreateProxyManagerResolverInstance+3B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 915)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::LoadAutomaticProxyResolvers+202 (d:\9147\net\winhttp\handles\hinet.cxx, 2007)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::SetProxySettings+44ED5 (d:\9147\net\winhttp\handles\hinet.cxx, 2167)
 winhttp!WinHttpSetOptionInternal+397 (d:\9147\net\winhttp\api\options.cxx, 1967)
 winhttp!WinHttpOpen+27A (d:\9147\net\winhttp\api\inetapiw.cxx, 1344)
 <no module>!???+0 : 7FFCDE6525E8

+ 8474240 ( 8911040 - 436800)  27847 allocs BackTrace3C90B53D
+   26482 (  27847 -   1365) BackTrace3C90B53D allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 winhttp!WinHttpClientResolver::CreateInstance+59 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 2636)
 winhttp!CreateWinHttpClientResolverInstance+4B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 891)
 winhttp!CreateAutoProxyForWinHttp+67 (d:\9147\net\winhttp\proxy\proxyhelper.cpp, 199)
 winhttp!WxProxyManager::Initialize+456F7 (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 829)
 winhttp!WxProxyManager::CreateInstance+67 (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 1966)
 winhttp!CreateProxyManagerResolverInstance+3B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 915)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::LoadAutomaticProxyResolvers+202 (d:\9147\net\winhttp\handles\hinet.cxx, 2007)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::SetProxySettings+44ED5 (d:\9147\net\winhttp\handles\hinet.cxx, 2167)
 winhttp!WinHttpSetOptionInternal+397 (d:\9147\net\winhttp\api\options.cxx, 1967)
 winhttp!WinHttpOpen+27A (d:\9147\net\winhttp\api\inetapiw.cxx, 1344)
 <no module>!???+0 : 7FFCDE6525E8

+ 5720112 ( 6014952 - 294840)  27847 allocs BackTrace3C90C23D
+   26482 (  27847 -   1365) BackTrace3C90C23D allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 ntdll!TpAllocWork+92 (d:\9141\minkernel\threadpool\ntdll\work.c, 330)
 KERNELBASE!CreateThreadpoolWork+18 (d:\9147\minkernel\threadpool\kernel32\threadpool.c, 149)
 winhttp!WxCreateThreadpoolWork+5B (d:\9147\inetcore\inetcommon\wxlib\wx_threadpool.cpp, 63)
 winhttp!WinHttpClientSession::FinalConstruct+45 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 2694)
 winhttp!WinHttpClientSession::CreateInstance+74 (d:\9147\inetcore\inetcommon\proxylib\inc\wxp_winhttpclient.h, 34)
 winhttp!WinHttpClientResolver::Initialize+95 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 1392)
 winhttp!WinHttpClientResolver::CreateInstance+89 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 2639)
 winhttp!CreateWinHttpClientResolverInstance+4B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 891)
 winhttp!CreateAutoProxyForWinHttp+67 (d:\9147\net\winhttp\proxy\proxyhelper.cpp, 199)
 winhttp!WxProxyManager::Initialize+456F7 (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 829)
 winhttp!WxProxyManager::CreateInstance+67 (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 1966)
 winhttp!CreateProxyManagerResolverInstance+3B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 915)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::LoadAutomaticProxyResolvers+202 (d:\9147\net\winhttp\handles\hinet.cxx, 2007)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::SetProxySettings+44ED5 (d:\9147\net\winhttp\handles\hinet.cxx, 2167)
 winhttp!WinHttpSetOptionInternal+397 (d:\9147\net\winhttp\api\options.cxx, 1967)
 winhttp!WinHttpOpen+27A (d:\9147\net\winhttp\api\inetapiw.cxx, 1344)
 <no module>!???+0 : 7FFCDE6525E8

+ 4237120 ( 4455520 - 218400)  27847 allocs BackTrace3C90A5BD
+   26482 (  27847 -   1365) BackTrace3C90A5BD allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 winhttp!WxProxyManager::CreateInstance+3D (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 1963)
 winhttp!CreateProxyManagerResolverInstance+3B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 915)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::LoadAutomaticProxyResolvers+202 (d:\9147\net\winhttp\handles\hinet.cxx, 2007)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::SetProxySettings+44ED5 (d:\9147\net\winhttp\handles\hinet.cxx, 2167)
 winhttp!WinHttpSetOptionInternal+397 (d:\9147\net\winhttp\api\options.cxx, 1967)
 winhttp!WinHttpOpen+27A (d:\9147\net\winhttp\api\inetapiw.cxx, 1344)
 <no module>!???+0 : 7FFCDE6525E8

+ 2754128 ( 2896088 - 141960)  27847 allocs BackTrace3C90B9FD
+   26482 (  27847 -   1365) BackTrace3C90B9FD allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 combase!CoTaskMemAlloc+3A (d:\9147\com\combase\class\memapi.cxx, 459)
 winhttp!HostProxyMap::CreateInstance+66 (d:\9147\inetcore\inetcommon\proxylib\inc\wxp_hostproxymap.h, 64)
 winhttp!AutoProxyBase::Initialize+33 (d:\9147\inetcore\inetcommon\proxylib\autoprox.cpp, 204)
 winhttp!WinHttpClientResolver::Initialize+37 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 1382)
 winhttp!WinHttpClientResolver::CreateInstance+89 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 2639)
 winhttp!CreateWinHttpClientResolverInstance+4B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 891)
 winhttp!CreateAutoProxyForWinHttp+67 (d:\9147\net\winhttp\proxy\proxyhelper.cpp, 199)
 winhttp!WxProxyManager::Initialize+456F7 (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 829)
 winhttp!WxProxyManager::CreateInstance+67 (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 1966)
 winhttp!CreateProxyManagerResolverInstance+3B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 915)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::LoadAutomaticProxyResolvers+202 (d:\9147\net\winhttp\handles\hinet.cxx, 2007)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::SetProxySettings+44ED5 (d:\9147\net\winhttp\handles\hinet.cxx, 2167)
 winhttp!WinHttpSetOptionInternal+397 (d:\9147\net\winhttp\api\options.cxx, 1967)
 winhttp!WinHttpOpen+27A (d:\9147\net\winhttp\api\inetapiw.cxx, 1344)
 <no module>!???+0 : 7FFCDE6525E8

+ 2754128 ( 2896088 - 141960)  27847 allocs BackTrace3C90A1BD
+   26482 (  27847 -   1365) BackTrace3C90A1BD allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 combase!CoTaskMemAlloc+3A (d:\9147\com\combase\class\memapi.cxx, 459)
 winhttp!WxProxyList::Initialize+70 (d:\9147\inetcore\inetcommon\proxylib\badproxy.cpp, 102)
 winhttp!WxProxyList::CreateInstance+7F (d:\9147\inetcore\inetcommon\proxylib\badproxy.cpp, 76)
 winhttp!CreateBadProxyListInstance+32 (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 813)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::LoadAutomaticProxyResolvers+1D3 (d:\9147\net\winhttp\handles\hinet.cxx, 2005)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::SetProxySettings+44ED5 (d:\9147\net\winhttp\handles\hinet.cxx, 2167)
 winhttp!WinHttpSetOptionInternal+397 (d:\9147\net\winhttp\api\options.cxx, 1967)
 winhttp!WinHttpOpen+27A (d:\9147\net\winhttp\api\inetapiw.cxx, 1344)
 <no module>!???+0 : 7FFCDE6525E8

+ 2754128 ( 2896088 - 141960)  27847 allocs BackTrace3C8F6BFD
+   26482 (  27847 -   1365) BackTrace3C8F6BFD allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 combase!CoTaskMemAlloc+3A (d:\9147\com\combase\class\memapi.cxx, 459)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::INTERNET_SESSION_HANDLE_OBJECT+394 (d:\9147\net\winhttp\handles\hinet.cxx, 1087)
 winhttp!WinHttpOpen+1F3 (d:\9147\net\winhttp\api\inetapiw.cxx, 1344)
 <no module>!???+0 : 7FFCDE6525E8

+ 2542272 ( 2673312 - 131040)  27847 allocs BackTrace3CB2357D
+   26482 (  27847 -   1365) BackTrace3CB2357D allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 webio!WapCreateSession+3A (d:\9147\net\webio\core\session.c, 227)
 webio!WapCreateSessionHandle+9F (d:\9147\net\webio\core\session.c, 558)
 webio!WebCreateSession+E (d:\9147\net\webio\core\session.c, 1258)
 winhttp!WinHttpSendRequest+6A4 (d:\9147\net\winhttp\api\sendapi.cxx, 218)
 <no module>!???+0 : 7FFCDE65B579

+ 2330416 ( 2450536 - 120120)  27847 allocs BackTrace3C90BBFD
+   26482 (  27847 -   1365) BackTrace3C90BBFD allocations

 ntdll!RtlpCallInterceptRoutine+40 (d:\9141\minkernel\ntos\rtl\heappriv.h, 3625)
 ntdll!RtlAllocateHeap+7B5F8 (d:\9141\minkernel\ntos\rtl\heap.c, 1892)
 winhttp!WinHttpClientSession::CreateInstance+25 (d:\9147\inetcore\inetcommon\proxylib\inc\wxp_winhttpclient.h, 34)
 winhttp!WinHttpClientResolver::Initialize+95 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 1392)
 winhttp!WinHttpClientResolver::CreateInstance+89 (d:\9147\inetcore\inetcommon\proxylib\winhttpclient.cpp, 2639)
 winhttp!CreateWinHttpClientResolverInstance+4B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 891)
 winhttp!CreateAutoProxyForWinHttp+67 (d:\9147\net\winhttp\proxy\proxyhelper.cpp, 199)
 winhttp!WxProxyManager::Initialize+456F7 (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 829)
 winhttp!WxProxyManager::CreateInstance+67 (d:\9147\inetcore\inetcommon\proxylib\proxymanager.cpp, 1966)
 winhttp!CreateProxyManagerResolverInstance+3B (d:\9147\inetcore\inetcommon\proxylib\proxyutil.cpp, 915)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::LoadAutomaticProxyResolvers+202 (d:\9147\net\winhttp\handles\hinet.cxx, 2007)
 winhttp!INTERNET_SESSION_HANDLE_OBJECT::SetProxySettings+44ED5 (d:\9147\net\winhttp\handles\hinet.cxx, 2167)
 winhttp!WinHttpSetOptionInternal+397 (d:\9147\net\winhttp\api\options.cxx, 1967)
 winhttp!WinHttpOpen+27A (d:\9147\net\winhttp\api\inetapiw.cxx, 1344)
 <no module>!???+0 : 7FFCDE6525E8

The ctor currently throws PlatformNotSupportedException.

We will want to be able to run (or exclude) subsets of unit and scenario tests by category independent of their CSPROJ grouping. I believe the best approach is to define our own xunit trait attributes and attach them to the tests. This is consistent with what is being proposed in CoreFx Issue https://github.com/dotnet/corefx/issues/1477 and will allow filtering in or out tests by category.

Let's use this current issue to first propose what test categories we need, then we can create the PR to implement and apply them. Note that the current build tools categorize OuterLoop tests using an xunit trait attribute, but that may change. If it does change, it is not expected to affect our use of our own traits.

Using using with many WCF objects is a real minefield because Dispose can throw exceptions if the channel is in a Faulted state. This behavior is well known, but very counter-intuitive and the "pattern" to try/finally { abort or close } makes code more verbose than it needs to be.

By Microsoft's own design guidelines, Dispose should not throw an exception.

In order to avoid breaking the public contract ([a]n exception is no longer thrown) this behavior could be opt-in.

I do not have a good suggestion for how to provide the opt-in. Setting compatibility settings in (app|web).config (like NetFx40_LegacySecurityPolicy, CompatSortNLSVersion, TimeSpan_LegacyFormatMode) will apply to every assembly, when third-party assemblies might be broken by this change (unlikely but possible).

So I submit the following suggestions:

• A Ca1065CompliantDisposeBehaviorAttribute on service contracts (channels should know their service contracts?)
• A new constructor/constructor argument/property

Currently, in desktop, SecurityTokenProvider implements async with APM (i.e., BeginXXX/EndXXX methods). We should consider changing these out in favour of using async methods.

This will benefit long-term development as it will allow us to advantage of the async niceness and not have to handle Begin/End methods and the associated AsyncResults.

However, while going from APM to async probably will simplify the code a lot, it will likely be a lot of work to replumb all the calls into the various SecurityTokenProviders.

So this issue is essentially two-part:

• Bring over the necessary token providers for WCF client
• While doing so, consider whether or not we should move to async from BeginXXX/EndXXX

When building the SelfHostWcfService at src/System.Private.ServiceModel/tests/Scenarios/SelfHostWcfService/WcfService.csproj, the build artifacts (bin/ and obj/) are placed in same directory as the csproj file, polluting the tree. .gitignore will prevent the build artifacts from getting committed.

Consider changing the project file to write binaries and build artifacts for SelfHostWcfService in the bin/ directory of the repo root.

Repro steps:

• Open Visual Studio 2015 RC
• Open System.Private.ServiceModel\tests\System.Private.ServiceModel.Tests.csproj

In the background, you can see dnx spawning and quitting, repeatedly, running the command:

N:\git\wcf\packages\dnx-coreclr-win-x86.1.0.0-beta5-11682\bin\dnx" "N:\git\wcf\packages\dnx-coreclr-win-x86.1.0.0-beta5-11682\bin\lib\Microsoft.Framework.PackageManager\Microsoft.Framework.PackageManager.dll" restore --packages "N:\git\wcf\packages" "N:\git\wcf\src\System.ServiceModel.Tests.Common\src/project.json"

Where my working directory is N:\git\wcf.

Opening individual projects does work if I delete the solution file at src/System.Private.ServiceModel/System.Private.ServiceModel.sln

It doesn't seem like VS 2013 is affected.

PR #41 effectively moved our experimental scenario branch into master in preparation for allowing further reorganizing and improving in the open. However the test organization in that branch pre-dated this WCF repo becoming public and therefore was not available for community feedback.

The goal of this current issue is to publically reorganize and rename these existing tests into a more rational structure that is similar to how the long-standing WCF samples are organized. Once this reorganization has been reviewed and completed, we will be able to publish guidance for adding new scenario tests.

Support for JSON-LD would be helpful.

PlatformNotSupportedException is thrown is if any Http binding attempts to use AuthenticationSchemes.Negotiate for Kerberos authentication

On desktop, we buffer the output stream so that lots of small writes that are done when serializing using streaming don't become lots of p/invokes. We don't currently buffer the output stream which will affect performance for some streaming scenarios.

Add support for ETW tracing throughout the WCF libraries.
Before starting this issue, please provide a description of the intended approach so that we can discuss it here.

The goal of this item is to come up with a definition of how tests would communicate out of the xUnit runner. The proposed set of guiding principles here are

• Tests that need to make an network call usually need a well defined way of ensuring that the endpoint is running and ready.
• The endpoint/host is configurable and manageable through rest apis
• The endpoint could use the full framework to allow writing wcf services.
• xUnit can communicate with the host through well defined methods

As an example

PUT - http://localhost/initialize/test/ with body {name: "test name", parameters: "..."}
POST - http://localhost/shutdown
GET - http://localhost/log

Looping in folks for thoughts and elaborating further.
@StephenBonikowsky @roncain @iamjasonp

The corefx HttpClient doesn't support pre-authentication with Digest. This requires the request to be sent twice, once for the initial unauthenticated attempt, and a second time in response to the authentication challenge. The http transport doesn't allow the message to be sent twice and HttpClient will hang on the second send attempt.

On .Net 4.5.x and earlier, NetTcp with certificate security was only able to use SSL3.0 and TLS1.0 when upgrading the transport to use certificate security. Support was added to .Net 4.6 to allow specifying the version of SSL/TLS to use. The following properties need to be added (both of type System.Security.Authentication.SslProtocols):

System.ServiceModel.TcpTransportSecurity.SslProtocols
System.ServiceModel.Channels.SslStreamSecurityBindingElement.SslProtocols

This issue is blocked on Certificate support being added to NetTcp.

In all cases within WCF where we use an XmlWriter rather than XmlDictionaryWriter, check that:

• Dispose() is called on the XmlWriter after use
• All Xml tags/elements/contents are manually closed and doesn't rely on Dispose() to do this work

Background:
In desktop .NET, System.Xml.XmlWriter has a virtual Close() method that is overridden by, say, System.Xml.XmlTextWriter that performs actions like closing all outstanding opened elements.

In .NET Core, System.Xml.XmlWriter does not expose a Close() method anymore, and neither does System.Xml.XmlTextWriter. You are expected to call the Dispose() method instead.

We don't need to check XmlDictionaryWriter for this issue. Dispose() == Close() since XmlDictionaryWriter (and therefore, derived classes) has a virtual Close() method. XmlDictionaryWriter.Dispose() will call XmlDictionaryWriter.Close()

In a cross platform environment where there are separate Kerberos realms with a 2-way trust, current WCF implementation does not allow foreign non-windows AD based identities with Kerberos authentication unless the foreign realm identity has a mapped AD account with altSecurityIdentities = "Kerberos:[email protected]"

The issue with this is the unnecessary enforcement to duplicate users between Kerberos realms mapping them together even when there is no real need for that.
This results in unnecessary duplication process work at large enterprises.
There can be cases, where the WCF service only needs to know the identity / authentication and it has it's own implementation of the authorization bits which are not AD based.
In that case, it's not possible to have only the foreign realm by itself / not having it mapped to a Windows AD account.

Example setup:

• A Kerberos realm for a Linux infrastructure with it's own KDC and a Windows AD having it's own Kerberos realm with a 2-way cross realm trust between the 2
• Linux realm has a krb5.config pointing to the Windows AD as KDC for the windows domain
• Linux realm has a [email protected] which is not mapped to an AD account
• Windows AD having an IIS server with Kerberos:Negotiate authentication
• Windows IIS server configured with Service Principal Name ( SPN ) for default port 80 - like HTTP/hostname.windows.fqdn
• IIS host to have a simple WCF service configured with windows integrated auth ( kerberos )
• Linux user making a kerberized connection - curl --negotiate -u : http://iisbox.windows.fqdn/service.svc

Results:

• Since there is a cross realm trust, the Linux client successfully obtain the tickets and makes the request
• IIS authenticates and even logs the linux realm user in the IIS logs
• WCF will try to find the mapped account in AD to get the SID and group membership
• As the account is not mapped to and AD account, WCF will change the identity to be anonymous ( this is the problem )
• the ValidateAnonymityConstraint method will throw an exception, resulting in a 401 unauthenticated HTTP response as the incoming identity cannot be anonymous when windows integrated auth is being used

Other working setups:

• IIS is capable to authenticate and serve requests with Kerberos for non-mapped foregin realm users
• ASP.NET as well and the non-mapped foreign realm identity will be added to the context user with no issue

So this is just a WCF only issue on the Microsoft stack.

Reference code with ValidateAnonymityConstraint
http://referencesource.microsoft.com/#System.ServiceModel/System/ServiceModel/Security/SecurityUtils.cs,87f77a91918ba8d2,references

Proposal
Just because the foreign realm identity can't be mapped to a Windows AD identity, it does not mean that the authentication has failed. Kerberos auth with IIS works fine, so as in ASP.NET. The proposal could be to leave the identity as the foreign realm identity and do not switch to anonymous.
Also don't mix up authentication with authorization, let the app layer decide if the incoming identity can be authorized to make that particular service call.
With .NET Core being cross platform targeted this is definitely going to be an issue in other cases as well, not just the one presented in this issue.

Notes on duplication
While you could get away to just have a placeholder windows AD user account and map all foregin realm identities to that, that is not considered as a best practice by most of the IT Security policies, so the only option remains is a one-to-one mapping between the users from the 2 realms.
Also even if the many-to-one mapping was alowed, how many identites can you map to a single user ?
Plus it's still an extra work to be done for each user in the foreign realm

Question
Once the relevant code is also on Github, would you accept a fix with this proposal or willing to review and fix it ?

The only supported transfer mode on any binding is TransferMode.Buffered.
Not supported are Streamed, StreamedRequest or StreamedResponse

StreamFormatter.SerializeAsyncResult currently throws PlatformNotSupportedException because it required API not available via public contracts. The external implementation it required is small enough that the implementation can be duplicated locally in StreamFormatter

Issue #7 (Support TransferMode.Streamed) depends on this issue being done first.

There are some questions on how unit tests are organized particularly tests of non-public APIs. Also, the unit test cs projects use the convention "*.cs" to pull in all files to compile, this works great except in the project located under System.Private.ServiceModel\tests since that location also contains the scenario tests, this particular project needs to be changed in some fashion.

HttpClient doesn't support pre-authentication with Digest authentication and requires the request entity body to be resent. Currently the Http transport doesn't support re-sending of the request message content after it has been sent once. The result is the client asynchronously await's on a Task which will never complete.

NetTcpBinding does not support NetTcpSecurity.Message and will throw PlatformNotSupportedException

Basic authentication test is currently disabled as the test needs to be run on a domain with domain user. We need to investigate if it's possible to run it without a domain.

This issue was originally submitted by @rCollet as https://github.com/dotnet/corefx/issues/300 but I am taking it over to the WCF issues for further consideration.

The following is an example of a generic extension method I would like to write, but cannot because ClientBase<T> does not inherit from a base class containing the non generic members. It would be very helpful if ClientBase<T> was refactored into ClientBase<T>:ClientBase

using DotNetOpenAuth.OAuth2;
using System;
using System.Net;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.Threading;
using System.Threading.Tasks;

namespace OAuthClient
{
    public static class ExtensionMethods
    {
        public static async Task<T> CallAsync<TClient, TChannel, T>(this TClient wcfClient, Func<TClient, T> predicate, IAuthorizationState authorization, CancellationToken cancellationToken) where TClient : ClientBase<TChannel> where TChannel : class
        {
            if (authorization == null)
            {
                throw new InvalidOperationException("No access token!");
            }

            // Refresh the access token if it expires and if its lifetime is too short to be of use.
            if (authorization.AccessTokenExpirationUtc.HasValue)
            {
                await AuthorizationServer.Client.RefreshAuthorizationAsync(authorization, TimeSpan.FromSeconds(30));
            }

            var httpRequest = (HttpWebRequest)WebRequest.Create(wcfClient.Endpoint.Address.Uri);
            ClientBase.AuthorizeRequest(httpRequest, authorization.AccessToken);

            var httpDetails = new HttpRequestMessageProperty();
            httpDetails.Headers[HttpRequestHeader.Authorization] = httpRequest.Headers[HttpRequestHeader.Authorization];
            using (var scope = new OperationContextScope(wcfClient.InnerChannel))
            {
                OperationContext.Current.OutgoingMessageProperties[HttpRequestMessageProperty.Name] = httpDetails;
                bool isError = true;
                try
                {
                    T result = predicate(wcfClient);
                    // If there is an error on the channel, the close call will throw an exception.
                    wcfClient.Close();
                    isError = false;
                    return result;
                }
                finally
                {
                    // If we have an error on the channel, we cannot close the channel so we abort.
                    // Exceptions that occur will still be raised unmodified.
                    if (isError)
                    {
                        wcfClient.Abort();
                    }
                }
            }
        }
    }
}

When making a call to the extension like:

var client = new ProfileServiceClient();
UserProfile userProfile = 
    await client.CallAsync(c => c.UserProfile(), authorization, response.ClientDisconnectedToken);

The compiler generates the following error at the call to the extension function:

Error 89 'OAuthClient.SampleResourceServer.ProfileServiceClient' does not contain a definition for 'CallAsync' and no extension method 'CallAsync' accepting a first argument of type 'OAuthClient.SampleResourceServer.ProfileServiceClient' could be found (are you missing a using directive or an assembly reference?)

While intellisense shows the extension method as available for ProfileServiceClient, I'm assuming the compiler isn't able to infer the type TChannel (At least not in VS 2012) because there is no parameter associated with that type.

I need to be able to access ClientBase<T> properties like InnerChannel. If the non-generic properties and methods of ClientBase<T> were refactored into a non-generic base class ClientBase, then I could declare the extension method like:

public static async Task<T> CallAsync<TClient, T>(this TClient wcfClient, Func<TClient, T> predicate, IAuthorizationState authorization, CancellationToken cancellationToken) where TClient : ClientBase

The problem with inferring the type of TChannel then goes away. In general I have found it a useful design pattern to place all non-generic members of a generic class in non-generic base, for just this reason.

The default ctor for NetTcpBinding cannot be used yet because it relies on NegotiateStream which is not yet available.

Current workaround is to construct it like this:
NetTcpBinding binding = new NetTcpBinding(SecurityMode.None);

Some suggestions for making the self-hosted server setup script more useful:

• Debuggability/logging - pause after error or redirect all console output from commands like netsh and certutil
• When buildwcftestservice.cmd is called, prevent two elevations
• Allow ability to prevent a server from starting up/getting killed (e.g., if someone spun up their own server for debugging purposes)

Currently the self-hosted WCF service needed to run the scenario (OuterLoop) tests is started and torn down in the main build script. Attempting to F5 debug one of the scenario test projects in VS fails because the service is not running.

This current issue needs to solve these scenarios

• Allow the current behavior to continue to work so the CI machine can continue to run OuterLoop tests
• Allow a developer to hit F5 on a scenario test project and have them succeed
• Allow a developer to msbuild any scenario test project and have the tests succeed

Requirement: we need a mechanism to allow each scenario test to ensure its necessary WCF service endpoints are available. Since the tests will be running in CoreCLR, they cannot launch arbitrary processes themselves. Moreover, we want them decoupled from how that launching works -- we just want them to use Http to say "I need WCF service XYZ running please". There may be multiple endpoints running at once.

Possible approach: consider a WebAPI application that is launched once (TBD) in preparation for running tests. Each individual test suite will be able to issue an Http request (HttpClient) to ask that application to launch a specific service endpoint. The WebAPI application will be running against the full .NET Framework and can handle launching other processes, elevation, etc.

Stretch goal: eventually consider a UI that allows visualizing what services are running and allow access to their logs.

This issue should be used for a design discussion how to achieve this

The ctor currently throws PlatformNotSupportedException

svcutil generates proxy with MessageHeader & MessageBodyMember attributes and does not compile with the DNX Core 5 because there attributes does not exist in System.ServiceModel

Here is a workaround to compile a generated proxy from svcutil in a vNext assembly:

#if DNXCORE50

namespace System.ServiceModel
{
    internal class MessageHeaderAttribute : Attribute
    {
        public string Namespace { get; set; }
    }
}

namespace System.CodeDom.Compiler
{
    internal class GeneratedCodeAttribute : Attribute
    {
        public GeneratedCodeAttribute(string name, string version)
        {

        }
    }

}

namespace System
{
    internal class SerializableAttribute : Attribute
    {

    }

    internal class NonSerializedAttribute : Attribute
    {

    }
}

namespace System.Diagnostics
{
    internal class DebuggerStepThroughAttribute : Attribute
    {

    }
}

namespace System.ComponentModel
{
    internal class DesignerCategoryAttribute : Attribute
    {
        public DesignerCategoryAttribute(string name)
        {

        }
    }

    internal class BrowsableAttribute : Attribute
    {
        public BrowsableAttribute(bool browsable)
        {

        }
    }
}

namespace System.Runtime.Serialization
{
    internal interface IExtensibleDataObject
    {

    }

    internal class ExtensionDataObject : IExtensibleDataObject
    {

    }

    internal class OptionalFieldAttribute : Attribute
    {

    }
}

#endif

The existing set of scenario tests have been moved a couple of times now, they were named based on their original locations which may no longer make sense for some of them. Revisit the tests and re-name the ones that need it.

All tests that are currently marked with [Fact(Skip="some reason")] need to be marked with [ActiveIssue] and the Skip reason removed. See CoreFx repo for examples. Also verify the ActiveIssue attribute exists in our repo and clone from build-tools if not.

CoreFx and CoreClr are moving their wiki content into the repo itself, under a documentation folder. The WCF repo should also do this. It is possible our README.md and Contributing.md's might now point to non-existant locations in CoreFx, so they will need to be fixed at the same time.

For references see CoreFx PR dotnet/corefx#1879

SecurityBindingElement is not yet supported and throws PlatformNotSupportedException

We want the OSS codebase to be able to build both CoreCLR and NET Native versions. The default will be CoreCLR but using MsBuild properties set externally we want the ability to build for NET Native too. An example of this is https://github.com/dotnet/corefx/tree/master/src/System.IO.FileSystem

Message level security is not currently supported.
Attempting to use it will throw PlatformNotSupportedException

NetTcpBinding does not support MessageSecurityOverTcp.ClientCredentialType and will throw PlatformNotSupportedException if the property is read or set.

Our scenario tests will require the ability to redirect the URL of the test service to alternate machines. One can also imagine other test inputs that might feed some [Theory] based test.
One technique to investigate is a pre-build step that accepts MSBuild properties of a known format, generates a temporary .cs file with the information (a Dictionary?), and adds that file to the @(Compile) collection. The tests could be written to consult the dictionary for expected names. Also we could create a [Theory] style test that pulls multiple values. The implementation should not be tied only to scenario tests but available to all tests.

This would be more generally useful than just for WCF, so we should consider working with https://github.com/dotnet/buildtools

Add support for Duplex communication to NetTcpBinding

Its base class (SecurityBindingElement) throws PlatformNotSupported in the ctor.

We need to be able to launch and run tests against a WCF test service that allows us to test Kerberos. This issue needs to consider how to configure a machine for this service, launch this service, and identify the tests that require this service (probably custom xunit traits like OuterLoop).

Let's use this issue to discuss the approach and open other issues as appropriate.

Customer has a large deployment of WCF services that use WsHttpBinding & WsFederationHttpBinding. They are currently developing.NET Core based front-end Web APIs (using ASP.NET 5) that would have to consume these services. Without support for these WS-* bindings, there is no way to call these services securely using federated security. Enabling WS-* on the WCF client would enable these interop scenarios for large enterprises.

HttpTransportBindingElement uses HttpClient to make the requests to the server. HttpClient will throw an exception if HttpRequestMessage has it's Content property not null when making a GET request. Currently we always set the Content property regardless of HTTP verb.