9.2 OPCJE
Metoda OPTIONS reprezentuje żądanie informacji o dostępnych opcjach komunikacji w łańcuchu żądań / odpowiedzi identyfikowanym przez URI żądania. Ta metoda umożliwia klientowi określenie opcji i / lub wymagań związanych z zasobem lub możliwościami serwera, bez narzucania działania związanego z zasobem lub inicjowania pobierania zasobu.
Odpowiedzi na tę metodę nie podlegają buforowaniu.
Jeśli żądanie OPTIONS zawiera treść encji (na co wskazuje obecność Content-Length lub Transfer-Encoding), wówczas typ nośnika MUSI być wskazany w polu Content-Type. Chociaż ta specyfikacja nie definiuje żadnego zastosowania takiej treści, przyszłe rozszerzenia HTTP mogą używać treści OPTIONS do wykonywania bardziej szczegółowych zapytań na serwerze. Serwer, który nie obsługuje takiego rozszerzenia, MOŻE odrzucić treść żądania.
Jeśli identyfikator URI żądania jest gwiazdką („*”), żądanie OPTIONS ma dotyczyć ogólnie serwera, a nie konkretnego zasobu. Ponieważ opcje komunikacji serwera zwykle zależą od zasobu, żądanie „*” jest przydatne tylko jako metoda typu „ping” lub „no-op”; nie robi nic poza umożliwieniem klientowi przetestowania możliwości serwera. Na przykład można tego użyć do przetestowania serwera proxy pod kątem zgodności z HTTP / 1.1 (lub jej braku).
Jeśli identyfikator URI żądania nie jest gwiazdką, żądanie OPTIONS dotyczy tylko opcji, które są dostępne podczas komunikacji z tym zasobem.
Odpowiedź 200 POWINNA zawierać wszystkie pola nagłówka, które wskazują opcjonalne funkcje zaimplementowane przez serwer i mające zastosowanie do tego zasobu (np. Zezwalaj), ewentualnie zawierające rozszerzenia nie zdefiniowane w tej specyfikacji. Ewentualna treść odpowiedzi POWINNA również zawierać informacje o opcjach komunikacji. Format takiej treści nie jest zdefiniowany w tej specyfikacji, ale może zostać zdefiniowany przez przyszłe rozszerzenia protokołu HTTP. Do wybrania odpowiedniego formatu odpowiedzi MOŻNA użyć negocjacji treści. Jeśli nie podano treści odpowiedzi, odpowiedź MUSI zawierać pole Content-Length z wartością pola „0”.
Pole nagłówka żądania Max-Forwards MOŻE być używane do kierowania na określone proxy w łańcuchu żądań. Gdy proxy otrzymuje żądanie OPTIONS na bezwzględnym adresie URL, dla którego dozwolone jest przekazywanie żądania, MUSI sprawdzić, czy jest pole Max-Forwards. Jeśli wartość pola Max-Forwards wynosi zero („0”), proxy NIE MOŻE przesyłać dalej wiadomości; zamiast tego serwer proxy POWINIEN odpowiadać własnymi opcjami komunikacji. Jeśli wartość pola Max-Forwards jest liczbą całkowitą większą od zera, proxy MUSI zmniejszyć wartość pola, gdy przekazuje żądanie dalej. Jeśli w żądaniu nie ma pola Max-Forwards, wówczas przesłane żądanie NIE MOŻE zawierać pola Max-Forwards.
9.4 GŁOWA
Metoda HEAD jest identyczna z metodą GET, z wyjątkiem tego, że serwer NIE MOŻE zwracać treści wiadomości w odpowiedzi. Metainformacja zawarta w nagłówkach HTTP w odpowiedzi na żądanie HEAD POWINNA być identyczna z informacjami przesłanymi w odpowiedzi na żądanie GET. Tej metody można użyć do uzyskania metainformacji o jednostce, której dotyczy żądanie, bez przenoszenia samej treści jednostki. Ta metoda jest często używana do testowania łączy hipertekstowych pod kątem ważności, dostępności i niedawnych modyfikacji.
Odpowiedź na żądanie HEAD MOŻE być zapisywalna w pamięci podręcznej w tym sensie, że informacje zawarte w odpowiedzi MOGĄ zostać wykorzystane do aktualizacji wcześniej zbuforowanej jednostki z tego zasobu. Jeśli nowe wartości pól wskazują, że jednostka buforowana różni się od jednostki bieżącej (na co wskazywałaby zmiana Content-Length, Content-MD5, ETag lub Last-Modified), wówczas pamięć podręczna MUSI traktować wpis pamięci podręcznej jako nieaktualny.