Ukryte funkcje HTTP

O jakich ukrytych funkcjach protokołu HTTP warto wspomnieć?

Przez ukryte funkcje rozumiem funkcje, które są już częścią standardu, ale są raczej nieznane lub nieużywane.

Tylko jedna funkcja na odpowiedź.

To musi być kod statusu 418 I'm a teapot , część protokołu Hyper Text Coffee Pot Control Protocol (rozszerzenie HTTP). Rozśmiesza mnie za każdym razem.

2.3.2 418 Jestem czajniczkiem

Każda próba zaparzenia kawy czajnikiem powinna skutkować wyświetleniem kodu błędu „418 Jestem czajniczkiem”. Powstały w ten sposób korpus jednostki MOŻE być krótki i tęgi.

Fakt, że strona odsyłająca została błędnie wpisana i zdecydowano, że należy ją zachować.

Oczywista odpowiedź: metody PUT, DELETE, TRACE, OPTIONS, CONNECT

Większość ludzi wie o metodach GET i POST, ponieważ właśnie tego używają podczas tworzenia formularzy. Przeglądarki również często używają HEAD. Inne metody są znacznie mniej znane; są najczęściej używane przez bardziej specyficzne aplikacje.

Czy ktoś kiedykolwiek widział wymaganą płatność 402 ?

204 Brak treści

Myślałem, że 204 jest tylko wtedy, gdy nie masz treści do wyświetlenia, ale specyfikacja wygląda na to, że istnieje dodatkowe zachowanie, które polega na tym, że agent użytkownika „nie zmienia widoku dokumentu”.

Zgodnie z HOWTO: Skonfiguruj Apache, aby zwracał HTTP 204 (brak treści) dla AJAX

FWIW, Google faktycznie robi coś podobnego. Za każdym razem, gdy użytkownik klika łącze w wynikach wyszukiwania, Google pinguje się, aby zarejestrować kliknięcie; kod odpowiedzi z polecenia ping to HTTP 204.

Ponadto 204 No Content proponuje, że jest to dobra technika w przypadku „błędów internetowych” lub „sygnałów nawigacyjnych”, jeśli chcesz zaoszczędzić na każdym ostatnim bajcie ruchu sieciowego, jaki możesz.

Kod odpowiedzi410 Gone :

(...) właściciele serwerów chcą, aby zdalne łącza do tego zasobu zostały usunięte. (...)

Pająki sieciowe (w szczególności Google) usuwają indeksowanie (zwykle podczas następnego indeksowania) strony, która zaczyna zwracać 410.

W zawartości dynamicznej użyj nagłówka Last_Modified lub ETag

Czasami masz dynamiczną zawartość, która może być duża i / lub kosztowna do wygenerowania i która może się nie zmieniać w zależności od żądania. Możesz dodać nagłówek Last_Modified lub ETag do wygenerowanej odpowiedzi.

Na początku drogiego kodu dynamicznego możesz użyć If_Modified_Since lub If_None_Match, aby określić, czy żądający treści już ma, jest nadal aktualny. Jeśli zmieni status odpowiedzi na „304 Unmodified” i zakończ żądanie.

Niektóre technologie po stronie serwera formalnie zapewniają takie funkcje, ale możesz to zrobić nawet w skromnym ASP-Classic.

Zauważ, że różni się to od ustawiania nagłówków Cache-Control, Expires tym, że zapewnia klientowi zawsze aktualne informacje na żądanie.

Możesz zażądać wznowienia (dużej) odpowiedzi HTTP (np. Pobrania pliku), używając nagłówków Rangei If-Rangeżądań z odpowiednio określonym zakresem bajtów i unikalnym identyfikatorem pliku lub znacznikiem czasu modyfikacji pliku. Jest to możliwe, jeśli serwer wysłał nagłówki Accept-Ranges: bytesi ETaglub Last-Modifiedodpowiedzi w odpowiedzi początkowej z odpowiednio powiadomieniem, że serwer obsługuje żądania zakresów bajtów, unikalnym identyfikatorem pliku i znacznikiem czasu modyfikacji pliku.

Początkowa odpowiedź może wyglądać następująco ( ETagzazwyczaj składa się z nazwy pliku, rozmiaru i znacznika czasu ostatniej modyfikacji):

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 0-1233/1234

Gdy pobieranie zostanie przerwane na przykład na 1 KB (1024 bajty), klient może je wznowić w następujący sposób:

If-Range: file.ext_1234_1234567890
Range: bytes=1024-

Który powinien zwrócić tę odpowiedź z odpowiednimi bajtami w treści:

Accept-Ranges: bytes
ETag: file.ext_1234_1234567890
Content-Range: bytes 1024-1233/1234

ReST próbuje wykorzystać HTTP do granic swoich możliwości jako protokół interfejsu.

To nie jest ukryta funkcja , ale patrząc na dobrze zdefiniowane API ReST, można dość dobrze zrozumieć, jak powinien działać HTTP i znaleźć wspaniałe przykłady tego, co można osiągnąć za pomocą prostej kombinacji metod HTTP, kodów stanu i nagłówków do i od.

Trailer (w przeciwieństwie do Header)

Protokół umożliwia definiowanie własnych pól niestandardowych. Mogą one służyć do przenoszenia innych informacji, jeśli nie chcesz używać do tego plików cookie.

Status HTTP 100 (kontynuacja)

Klient może wysłać komunikat żądania z treścią żądania, aby określić, czy serwer pochodzenia jest skłonny zaakceptować żądanie.

W niektórych przypadkach wysłanie treści przez klienta może być niewłaściwe lub wysoce nieefektywne, jeśli serwer odrzuci wiadomość bez patrzenia na treść.

Może być używany do unikania ruchu od nieuczciwych klientów ... i / lub gdy przepustowość jest cennym towarem.

Jednak w celu pełnego wykorzystania tej funkcji istnieją pewne kryteria dotyczące klienta, serwerów i serwerów proxy HTTP1.1. Więcej informacji na temat połączeń HTTP można znaleźć w dokumencie HTTP / 1.1 RFC 2616 .

Kody statusu :

• Gdy wywoływany jest identyfikator URI http://www.domain.invalid/index.php?id=44 , jeśli query ( id=44) nie może zwrócić zasobu, dlaczego nie zwrócić kodu stanu 404?
• Dlaczego wywoływany jest identyfikator URI, który akceptuje tylko liczby całkowite, dlaczego nie zwrócić kodu stanu ?http://www.domain.invalid/index.php?id=fooid400
• Dlaczego po wprowadzeniu nieprawidłowego loginu / hasła prawie wszystkie aplikacje internetowe zwracają komunikat typu „Uwierzytelnianie nie powiodło się” z kodem stanu 200(ok, nie ma problemu, robisz to dobrze) 401?

Tak, kody statusu wydają się być rodzajem tajnej funkcjonalności HTTP dla niektórych twórców stron internetowych ... Ale zastanawiam się, czy najbardziej okultystyczną ze wszystkich "funkcji" tego protokołu nie jest jego RFC !