Czy żądanie HTTP OPTIONS może zwrócić wartość 204, czy też powinna zawsze zwracać 200?

Question

Zgodnie z http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.2 jedyną odpowiedzią kiedykolwiek wspomnianą na żądanie HTTP OPTIONS jest 200. Wydaje się jednak, że są przypadki takie, jak gdy długość zawartości wynosi 0, że 204 byłoby bardziej odpowiednie. Czy jest właściwe, aby żądanie HTTP OPTIONS zwróciło 204?

Answer 1

Tak, może zwrócić 204. Lub 400. Lub 400. Nie ma ogólnych ograniczeń co do kodów statusu, które metoda może zwrócić.

Należy również pamiętać, że nadszedł czas, aby przestać patrzeć na RFC 2616. Zobacz http://trac.tools.ietf.org/wg/httpbis/trac/wiki.

Answer 2

RFC 2616 mówi:

A 200 odpowiedź powinna ...

...

Jeśli ciało nie jest wliczone odpowiedź, odpowiedź musi zawierać pole Content-Length z wartość pola "0".

co rzeczywiście nie jest jasne, czy 200 odnosi się do całego akapitu, czy tylko do pierwszego zdania. Jeśli chcesz grać bezpiecznie, musisz pozwolić MUSI mieć pierwszeństwo (i nie będzie cię to kosztowało dużo).

RFC 7231, RFC 2616, które obsoletes, zmienił sformułowanie

serwerze generowania udaną odpowiedź na opcje powinny ...

...

Serwer musi wygenerować Pole długości treści o wartości "0", jeśli w odpowiedzi nie ma być wysyłane żadne ciało ładunku.

, która sprawia, że ​​ostatnie zdanie stosuje się w sensie ogólnym do statusów 2xx, a kryterium MUSI ma pierwszeństwo.

Tak więc, długość treści MUSI zostać wysłana. Ale Content-Length nie może zostać wysłany z 204:

RFC 2616 mówi tak:

Obecność wiadomości-ciała w żądaniu jest sygnalizowana poprzez włączenie Content-Length lub Pole nagłówka Transfer-Kodowanie ...

... Wszystkie odpowiedzi 1xx (informacyjne), 204 (bez zawartości) i 304 (niezmodyfikowane) NIE MOGĄ zawierać treści wiadomości.

i RFC 7230 wyjaśnia to także:

Serwer NIE wysłać pole nagłówka Content-Length w jakiejkolwiek odpowiedzi z kodem statusu 1xx (informacyjne) lub 204 (No Content).

Tak to rozumiem.