Czy możemy tworzyć niestandardowe kody stanu HTTP?

92

Mam usługę REST i WCF i chcę wysłać niestandardowy kod stanu na podstawie operacji.

Przykład, gdy część weryfikacji nie powiedzie się, chcę wysłać HTTP 444, a gdy autoryzacja się nie powiedzie, chcę wysłać HTTP 455

Pytanie brzmi, w jaki sposób mamy to sprawdzić dla usług sieciowych SOAP i REST.

Na kliencie, jak działa kod błędu, ponieważ podczas wysyłania HTTP 400/500 z usługi WCF (przy użyciu protokołu SOAP) na kliencie jest zgłaszany wyjątek pokazujący kod stanu.

Jeśli teraz wyślę nowy niestandardowy kod statusu, jak klient sobie z tym poradzi?

c#  asp.net  wcf  http  wcf-rest 
— Rajesh
źródło
3
Czy jest to usługa, którą udostępniasz światu, czy też kontrolujesz również wszystkich klientów?
— Rup

Odpowiedzi:

109

Tak, pod warunkiem, że szanujesz klasę - to znaczy 2xx dla sukcesu, 4xx dla błędu klienta itp. Możesz więc zwrócić niestandardowe kody błędów 4XX (najlepiej te, które są nieprzypisane) dla warunków błędów Twojej własnej aplikacji.

Cytat z [RFC 2616] [1]:

„Kody statusu HTTP są rozszerzalne. Aplikacje HTTP nie muszą rozumieć znaczenia wszystkich zarejestrowanych kodów statusu, chociaż takie rozumienie jest oczywiście pożądane. Jednak aplikacje MUSZĄ rozumieć klasę dowolnego kodu stanu, jak wskazuje pierwsza cyfra, i traktować każda nierozpoznana odpowiedź jest równoważna z kodem statusu x00 tej klasy, z wyjątkiem tego, że nierozpoznana odpowiedź NIE MOŻE zostać zapisana w pamięci podręcznej. Na przykład, jeśli klient otrzyma nierozpoznany kod statusu 431, można bezpiecznie założyć, że coś jest nie tak z żądaniem i traktuj odpowiedź tak, jakby otrzymała kod statusu 400. "

Klasa'

  • 1xx: Informacyjne - otrzymano żądanie, kontynuacja procesu

  • 2xx: Sukces - akcja została pomyślnie odebrana, zrozumiana i zaakceptowana

  • 3xx: Przekierowanie - należy podjąć dalsze działania, aby zrealizować żądanie

  • 4xx: Błąd klienta - żądanie zawiera złą składnię lub nie można go spełnić

  • 5xx: Błąd serwera - serwer nie spełnił pozornie prawidłowego żądania [1]:

http://tools.ietf.org/html/rfc2616#section-6.1.1

— ChrisNY
źródło
2
Nie używaj niezarejestrowanych kodów statusu, z wyjątkiem testów.
— Julian Reschke,
1
ChrisNY: cóż, jeśli korzystasz z niezarejestrowanych kodów statusu przy korzystaniu z HTTP, może dojść do zerwania, jeśli ktoś inny użyje tego samego kodu w innym celu. Jeśli potrzebujesz bardziej szczegółowych informacji o błędzie, możesz nadal umieścić je w ładunku (patrz na przykład tools.ietf.org/html/draft-nottingham-http-problem-06 )
— Julian Reschke,
21
@ChrisNY: Większość aplikacji internetowych jest zaprojektowana do pracy z jednym klientem (Twój kod javascript / ajax) i jednym serwerem (Twoim serwerem), więc używanie niestandardowego kodu statusu jest całkowicie w porządku. W takich sytuacjach nie jest nawet możliwe, aby „ktoś inny” spowodował „awarię” przy użyciu tego samego kodu statusu.
— AR
2
Ten cytat nie mówi, że możesz tworzyć własne kody, ale mówi, że Twoja aplikacja nie musi wiedzieć, czym jest każdy zarejestrowany kod, o ile przestrzega klasy kodu i zgłasza błąd dla 4xx itp. Pomijając to, Jedynym problemem, jaki widziałem, jest to, że w przyszłości jeden z tych kodów zostanie oficjalnie przypisany, a funkcjonalność przeglądarki / javascript może ulec zmianie. Np. atak 494 DDNS zatrzyma całą komunikację, przeglądarka może to zobaczyć i zablokować js rozpoczęcie dalszej komunikacji z tym adresem IP. Bardzo mało prawdopodobne, ale nie możesz być w 100%, wydaje się, że Twitter myśli, że można to zrobić 420 Popraw swój spokój
— Matt
1
Specyfikacja mówi, że możesz tworzyć własne kody i używa kodu 471 jako przykładu. Mówi, że każdy nierozpoznany błąd 4xx jest równoważny 400.
— Jeff Lowery
32

Odradzam tworzenie własnych kodów statusu HTTP, gdy istnieją już odpowiednie kody dla rzeczy, które chcesz zrobić w swoim przykładzie.

Z https://tools.ietf.org/html/rfc4918#section-11.2 :

Kod statusu 422 [Unprocessable Entity] oznacza, że ​​serwer rozumie typ zawartości jednostki żądania (stąd kod statusu 415 [Unsupported Media Type] jest nieodpowiedni), a składnia jednostki żądania jest poprawna (stąd 400 [Bad Request ] kod stanu jest nieodpowiedni), ale nie mógł przetworzyć zawartych instrukcji. Na przykład ten warunek błędu może wystąpić, jeśli treść żądania XML zawiera poprawnie sformułowane (tj. Poprawne składniowo), ale semantycznie błędne instrukcje XML.

Można argumentować, że „niemożność przetworzenia” może wynikać z błędu walidacji.

— Julian Reschke
źródło
10
Błąd autoryzacji to 401, a nie 403. 403 jest zabronione, gdzie autoryzacja nie rozwiązałaby problemu.
— Neil Hickman
6
401 dotyczy nieudanego uwierzytelnienia (pomimo nazwy).
— Julian Reschke
1
401 to „Zaloguj się (ponownie)”
— CodesInChaos
19

Tak, możesz dodać niestandardowe kody błędów. Jeśli to możliwe, użyj kodów, które już istnieją, a jeśli deklarujesz nowe, uważaj, aby uniknąć kolizji.

Należy jednak pamiętać, że niektóre serwery proxy filtrują nieznane kody . Miałem problemy z użytkownikami, którzy znajdowali się za serwerami proxy, które mapowały 5XX na 500 i 4XX na 404. To spowodowało, że moje wywołania Ajaxa kończyły się niepowodzeniem w sprawdzaniu kodu stanu.

— fmsf
źródło
tak, proxy są do niczego. Nie znam nazwy implementacji proxy, ale zinterpretowało ono nasz niestandardowy kod stanu i nie wysłało odpowiedzi do klienta.
— asgs
16

Niektóre aplikacje dodają własne kody odpowiedzi z zakresu 600-799. Sprawdź na przykład listę kodów odpowiedzi z KeyNote tutaj

Kody błędów zdefiniowane w opisie odnośników (600-799)

600: CONNECTION ERROR - This indicates a general connection error
601: INCOMPLETE ERROR - This indicates sever sends an incomplete page/object (as indicated by Content-Length header)
602: UNEXPECTED CLOSE ERROR - This indicates socket connection has been closed unexpectedly
603: REFUSED ERROR - This indicates a request to connect to the server is refused
604: TIMEOUT ERROR - This indicates there is no activity in socket connection in 3 minutes
605: REDIRECT ERROR - This indicates an error in redirect HTTP header
606: SSL ERROR - This indicates a general error in SSL
607: HEADER ERROR - This indicates a malformed HTTP header
608: EMPTY RESPONSE ERROR - This indicates server doesn't send any response after a request is sent
609: UNKNOWN HOST ERROR - This indicates socket receives an unknown host error from DNS
610: NO ROUTE TO HOST ERROR - This indicates a no route to host error was received while attempting to open a socket
611: SOCKET ERROR - This indicates a general socket error
612: FRAME LOOP ERROR - This indicates a page has a frame loop (frame A includes Frame B that includes Frame A)
613: REDIRECT LOOP ERROR - This indicates a page has a redirect loop (page A redirects to page B that redirects to page A)
614: CONNECTION RESET ERROR - This indicates socket receive a reset signal from the server
615: SOCKET PROTOCOL ERROR - This indicates an error in socket protocol
616: SOCKET BIND ERROR - This indicates an error in binding the socket
617: CONNECTION ERROR - This indicates a general socket connection error
618: CHUNK ERROR - This indicates an error in chunked encoding
619: SSL TIMEOUT - This indicates a timeout during SSL handshake (2 minutes)
620: SSL END OF INPUT - This indicates an end-of-file is received during SSL handshake
621: SSL HANDSHAKE ERROR - This indicates a general error during SSL handshake
622: SSL CERTIFICATE ERROR - This indicates an error in SSL certificate verification
623: SSL AUTHENTICATION ERROR - This indicates an authentication error during SSL handshake
624: SSL BAD MAC ERROR - This indicates a bad MAC during SSL handshake
625: SSL CIPHER ERROR - This indicates a cipher error during SSL handshake
701: ERROR TEXT FOUND - This code is returned if any error text (such as, "Service Unavailable") are found in the main page (frame HTML contents included). Note that the error text must be defined in advance of the test. Error text means if the text is found, this session should be considered a failure.
702: REQUIRED TEXT NOT FOUND - This code is returned If not all required texts are found in the main page. Note that required text must be defined in advance of the test. Required text means if the text is not found, this session should be considered a failure.
703: HTML BODY EMPTY - This code is returned if the HTML body of the page is empty (only if error text or required text has been defined).

Czy to dobra praktyka, nie odważyłbym się powiedzieć, ale jest to przynajmniej ciekawa wzmianka.

— Więdnąć
źródło
1
Te wartości są niedozwolone, ponieważ specyfikacja HTTP nie zezwala na nic poza 100 ... 599.
— Julian Reschke
16
@JulianReschke Wspomniałem nawet, że „nie śmiem powiedzieć, czy to dobra praktyka”. Dodam tylko odniesienie do tego, co robią inne aplikacje. Głosowanie w dół na moją odpowiedź, ponieważ Keynote używa nielegalnych kodów statusu, wydaje się nieuzasadnione. Ja tylko podsycam dyskusję.
— Wilt
-12

Nie, możesz używać tylko kodu wymagań dokumentacji rfc, zobacz szczegóły w RFC1945

— Aimeast
źródło
4
Możesz użyć dowolnego kodu statusu zdefiniowanego w iana.org/ assignments/http- status- codes .
— Julian Reschke
@Julian, czy to oznacza, że ​​Rajesh może używać tych „427-499 nieprzypisanych” do swoich celów?
— IrishChieftain
OK :-) Możesz użyć dowolnego przypisanego kodu statusu z tej listy. Lub napisz specyfikację nowego kodu statusu i zarejestruj go.
— Julian Reschke
5
Technicznie rzecz biorąc, możesz użyć wszystkiego, co ci się podoba. Tylko nie oczekuj, że będzie dobrze współgrał z kimkolwiek innym. Zgodnie z zapytaniem w PO - jeśli Rajesh kontroluje wszystkich klientów, może sprawić, że zrozumieją "1337 - Cała twoja baza należy do nas", jeśli tak im się podoba. ;)
— Cornelius,
1
Połączyłeś się z kodami stanu HTTP / 1.0, które nie były używane od wczesnych lat 90-tych.
— andsens,
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.