Ik heb een probleem bij het gebruik van een WCF-aanroep van een Windows-service naar mijn WCF-service die op mijn webserver wordt uitgevoerd. Deze oproep werkt al een aantal weken, maar stopte toen plotseling met werken en heeft sindsdien niet meer gewerkt.
De uitzondering die ik krijg is:
Algemene fout opgetreden System.ServiceModel.CommunicationException: er is een fout opgetreden tijdens het maken van het HTTP-verzoek
en dan staat er
Dit kan te wijten zijn aan het feit dat het servercertificaat niet correct is geconfigureerd met HTTP.SYS in het geval van HTTPS. Dit kan ook worden veroorzaakt door een mismatch van de beveiligingsbinding tussen de client en de server.
De beveiliging die ik aan beide kanten gebruik is wsHttpBinding, zonder enige vorm van codering. Het gebruikt ook gewoon HTTP – niet HTTPS, dus ik weet niet zeker waarom het klaagt over HTTPS.
De rest van de binnenste uitzonderingsstapel is:
SystemNet.WebException: de onderliggende verbinding is gesloten: er is een onverwachte fout opgetreden bij het verzenden.
—> System.IO.IOException: kan geen gegevens naar de transportverbinding schrijven: er is een ongeldig argument opgegeven.
—> System.Net.Sockets.SocketException: er is een ongeldig argument opgegeven bij System.Net.Sockets.Socket.MultipleSend(BufferOffsetSize[] buffers, SocketFlags socketFlags) bij System.Net.Sockets.NetworkStream.MultipleWrite(BufferOffsetSize[] buffers)
Ik moet er ook rekening mee houden dat het punt in mijn programma waar dit gebeurt zich op de regel “Uitvoeren” van de aanroep naar de webservice bevindt – dat wil zeggen, zodra ik de webservice aanroep en het ingepakte DataContract doorgeef object, het ontploft.
Het enige dat deze service doet, is een grote hoeveelheid XML doorgeven (doorgegeven als een .NET-object aan de aanroep aan de clientzijde), waarmee het vervolgens wat werk doet. Waarschijnlijk wordt ongeveer 100-200k aan XML verzonden. Ik heb de limieten voor de gegevensgrootte aan beide kanten verhoogd tot meer dan 6 MB, maar dat leek niet te helpen.
Enig idee?
Wat meer informatie over dit probleem:
Als we de clientomgeving lokaal dupliceren, merken we dat we geen grote hoeveelheden XML kunnen uploaden, tenzij we de volgende wijzigingen aanbrengen:
1. Stel op de server de “maxRequestLength” in op 100 MB (veel hoger dan we verzenden)
2. Op de client stellen we de waarde van maxItemsInObjectGraph onder de tag dataContractSerializer in op “2147483646”.
Met deze wijzigingen wordt onze lokale installatie succesvol geüpload. De installatie van de client op hun server mislukt echter nog steeds. Wat interessant is om op te merken, is dat zodra we de maxRequestLength-waardewijziging op de server hadden aangebracht, onze testinstallatie een fout begon te geven die specifiek betrekking had op de maxItemsInObjectGraph-instelling. Terwijl op de server van onze klant nog steeds de originele “HTTP.sys”-fout optreedt.
Zoals ik al eerder heb opgemerkt, gebruiken we helemaal geen SSL, en er zijn nog 2 andere webservices die XML op dezelfde manier uitvoeren en uploaden. Aangezien de niet-werkende service-oproep echter meer gegevens verzendt, lijkt dit een probleem met de grootte te zijn.
Als het probleem dat de client heeft echter hetzelfde probleem was als onze testinstallatie, begrijp ik niet waarom de clientfoutmelding niet gerelateerd zou zijn aan de ObjectGraph-fout.
Is het mogelijk dat we gewoon de generieke “ongeldige parameter” “HTTP.sys”-fout krijgen voor elke mogelijke fout op de client (dat wil zeggen dat hij ook echt de objectGraph-fout krijgt, maar deze gewoon niet laat zien? )
Antwoord 1, autoriteit 100%
We hadden dit probleem omdat de hostserver was bijgewerkt om TLS V1.2 te gebruiken en we verbinding maakten via standaard SSL. Dit was een update die werd gemaakt als onderdeel van het testen van de pennen van de sites. We zagen het probleem in de codeverbinding, maar niet bij browsers die naar de wsdl gingen.
Onderstaande code is opgelost:
if (System.Net.ServicePointManager.SecurityProtocol == (SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls))
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls13;
Genomen vanaf hier: SSL-terugval uitschakelen en alleen TLS gebruiken voor uitgaande verbindingen in .NET? (Verzachting van de poedel)
Antwoord 2, autoriteit 36%
Ik had hetzelfde probleem met een service die draait op IIS 7
de service maakt verbinding met servers van meerdere leveranciers (sommige SSL, andere niet)
bij het toevoegen van een nieuwe van deze (deze nieuwe leverancier was TLS 1.2) kreeg ik de foutmelding nadat er een paar verzoeken waren gedaan aan de originele servers (SSL).
Om dit te bevestigen heb ik simpelweg het System.Net.ServicePointManager.SecurityProtocolgeregistreerd vóór elk verzoek aan elke leverancier.
Low en zie na het herstarten van de service (of het herstarten van de applicatiepool) zou ik de output Ssl3, Tlskrijgen, maar na een paar verzoeken aan de oorspronkelijke leveranciersservers veranderde dit in Ssl3en verzoeken aan de TLS-service gaven de fout.
Om het op te lossen deed ik gewoon wat user369142 suggereerde.
Voor elk verzoek aan de nieuwe server:
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12 | SecurityProtocolType.Ssl3;
en geen fouten meer.
Antwoord 3, autoriteit 17%
In mijn geval moest ik SchUseStrongCryptoinschakelen voor .Net
Dit dwingt de server om verbinding te maken met behulp van TLS 1.0, 1.1 of 1.2. Zonder SchUseStrongCryptoingeschakeld, probeerde de verbinding SSL 3.0 te gebruiken, wat was uitgeschakeld op mijn externe eindpunt.
Registersleutels om gebruik van sterke cryptovaluta mogelijk te maken:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NetFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SchUseStrongCrypto"=dword:00000001
Antwoord 4, autoriteit 11%
Had dit probleem met een echte HTTPS-binding en dezelfde uitzondering met “Dit kan te wijten zijn aan het feit dat het servercertificaat niet correct is geconfigureerd met HTTP.SYS in het geval van HTTPS…”.
Na alles dubbel te hebben gecontroleerd in code en configuratie, lijkt het erop dat de foutmelding niet zo misleidend is als de innerlijke uitzonderingen, dus na een snelle controle zijn we erachter gekomen dat de poort 443 was vastgehaakt door skype (op de dev-server). Ik raad je aan om te kijken wat het verzoek tegenhoudt (Fiddler kan hier helpen) en ervoor te zorgen dat je het servicefront kunt bereiken (bekijk de .svc in je browser) en zijn metadata.
Veel succes.
Antwoord 5, autoriteit 7%
Voor ons was deze fout omdat de computer van de ontwikkelaar waarop de service werd uitgevoerd, IIS had geconfigureerd om poort 443 alleen op 127.0.0.1 te binden.
Klik in IIS Manager met de rechtermuisknop op de website en kies Bindingen bewerken. Als de invoer voor poort 443het IP-adres 127.0.0.1heeft, wijzigt u dit in *.
Antwoord 6, autoriteit 7%
Wijzig uw clienttoepassing in 4.5 en hoger.
ALS u 4.5 bent, gebruik dan: System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls12 / Tls1.1 / Tls1.0 indien nodig of u kunt uw toepassing upgraden naar boven 4.6.1.
Antwoord 7, autoriteit 6%
Na veel zoeken en het ijdel gebruiken van de naam van de heer kreeg ik het eindelijk. Ik heb TLS 1.2 geïnstalleerd op de server waarop mijn wcf-service draait. Mijn client was correct geconfigureerd, maar het was gebouwd op .NET 4.5. 1 terwijl de wcf op .NET 4.6.1 stond. Zowel client als server moeten dezelfde .NET-versie hebben als u TLS 1.2 gebruikt. Ik hoop dat het ooit iemand helpt 🙂
Antwoord 8, autoriteit 5%
We hadden onlangs bijna exact hetzelfde probleem en het bleek te worden veroorzaakt door Microsoft-update KB980436 (http ://support.microsoft.com/KB/980436) wordt geïnstalleerd op de oproepende computer. De oplossing voor ons, behalve het volledig verwijderen, was om de instructies op de KB-site te volgen om de UseScsvForTls DWORD in het register in te stellen op 1. Als u ziet dat deze update in uw oproepsysteem is geïnstalleerd, wilt u het misschien proberen .
Antwoord 9, autoriteit 3%
Als uw WCF-service .net Framework 4.0 gebruikt en iemand TLS 1.0 op de server heeft uitgeschakeld, ziet u deze uitzondering. Omdat .net 4.0 de hogere versies van TLS niet ondersteunt.
Ondersteunde protocollen: https://msdn.microsoft.com/en-us/library/system.security.authentication.sslprotocols(v=vs.100).aspx
Antwoord 10, autoriteit 3%
Ik had dit probleem bij het uitvoeren van oudere XP SP3-boxen tegen zowel IIS als glassfish op Amazon AWS. Amazon heeft hun standaard load balancer-instellingen gewijzigd om de DES-CBC3-SHA-codering NIET in te schakelen. U moet dat inschakelen op Amazon ELB als u oudere XP TLS 1.0 wilt laten werken tegen ELB voor HTTPS, anders krijgt u deze foutmelding. Cijfers kunnen op ELB worden gewijzigd door naar de listener-tab in de console te gaan en op cipher te klikken naast de specifieke luisteraar die je probeert te laten werken.
Antwoord 11, autoriteit 2%
In plaats van het beveiligingsprotocol expliciet in te stellen, is een betere manier om het web.config <compilation targetFramework=”4.5″> of hoger.
Antwoord 12, autoriteit 2%
Ik heb mijn probleem opgelost door mijn .NetFramework-versie te upgraden van 4.5.2 naar 4.7.2.
Antwoord 13
Ik heb deze specifieke uitzonderingen gezien met betrekking tot problemen met Complex DataType, zie het volgende bericht als u verzamelingen of opsommingen doorgeeft:
Antwoord 14
Als je de overdrachtsmodus = gestreamd gebruikt, probeer deze dan te wijzigen in gebufferd.
Als dit niet het probleem is, zou je dan je configuratie kunnen posten.
Antwoord 15
Omdat alles wekenlang goed werkte en daarna stopte, betwijfel ik of dit iets met je code te maken heeft. Misschien treedt de fout op wanneer de service geactiveerdis binnen IIS/ASP.NET, niet wanneer uw code wordt aangeroepen. De runtime kan gewoon de configuratie van de website controleren en een algemene foutmelding geven die niets met de service te maken heeft.
Mijn vermoeden is dat een certificaat is verlopen of dat de bindingen niet goed zijn ingesteld. Als de website verkeerd is geconfigureerd voor HTTPS, of uw code deze nu gebruikt of niet, krijgt u mogelijk deze foutmelding.
Antwoord 16
Probeer door de service te bladeren in de browser en in de Https-modus, als het niet brow-sable is, dan bewijst dit de reden voor deze fout. Om deze fout op te lossen, moet u het volgende controleren:
- https-poort, controleer of deze niet door andere bronnen (website) wordt gebruikt
- Controleer of het certificaat voor https correct is geconfigureerd of niet (controleer ondertekeningsautoriteit, zelfondertekend certificaat, gebruik meerdere certificaten)
- controleer WCF-servicebinding en configuratie voor Https-modus
Antwoord 17
Ons probleem was gewoon dat het poortnummer op het eindpunt onjuist was ingesteld op 8080. We hebben het gewijzigd in 8443 en het werkte.
Antwoord 18
We hebben deze fout gekregen van de buitenste API…
Niets hierboven heeft ons geholpen, uiteindelijk was het probleem dat het verzoek te groot was!!
Dus controleer de foutmassage van de server als niets boven helpt…
Antwoord 19
Onlangs dit meegemaakt:
System.ServiceModel.CommunicationException:
Er is een fout opgetreden tijdens
het HTTP-verzoek indienen bij http://example.com/WebServices/SomeService.svc. Dit kan te wijten zijn aan
aan het feit dat het servercertificaat niet correct is geconfigureerd
met HTTP.SYS in het geval van HTTPS. Dit kan ook worden veroorzaakt door een
mismatch van de beveiligingsbinding tussen de client en de server.—> System.Net.WebException: De onderliggende verbinding is gesloten: er is een onverwachte fout opgetreden bij het verzenden.
—> System.IO.IOException: kan geen gegevens naar de transportverbinding schrijven: een bestaande verbinding is geforceerd gesloten door de externe
gastheer.
Ik hoorde van een beheerder dat de IIS-toepassingsgroep die de webservice hostte, automatisch werd gerecycleerd nadat het geheugen bijna vol was. De fout op de client deed zich voor toen de toepassingsgroep werd hergebruikt.
Het vergroten van het beschikbare geheugen voor de applicatiepool loste het onmiddellijke probleem op.
Antwoord 20
Onze applicaties zijn onlangs van SSL naar TLS geforceerd via een update van het netwerkapparaat (F5). We hebben deze fout verholpen door de zelfondertekende certificaten opnieuw te genereren. Ik hoop dat dit iemand in de toekomst helpt om het probleem op te lossen, aangezien we meerdere onderhoudsvensters hebben besteed aan het oplossen van problemen voordat we tot de oplossing kwamen.
Antwoord 21
Onlangs dit meegemaakt:
System.ServiceModel.CommunicationException:
Er is een fout opgetreden bij het maken van het HTTP-verzoek aan http://example.com/WebServices/SomeService. svc. Dit kan te wijten zijn aan het feit dat het servercertificaat niet correct is geconfigureerd met HTTP.SYS in het geval van HTTPS. Dit kan ook worden veroorzaakt door een mismatch van de beveiligingsbinding tussen de client en de server.
—> System.Net.WebException: De onderliggende verbinding is gesloten: er is een onverwachte fout opgetreden bij het verzenden.
—> System.IO.IOException: kan geen gegevens naar de transportverbinding schrijven: een bestaande verbinding is geforceerd gesloten door de externe host.
Onze licentie van de bluecoat-proxy is verlopen! dus het was niet mogelijk om de externe partij (internet) te bereiken.
Antwoord 22
We hadden hetzelfde probleem en in ons geval is het opgelost door het certificaat opnieuw te installeren en de binding opnieuw te maken.
Wat ons daarheen leidde, was het feit dat zelfs het krijgen van een eenvoudig png-afbeeldingsbestand op de site dezelfde fout gaf.