Pytanie w sprawie .net-3.5, iis-6, wcf – WCF Typed Faults i Internal Server Error code 500?

5

Oto moja koperta odpowiedzi:

<s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/">
   <s:Body>
      <s:Fault>
         <faultcode>s:Client</faultcode>
         <faultstring xml:lang="en-US">The creator of this fault did not specify a Reason.</faultstring>
         <detail>
            <ServiceFault xmlns="http://schemas.datacontract.org/2004/07/Zagat.Services.FaultException" xmlns:i="http://www.w3.org/2001/XMLSchema-instance">
               <ReasonCollection xmlns:a="http://schemas.datacontract.org/2004/07/Zagat.Enterprise.Domain"/>
               <ReasonMessage>Credentials are not valid</ReasonMessage>
            </ServiceFault>
         </detail>
      </s:Fault>
   </s:Body>
</s:Envelope>
enter code here

Oto mój nagłówek:

HTTP/1.1 500 Internal Server Error
Date: Wed, 01 Jul 2009 17:55:33 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: text/xml; charset=utf-8
Content-Length: 564

Jak mogę uzyskać IIS, aby zwrócić 200 zamiast 500? Mój kod działa na serwerze, wysyłam tylko błąd do klienta do przetworzenia.

Daniel

Czy otrzymujesz tę wiadomość w wyjątku ProtocolException? Miałem problem z tymi wyjątkami, ponieważ zawsze otrzymałem kod HTML w komunikacie wyjątku. Teraz zakładam, że każdy wyjątek protokołu pochodzi z tego kodu HTML i analizuję go, aby uzyskać prawdziwy komunikat.stackoverflow.com/questions/998065/… sebagomez

Twoja odpowiedź

2   odpowiedź
1

Przypominam sobie, że protokół SOAP jest wysyłany jako kod 500.

Błędy nie są odpowiedzią na sukces. Wskazują charakter awarii.

5

Możesz łatwo dostosować obsługę błędów WCF. WidziećModyfikowanie kodów błędów HTTP, część 1 iCzęść 2 autorstwa Nicholasa Allena, Indigo Blog;WCF: Wyrzucanie wyjątków z WebHttpBinding autor: Andre de Cavaignac; iObsługa wyjątków w usłudze sieci Web WCF Brajendra Singh.

Ok, ale czy zwróciłeś błąd SOAP dla REST? Zwróć to, co lubisz dla REST, ale protokół SOAP ogranicza, które kody HTTP mogą być używane w jakich okolicznościach. Jeśli chcesz coś zwrócićwygląda mniej więcej tak jak usterka SOAP, ale niebyć jeden, a następnie złap wyjątek i po prostu zwróć swój własny niestandardowy XML. Ale jeśli oczekujesz, że klient zobaczy Twój błąd SOAP jako Błąd SOAP, musisz użyć poprawnego kodu statusu. John Saunders
Zrobiłem POX lub JSON dla REST. Sam protokół SOAP jest strukturą przesyłania wiadomości, więc nie określa statusu HTTP. Możesz użyć e-maila lub gołębia do przenoszenia wiadomości SOAP.w3.org/TR/soap12-part1 Część określająca 500 to powiązanie HTTP SOAP w części 2 specyfikacji:w3.org/TR/soap12-part2/#soapinhttp. Z pewnością nie polecam używania 500, ale jeśli @DiVita chce to zrobić, to zależy od niego. Może to być konieczne, ponieważ niektóre platformy, w tym .NET 2.0 IIRC, tracą treść wiadomości odpowiedzi. FaultException (TDetail) to funkcja .NET 3.x. Eugene Yokota
To zależy. Pierwszą rzeczą, o której mówi powiązanie SOAP HTTP, jest to, że jest opcjonalne. Zobacz 7.1.1 Opcjonalność: Wiązanie HTTP SOAP jest opcjonalne, a węzły SOAP NIE są wymagane do jego implementacji. Można powiedzieć, że węzeł SOAP, który poprawnie i całkowicie implementuje powiązanie HTTP SOAP „jest zgodny z powiązaniem HTTP protokołu SOAP 1.2”. Eugene Yokota
@ eed3si9n: Całe powiązanie jest opcjonalne - a nie jego fragmenty. John Saunders

Powiązane pytania