Mam problem z używaniem wywołania WCF z usługi systemu Windows do mojej usługi WCF działającej na moim serwerze sieci Web. To wezwanie działało przez kilka tygodni, ale nagle przestało działać i od tamtej pory nie działa.
Wyjątek, który otrzymuję, to:
Wystąpił błąd ogólny System.ServiceModel.CommunicationException: Wystąpił błąd podczas wysyłania żądania HTTP
a potem mówi
Może to być spowodowane faktem, że certyfikat serwera nie jest poprawnie skonfigurowany z HTTP.SYS w przypadku HTTPS. Może to być również spowodowane niezgodnością powiązania zabezpieczeń między klientem a serwerem.
Zabezpieczenia, których używam na obu końcach, to wsHttpBinding, bez żadnego szyfrowania. Używa też tylko protokołu HTTP, a nie HTTPS, więc nie jestem pewien, dlaczego narzeka na HTTPS.
Reszta wewnętrznego stosu wyjątków to:
SystemNet.WebException: połączenie podstawowe zostało zamknięte: wystąpił nieoczekiwany błąd podczas wysyłania. ---> System.IO.IOException: nie można zapisać danych w połączeniu transportowym: podano nieprawidłowy argument. ---> System.Net.Sockets.SocketException: podano nieprawidłowy argument w System.Net.Sockets.Socket.MultipleSend (bufory BufferOffsetSize [], SocketFlags socketFlags) w System.Net.Sockets.NetworkStream.MultipleWrite (BufferOffsetSize [] bufory)
Powinienem również zauważyć, że punkt w moim programie, w którym to się dzieje, znajduje się w wierszu „Execute” wywołania usługi sieciowej - to znaczy zaraz po wywołaniu usługi sieciowej i przekazaniu jej opakowanego obiektu DataContract, wysadza.
Wszystko, co robi ta usługa, to przekazywanie dużej ilości XML (przekazywanej jako obiekt .NET do wywołania po stronie klienta), z którym następnie wykonuje jakąś pracę. Prawdopodobnie przesyłanych jest około 100-200 tys. Plików XML. Podniosłem limity rozmiarów danych na obu końcach do ponad 6 megabajtów, ale to nie pomogło.
Jakieś pomysły?
Więcej informacji na ten temat:
Kiedy lokalnie powielamy środowisko klienta, okazuje się, że nie możemy przesłać dużych ilości XML, chyba że dokonamy następujących zmian: 1. Na serwerze ustaw "maxRequestLength" na 100 MB (dużo więcej niż wysyłamy) 2. Włącz klienta, ustawiliśmy wartość maxItemsInObjectGraph pod tagiem dataContractSerializer na „2147483646”.
Dzięki tym zmianom nasza lokalna instalacja zostanie pomyślnie przesłana. Jednak instalacja klienta na serwerze nadal kończy się niepowodzeniem. Co ciekawe, gdy zmieniliśmy wartość maxRequestLength na serwerze, nasza instalacja testowa zaczęła generować błąd związany z ustawieniem maxItemsInObjectGraph. Podczas gdy na serwerze naszego klienta nadal występuje pierwotny błąd „HTTP.sys”.
Jak zauważyłem wcześniej, w ogóle nie używamy SSL, a istnieją 2 inne wywołania usług internetowych, które wykonują i przesyłają XML w ten sam sposób. Jednak ponieważ niedziałające wywołanie serwisowe przesyła więcej danych, wydaje się, że jest to problem z rozmiarem.
Jeśli jednak problem, który ma klient, był taki sam, jak nasza instalacja testowa, nie rozumiem, dlaczego komunikat o błędzie klienta nie miałby być powiązany z błędem ObjectGraph.
Czy to możliwe, że po prostu otrzymujemy ogólny błąd „nieprawidłowy parametr” „HTTP.sys” dla każdego możliwego błędu na kliencie (tj. Tak naprawdę pojawia się również błąd objectGraph, ale po prostu go nie wyświetla?)
źródło
Odpowiedzi:
Mieliśmy ten problem, ponieważ serwer hosta został zaktualizowany do korzystania z protokołu TLS V1.2, a my łączyliśmy się przy użyciu standardowego protokołu SSL. To była aktualizacja dokonana w ramach testów piórkowych stron. Widzieliśmy problem w połączeniu kodu, ale nie przeglądarki przechodzące do wsdl. Poniższy kod rozwiązany:
Zaczerpnięte stąd: Jak wyłączyć rezerwę SSL i używać tylko TLS dla połączeń wychodzących w .NET? (Łagodzenie skutków Pudla)
źródło
using System.Net
do mojego pliku. b) wartość SecurityProtocol to „Default”. Zdecydowałem się usunąć „if” i przypisać SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 bez uprzedniego pytania. HTH, MarceloMiałem ten sam problem z usługą działającą w IIS 7, usługa łączy się z serwerami wielu dostawców (niektóre SSL, niektóre nie) podczas dodawania nowego z nich (tym nowym dostawcą był TLS 1.2). Otrzymałem błąd po kilku żądaniach wykonane na oryginalnych serwerach (SSL).
Aby to potwierdzić, po prostu zapisałem
System.Net.ServicePointManager.SecurityProtocol
przed każdym żądaniem do każdego dostawcy.Niski i po ponownym uruchomieniu usługi (lub ponownym uruchomieniu puli aplikacji) otrzymywałem dane wyjściowe,
Ssl3, Tls
ale po kilku żądaniach do oryginalnych serwerów dostawcy zmieniło się to naSsl3
i żądania do usługi TLS spowodowały błąd.Aby to naprawić, po prostu zrobiłem to, co zasugerował user369142. Przed każdym żądaniem do nowego serwera:
i żadnych więcej błędów.
źródło
Miał ten problem z prawdziwym powiązaniem HTTPS i tym samym wyjątkiem z „Może to wynikać z faktu, że certyfikat serwera nie jest poprawnie skonfigurowany z HTTP.SYS w przypadku HTTPS ...”. Po podwójnym sprawdzeniu wszystkiego w kodzie i konfiguracji, wydaje się, że komunikat o błędzie nie jest tak mylący jak wewnętrzne wyjątki, więc po szybkim sprawdzeniu okazało się, że port 443 został przechwycony przez skype (na serwerze deweloperskim). Radzę przyjrzeć się temu, co wstrzymuje żądanie (Fiddler może tu pomóc) i upewnić się, że możesz dotrzeć do frontu usługi (wyświetl plik .svc w przeglądarce) i jego metadane.
Powodzenia.
źródło
W moim przypadku musiałem włączyć
SchUseStrongCrypto
.Net To zmusza serwer do nawiązywania połączenia przy użyciu TLS 1.0, 1.1 lub 1.2. BezSchUseStrongCrypto
włączonej opcji połączenie próbowało używać protokołu SSL 3.0, który został wyłączony na moim zdalnym punkcie końcowym.Klucze rejestru umożliwiające korzystanie z silnego krypto:
źródło
Dla nas ten błąd był spowodowany tym, że komputer dewelopera, na którym działa usługa, miał skonfigurowane usługi IIS do wiązania portu 443 tylko z portem 127.0.0.1.
W Menedżerze usług IIS kliknij witrynę internetową prawym przyciskiem myszy i wybierz polecenie Edytuj powiązania. Jeśli wpis dotyczący portu
443
ma adres IP127.0.0.1
, zmień go na*
.źródło
Po wielu poszukiwaniach i daremnych poszukiwaniach, w końcu je otrzymałem. Zainstalowałem TLS 1.2 na serwerze, na którym działa moja usługa wcf Mój klient został skonfigurowany poprawnie, ale został zbudowany na .NET 4.5.1, podczas gdy wcf działał na platformie .NET 4.6.1. Zarówno klient, jak i serwer muszą mieć tę samą wersję .NET, jeśli używasz protokołu TLS 1.2. Mam nadzieję, że kiedyś komuś to pomoże :-)
źródło
Zmień aplikację kliencką na 4.5 lub nowszą. JEŚLI masz 4,5 lat, użyj: System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0 według potrzeb lub możesz zaktualizować aplikację do wersji 4.6.1.
źródło
Prawie ten sam problem wystąpił ostatnio i okazało się, że jest on spowodowany przez aktualizację KB980436 firmy Microsoft ( http://support.microsoft.com/KB/980436 ) instalowaną na komputerze wywołującym. Rozwiązaniem dla nas, poza zwykłym odinstalowaniem, było wykonanie instrukcji z witryny KB, aby ustawić wartość DWORD UseScsvForTls w rejestrze na 1. Jeśli zauważysz, że ta aktualizacja jest zainstalowana w systemie wywołującym, możesz spróbować .
źródło
Miałem ten problem podczas uruchamiania starszych skrzynek XP SP3 z usługami IIS i Glassfish na Amazon AWS. Amazon zmienił swoje domyślne ustawienia modułu równoważenia obciążenia, aby NIE włączyć szyfrowania DES-CBC3-SHA. Musisz to włączyć na amazon ELB, jeśli chcesz, aby starszy XP TLS 1.0 działał przeciwko ELB dla HTTPS, w przeciwnym razie pojawi się ten błąd. Szyfry można zmienić w ELB, przechodząc do zakładki słuchacza w konsoli i klikając szyfr obok konkretnego słuchacza, którego próbujesz uruchomić.
źródło
Jeśli usługa WCF korzysta z platformy .NET Framework 4.0 i ktoś wyłączył protokół TLS 1.0 na serwerze, zobaczysz ten wyjątek. Ponieważ .net 4.0 nie obsługuje wyższych wersji TLS.
Obsługiwane protokoły: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx
źródło
ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072; //TLS 1.2
i będzie działać w NET 4.0.Widziałem te szczególne wyjątki związane ze złożonymi problemami typu DataType, zobacz następujący post, jeśli przekazujesz kolekcje lub wyliczenia:
Złożone typy danych
źródło
Jeśli używasz trybu transferu = przesyłany strumieniowo, spróbuj zmienić go na buforowany.
Jeśli to nie jest problem, możesz wysłać swoją konfigurację.
źródło
Ponieważ przez wiele tygodni wszystko działało dobrze, a potem przestało, wątpię, by miało to coś wspólnego z twoim kodem. Być może błąd występuje, gdy usługa jest aktywowana w usługach IIS / ASP.NET, a nie podczas wywoływania kodu. Środowisko wykonawcze może po prostu sprawdzać konfigurację witryny internetowej i generować ogólny komunikat o błędzie, który nie ma nic wspólnego z usługą.
Podejrzewam, że certyfikat wygasł lub powiązania są skonfigurowane nieprawidłowo. Jeśli witryna internetowa jest nieprawidłowo skonfigurowana pod kątem protokołu HTTPS, niezależnie od tego, czy w Twoim kodzie są one używane, czy nie, możesz otrzymać ten błąd.
źródło
Spróbuj przeglądać usługę w przeglądarce iw trybie Https, jeśli nie jest to przeglądarka internetowa, to udowodni przyczynę tego błędu. Teraz, aby rozwiązać ten błąd, musisz sprawdzić:
źródło
Nasz problem polegał na tym, że numer portu w punkcie końcowym był nieprawidłowo ustawiony na 8080. Zmieniono go na 8443 i zadziałało.
źródło
Zamiast jawnie ustawiać protokół zabezpieczeń, lepszym sposobem jest ustawienie pliku web.config <compilation targetFramework = "4.5"> lub nowszego.
źródło
Rozwiązałem problem, aktualizując moją wersję .NetFramework z 4.5.2 do 4.7.2.
źródło
Niedawno tego doświadczyłem:
Dowiedziałem się od administratora, że pula aplikacji IIS, na której była hostowana usługa sieciowa, została automatycznie przywrócona po wyczerpaniu pamięci. Błąd na kliencie wystąpił podczas odtwarzania puli aplikacji.
Zwiększenie pamięci dostępnej dla puli aplikacji rozwiązało natychmiastowy problem.
źródło
Nasze aplikacje zostały niedawno wymuszone z SSL na TLS przez aktualizację systemu operacyjnego urządzenia sieciowego (F5). Naprawiliśmy ten błąd, ponownie generując certyfikaty z podpisem własnym. Mam nadzieję, że pomoże to komuś w przyszłości rozwiązać ten problem, ponieważ przed znalezieniem rozwiązania spędziliśmy wiele czasu na rozwiązywanie problemów z oknami obsługi.
źródło
Niedawno tego doświadczyłem:
System.ServiceModel.CommunicationException:
Wystąpił błąd podczas wysyłania żądania HTTP do http://example.com/WebServices/SomeService.svc . Może to wynikać z faktu, że certyfikat serwera nie jest poprawnie skonfigurowany z HTTP.SYS w przypadku HTTPS. Może to być również spowodowane niezgodnością powiązania zabezpieczeń między klientem a serwerem.
---> System.Net.WebException: połączenie podstawowe zostało zamknięte: wystąpił nieoczekiwany błąd podczas wysyłania.
---> System.IO.IOException: nie można zapisać danych w połączeniu transportowym: istniejące połączenie zostało wymuszone przez hosta zdalnego.
Nasza licencja na proxy bluecoat wygasła! więc nie można było nawiązać połączenia ze stroną zewnętrzną (internet).
źródło
Mieliśmy ten sam problem iw naszym przypadku został on rozwiązany przez ponowną instalację certyfikatu i ponowne utworzenie powiązania. Doprowadziło nas do tego, że nawet pobranie prostego pliku obrazu png na stronie daje ten sam błąd.
źródło