Czy możemy tworzyć niestandardowe kody stanu HTTP?

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?

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

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

• Nieprzetworzona awaria: stan 422
• Niepowodzenie autoryzacji : stan 403

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.

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.

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.

Oto pełna lista wszystkich dostępnych / niedostępnych HTTPkodów.

https://www.iana.org/ assignments/http-status-codes/http-status-codes.xhtml

Na przykład następujące strzałki ze strzałkami są dostępne do użycia (ponieważ nie są przypisane) w 4XXrodzinie.

Mam nadzieję, że to komuś pomoże.

Dzięki

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