Celem laboratorium jest zapoznanie się z HTTP (HyperText Transfer Protocol). Przed zajęciami laboratoryjnymi MUSICIE Państwo przeczytać rozdziały 1, 2 i 3 w celu zrozumienia komunikacji klient-serwer poprzez protokół HTTP. Następnie należy sprawdzić działanie HTTP przy wykorzystaniu Telnet (instrukcja w rozdziale 4).

1. Komunikat HTTP

1.1. Typy komunikatów

Komunikat HTTP składa sie z żądania klienta (request) i odpowiedzi serwera:

HTTP-message = Request | Response ; HTTP/1.1 messages

Komunikaty żądania i odpwiedzi używają generycznego formatu określonego w RFC 822 dla transferu encji (treści komunikatu). Oba typy komunikatów składają się z lini startowej, zera lub więcej pół nagłówka (znanych także jako „nagłówki” - headers), pustej linii (tzn. nic nie pojawia się przed znakiem CRLF) wskazującej koniec nagłówków i ewentualnie ciała wiadomości.

generic-message = start-line

*(message-header CRLF)

CRLF

message-body ]

start-line = Request-Line | Status-Line

W celu zapewnienia niezawodności, serwery POWINNY ingnorować wszystkie otrzymane puste linie, gdzie powinna pojawić się linia żądania. Innymi słowy, jeżeli serwer odczytuje strumień protokołu na początku komunikatu i na początku otrzymuje CRLF, powinien to zignorować. Niektóre wadliwe implementacje klientów HTTP/1.0 generują dodatkowe CRLF po żądaniu POST. W celu zapewnienia zgodności z notacja BNF, klientom HTTP/1.1 NIE WOLNO produkować ani przekazywać żądań z dodatkowymi CRLF.

1.2. Nagłówki komunikatów

Nagłówki HTTP zawierają nagłówek ogólny, nagłówek żądania, nagłówek odpowiedzi i pola nagłówka encji. Każde pole składa się z nazwy, po której następuje dwukropek („:”) i wartość pola. Nazwy pól są „case-sensitive”. Wartość pola może być poprzedzona dowolną ilościa białych spacji (linear white space, LWS), jednak preferuje się pojedynczy znak SP. Pola nagłówka mogą być rozszerzone na wiele lini poprzez poprzedzenie każdej dodatkowej linii co najmniej jednym znakiem SP lub HT (horizontal tab). Aplikacje powinny spełniać przyjętą formę podczas generowania konstrukcji HTTP, ponieważ zawsze mogą pojawić się implementacje nie obsługujące niczego, co wychodzi poza nią:

nagłówke-komunikatu = nazwa-pola ":" [ wartość-pola ]

nazwa-pola = token

wartość-pola = *( wartość-pola | LWS )

zawartość-pola = <oktety tworzące wartość pola i

składające sie z *TEKSTu lub kombinacji „tokenów”, separatorów i cytowanych „napisów” (quoted strings)>

Wartość pola nie zawiera żadnych LWS przed ani poprzedzający je ani następujących po nim. Takie białe spacje MOGĄ zostać usunięte bez zmiany sematyki pola. Dowolne LWS pojawiające się wewnątrz zawartości pola mogą zostać zastąpione pojedynczym znakiem SP przed interpretacją pola lub przekazaniem strumienia komunikatu.

Kolejność, w jakiej są otrzymywane pola nagłówków o różnych nazwach nie ma znaczenia. Jednakże, zaleca się najpierw wysyłać nagłówki ogólne, następnie nagłówki żądania/odpowiedzi kończąc nagłówkami encji.

Wielokrotne nagłówki o tej samej nazwie pola MOGĄ pojawić się w komunikacie jedynie, jeżeli cała wartość pola jest zdefiniowana jako lista oddzielana przecinkami. MUSI istnieć możliwość połączenia wielokrotnych nagłówków w pary „nazwa-pola: wartość-pola” bez zmiany semantyki komunikatu poprzez dodawanie kolejnych pól, poprzedzając je przecinkami. Dlatego kolejność, w której są otrzymywane pola o tej samej nazwie, jest istotna dla interpretacji pól łączonych i dlatego proxy NIE MOŻE zmieniać kolejności wartości tych pół podczas przekazywania komunikatu.

1.3. Ciało komunikatu

Ciało komunikatu HTTP (jeżeli istnieje) jest wykorzystywane do przenoszenia encji związanej z żądaniem lub odpowiedzią. Ciało komunikatu różni się od ciała encji jedynie kiedy stosuje się kodowanie transferu (wskazane w polu nagłówka Transfer-Encoding):

message-body = entity-body | <entity-body encoded as per Transfer-Encoding>

Nagłówek Transfer-Encoding MUSI zostać zastosowany w celu wskazanie wykorzystanego przez aplikację kodowania transferu i zapewnienia poprawnego i bezpiecznego transferu komunikatu. Transfer-Encoding jes właściwością komunikatu, nie encji i dlatego MOŻE zostać dodany lub usunięty przez dowolną aplikację w łańcuchu żądania/odpowiedzi.

Reguły, kiedy ciało komunikatu może różnić się przy żądaniu i odpowiedzi.

Obecność ciała komunikatu w żądaniu jest sygnalizowana poprzez włącznie pól nagłówków Content-Length lub Transfer-Encoding w nagłówkach komunikatu żądania. Ciało komunikatu NIE MOŻE być włączone w żądanie, jeżeli specyfikacja metody żądania nie dopuszcza przesyłania ciała encji w żądaniu. Serwer POWINIEN odczytać i przekazać ciało komunikatu na każde żądanie, jeżeli metoda żądania nie zawiera zdefiniowanej semantyki ciała encji, wtedy ciało komunikatu POWINNO zostać zignorowane podczas obsługi żądania.

Dla komunikatów odpowiedzi, czy ciało komunikatu jest zawarte w komunikacie czy też nie zależy zarówno od metody żądania i kodu statusu odpowiedzi. Żadne odpowiedzi na żądanie HEAD NIE MOGĄ zawierać ciała komunikatu, nawet jeżeli obecność pól nagłówka encji mogłaby na to wskazywać. Żadne odpowiedzi 1xx (informacyjne), 204 (no content) ani 304 (not modified) NIE MOGĄ zawierać ciała komunikatu. Wszystkie inne odpowiedzi zawierają ciało komunikatu, chociaż MOŻE ono mieć zerową długość.

1.4. Długość komunikatu

Długość transferu komunikatu jest długością ciała komunikatu, które pojawia się w komunikacie, tj. po każdorazowym zastosowaniu kodowania transferu. kiedy ciało komunikatu jest włączone w komunikat, długość transferu tego ciała jest ustalana poprzez jedną z następujących metod (w podanej kolejności):

1. Każdy komunikat odpowiedzi, który “NIE MOŻE” zawierać ciała odpowiedzi (jak 1xx, 204, 304 i odpowiedź na żądanie HEAD) jest zawsze zakończony pierwszą pustą linią oi polach nagłówka, bez względu na to, czy pola nagłówka encji są obecne w komunikacie.

2. Jeżeli nagłówek Transfer-Encoding jest obecny i ma dowolną wartość różną od “tożsamej”, długość transferu jest definiowana poprzez uzycie „cząstkowe” kodowanie transferu, chyba że komunikat jest zakończony przez zamknięcie połączenia.

3. Jeżeli nagłówek Content jest obecny, jego dziesiętna wartość w oktetach przedstawia jednocześnie długość encji długość transferu. Pole nagłówka Content-Length NIE MOŻE być wysłane, jeżeli te dwie długości są różne (tj. nagłówek Transfer-Encoding jest obecny). Jeżeli komunikat został otrzymany z obydwoma nagłówkami Transfer-Encoding i Content-Length, wcześniejszy MUSI zostać zignorowany.

4. Jeżeli komunikat używa typu nośnika (media type) "multipart/byteranges" i długość transferu nie jest zdefiniowana w inny sposób, wtedy samoeliminujący typ nośnika definiuje długość transferu. Ten typ nocnika NIE MOŻE być użyty, chyba że nadawca wie, że odbiorca może go przetworzyć, obecność w żądaniu nagłówka Range z wielobajtowym określeniem od klienta wskazuje, że klient może obsługiwać odpowiedzi "multipart/byteranges". Nagłówek Range może zostać przekazany przez 1.0 proxy, które nie rozumie "multipart/byteranges", w takiej sytuacji serwer MUSI oddzielić komunikat używając metody zdefiniowanej w punktach 1, 3 lub 5 tej sekcji.

5. Poprzez zamknięcie połączenia przez serwer (zamknięcie połączenia nie może być użyte di wskazania końca ciała żądanie, ponieważ nie pozostawiłoby to serwerowi możliwości odesłania odpowiedzi).

Dla kompatybilności z aplikacjami HTTP/1.0, żądania HTTP/1.1 zawierające ciało komunikatu MUSZĄ zawierać ważny nagłówek Content-Length, chyba że wiadomo, iż serwer jest zgodny z HTTP/1.1. Jeżeli żądanie zawiera ciało nagłówka a nie jest podany Content-Length, serwer powinien odpowiedzieć poprzez 400 (bad request) jeżeli nie może ustalić długości komunikatu lub poprzez 411 (length required) jeżeli chce nalegać na otrzymanie ważnego Content-Lenth.

Wszystkie aplikacje HTTP/1.1, które otrzymują encje MUSZĄ akceptować „cząstkowe” kodowanie transferu, w ten sposób pozwalając na użycie tego mechanizmu kiedy długość komunikatu nie może być z góry wyznaczona. Komunikat NIE MOŻE zawierać jednocześnie nagłówka Content-Lenght i nietożsamego kodowania transferu. Jeżeli komunikat zawiera nietożsame kodowanie transferu, Content-Length MUSI zostać zignorowane. Kiedy dany jest nagłówek Content-Length w komunikacie, dla którego ciało komunikatu jest dopuszczone, wartość jego pola MUSI dokładnie zgadzać się z liczbą oktetów w ciele komunikatu. Klienty HTTP/1.1 muszą powiadamiać użytkownika, kiedy otrzymują i wykrywają nieważną długość.

1.5. Pliki nagłówków ogólnych

Istnieje kilka nagłówków, które mają zastosowanie ogólne tak dla komunikatów żądań, jak i dla odpowiedzi, ale które nie odnoszą się do transferowanej encji. Odnoszą się one jedynie do transmitowanego komunikatu:

general-header = Cache-Control | Connection | Date | Pragma | Trailer | Transfer-Encoding | Upgrade | Via | Warning

2. Definicje metod HTTP

Poniżej został zdefiniowany zbiór powszechnych metod HTTP/1.1. Chociaż zbiór ten można rozszerzyć, nie można założyć, że dodatkowe metody będą dzieliły semantykę dla niezależnie rozszerzanych klientów i serwerów. Pole Host nagłówka żądanie musi towarzyszyć wszystkim żądaniom HTTP/1.1.

2.1. Metody bezpieczne i powtarzalne

2.1.1. Metody bezpieczne

Osoby wykonujące implementację powinni być świadome, że oprogramowanie reprezentuje użytkownika w internetowych interakcjach i powinni być ostrożni pozwalając użytkownikowi być świadomym działań, które podejmują, gdyż może to mieć nieoczekiwany wpływ na niego samego i innych.

W szczególności, ustalono konwencję, że metody GET i HEAD NIE POWINNY mieć wpływu na akcje inne niż dostarczanie zasobu. Te metody powinny być postrzegane jako „bezpieczne”. Pozwala to klientom przedstawiać inne metody, jak POST, PUT i DELETE, w szczególny sposób, tak że użytkownik jest uświadomiony, że żąda potencjalnie niebezpiecznych działań.

Naturalnie, nie jest możliwe zapewnienie, że serwer nie generuje efektów ubocznych w wyniku wykonania żądania GET, w rzeczy samej niektóre zasoby dynamiczne biorą pod uwagę tą cechę. Istotnym rozróżnieniem jest, że użytkownik nie żądał efektów ubocznych, tak że nie może być za nie odpowiedzialny.

2.1.2. Metody powtarzalne

Metody mogą mieć także cechę „powtarzalności” pod tym względem (poza kwestia błędu lub wygaśnięcia) - efekty uboczne N > 0 identycznych żądań są takie same jak pojedynczego żądania. Metody GET, HEAD, PUT i DELETE posiadają tą właściwość. Także metody OPTIONS i TRACE NIE POWINNY mieć efektów ubocznych i są uważane za „powtarzalne”.

Jednakże istnieje możliwość, że szereg kolejnych zapytań nie jest powtarzalny, nawet jeśli wszystkie metody wykonane w ciągu są powtarzalne (ciąg jest powtarzalny, jeżeli pojedyncze wykonanie całego ciągu zawsze daje wyniki, który nie jest zmieniany przez powtórne wykonanie całego lub części szeregu). Na przykład, szereg nie jest powtarzalny, jeżeli jego wynik zależy od wartości, która jest później modyfikowana w tym samym szeregu.

Szereg, który nigdy nie ma efektów ubocznych jest powtarzalny z definicji (pod warunkiem, że kolejne operacje są wykonywane na tym samym zbiorze zasobów).

2.2. OPTIONS

Metoda OPTIONS reprezentuje żądanie informacji na temat opcji komunikacji dostępnych łańcuchy żądań/odpowiedzi identyfikowanym przez URI żądania. Ta metoda pozwala klientowi wyznaczyć opcje i/lub wymagania związane z zasobem lub możliwości serwera, bez wymuszania działań na zasobie ani pubierania zasobu.

Jeżeli URI żądania jest asteryskiem („*”), żądanie OPTIONS ma na celu odniesienie się do serwera, a nie do konkretnego zasobu. Ponieważ opcje komunikacji serwera zazwyczaj zależą od zasobu, żądanie „*” jest jedynie użyteczne jako „ping” albo rodzaj metody „no-op” - nie robi nic poza pozwoleniem klientowi na sprawdzenie możliwości serwera. Na przykład, może być wykorzystane to testowanie proxy pod względem zgodności z HTTP/1.1.

Jeżeli URI żądania nie jest asteryskiem, żądnie OPTIONS odnosi się jedynie do opcji dostępnych przy komunikacji z zasobem.

Odpowiedź 200 POWINNA zawierać nagłówki wskazujące opcjonalne cechy zaimplementowane na serwerze i mające zastosowanie względem zasobu (np. Allow), możliwie włączając rozszerzenia nieokreślone w tej specyfikacji. Ciało odpowiedzi, jeżeli się pojawia, POWINNO także zawierać informacje na temat opcji komunikacji. Format takiego ciała nie jest określony w tej specyfikacji, jednak może zostać ujęty w przyszłych rozszerzeniach HTTP. Negocjacja zawartości MOŻE być wykorzystana do wyboru właściwego formatu odpowiedzi. Jeżeli nie jest włączone ciało odpowiedzi, odpowiedź musi zawierać pole Content-Length z wartością „0”.

2.3. GET

Metoda GET oznacza dostarczenie jakiejkolwiek informacji (w formie encji) identyfikowanej w formie URI żądania. Jeżeli URI żądania odnosi się do procesu tworzącego dane, właśnie te dane powinny być zwrócone jako encja w odpowiedzi, a nie tekst źródłowy procesu, chyba że ten tekst ma być zwrócony przez proces.

Semantyka metody GET zmienia się w „warunkowe GET” jeżeli komunikat żądania zawiera nagłówki If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, lub If-Range. Warunkowa metoda GET żąda, żeby encja była przesłana jedynie przy spełnieniu warunków opisanych w warunkowym polu (polach) nagłówka. Celem warunkowego GET jest zredukowanie niepotrzebnego obciążania sieci, pozwalając cache'owanym encjom na odświeżenie bez konieczności wielokrotnych żądań lub przesyłania danych już otrzymanych przez klienta.

2.1. HEAD

Metoda HEAD jest identyczna z GET poza tym, że serwer NIE MOŻE zwrócić ciała komunikatu w odpowiedzi. Metainformacja zawarta w nagłówkach HTTP odpowiedzi na żądanie HEAD POWINNA być identyczna z informacją wysłaną w odpowiedzi na żądanie GET. Ta metoda może być używana dla otrzymywania metainformacji o encji wskazywanej przez żądanie bez przesyłania samego ciała encji. Metodę tę często używa się dla testowania ważności, dostępności i ostatnich modyfikacji łączy hipertekstowych (hiperłączy).

2.5. POST

Metoda POST jest używana do żądań, żeby serwer przyjął encję zawartą w żądaniu jako nową podległą zasobu określonego w URI żądania w linii żądania. POST jest przeznaczona do obsługiwania jednorodną metodą następujących funkcji:

• Komentowania istniejących zasobów;

• Wysyłania wiadomości do grupy dyskusyjnej, listy mailingowej lub podobnej grupy artykułów;

• Dostarczania bloku danych, takich jak wynik przedłożenia formularza, do procesu obsługującego dane;

• Rozszerzania bazy danych poprzez operację dołączania.

Rzeczywista funkcja wykonywana metodą POST jest określana przez serwer i zazwyczaj zależy od URI żądania. Przesyłana encja podlega temu URI w ten sam sposób jak plik katalogowi, w którym się znajduje, post podlega grupie, do której został wysłany a rekord podlega bazie danych.

Akcja wykonywana przez metodę POST może nie dawać wyniku w postaci zasobu identyfikowanego przez URI. W tej sytuacji 200 (OK) lub 204 (No Content) jest odpowiednim statusem odpowiedzi, zależnie czy odpowiedź zawiera encję opisującą wynik.

Jezeli zasób został utworzony na serwerze, odpowiedź POWINNA być 201 (Created) i zawierać encję, która opisuje status żądania i odnosi się do nowego zasobu oraz nagłówek Location.

2.6. PUT

Metoda PUT żąda, ażeby zawarta encja została zachowana pod załączonym URI żądania. Jeżeli URI żądania odnosi się do już istniejącego zasobu, zawarta encja POWINNA być rozpatrzona jako zmodyfikowana wersja tej, która istnieje na serwerze. Jeżeli URI żądania nie wskazuje na istniejący zasób i może być zdefiniowane jako nowy zasób przez zapytanie klienta, serwer może stworzyć zasób na podstawie tego URI. Jeżeli zasób został utworzony, serwer MUSI poinformować klienta poprzez odpowiedź 201 (Created). Jeżeli istniejący zasób został zmodyfikowany, kody odpowiedzi 200 (OK) lub 204 (No Content) POWINNY być wysłane dla wskazania pomyślnego wykonania żądania. Jeżeli zasób nie mógł zostać stworzony lub zmodyfikowany, POWINNA być dana odpowiednia odpowiedź błędu, która odzwierciedla natorę błędu. Odbiorca encji NIE MOŻE zignorować żadnych nagłówków typu Content-* (np. Content-Range), których nie rozumie, lub nie implementuje i w takiej sytuacji MUSI zwrócić odpowiedź 501 (Not Implemented).

Podstawowa różnica pomiędzy żądaniami POST i PUT jest odzwierciedlona w różnym znaczeniu URI żądania. Przy POST URI identyfikuje zasób, który ma obsłużyć zawartą encje. Ten zasóbmoże być procesem przyjmującym dane, bramą do innego protokołu lub oddzielną encją przyjmującą komentarze. W odróżnieniu, URI w żądaniu PUT identyfikuje encję zawartą w zadaniu - klient wie, o które URI mu chodzi i serwer NIE MOŻE próbować zastosować żądania do innego zasobu. Jeżeli serwer chce zastosować żądanie do innego URI, MUSI wysłać odpowiedź 301 (Moved Permanently); klient może wtedy zadecydować czy przekierować żądanie.

2.7. DELETE

Metoda DELETE żąda, aby serwer usunął zasób identyfikowany przez URI żądania. Ta metoda MOŻE być przeciążona przez interwencję ludzką (lub innym sposobem) po stronie serwera. Klient nie może mieć gwarancji, że operacja się powiodła, mimo że kod statusu zwrócony z serwera wskazuje, że akcja została wykonana pomyślnie. Jakkolwiek, serwer NIE POWINIEN wskazywać sukcesu, chyba że w chwili udzielania odpowiedzi ma zamiar usunąć zasób lub przenieść go do niedostępnej lokalizacji.

W przypadku sukcesu odpowiedzią powinna być 200 (OK), jeżeli odpowiedź zawiera encję opisującą status, 202 (Accepted) jeżeli działanie nie zostało jeszcze podjęte lub 204 (No Content) jeżeli akcaja została podjęta lecz odpowiedź nie zawiera encji.

2.8. TRACE

Metoda TRACE jest używana w celu wywołania zdalnej pętli zwrotnej warstwy aplikacji komunikatu żądania. Końcowy odbiorca żądania POWINIEN odbić otrzymany komunikat z powrotem do klienta jako ciało encji odpowiedzi 200 (OK). Żądanie TRACE NIE MOŻE zawierać encji.

2.2. CONNECT

W tej specyfikacji metoda CONNECT służy do użytku z proxy, które mogą dynamicznie przełączać sie do bycia tunelem (np. tunelowanie SSL).

3. Kody statusu HTTP

Każdy kod statusu został opisany poniżej, włącznie z opisem, do jakich metod może sie odnosić i jaką metainformację powinien zawierać w odpowiedzi.

3.1. Informacyjne 1xx

Ta klasa kodów statusu wskazuje prowizoryczną odpowiedź składającą się jedynie z linii statusu o opcjonalnych nagłówków i jest zakończona pustą linią. Nie istnieją nagłówki wymagane w tej klasie kodów statusu. Ponieważ HTTP/1.0 nie definiuje żadnych kodów 1xx, serwerom NIE WOLNO wysyłać odpowiedzi 1xx klientom HTTP/1.0 z wyjątkiem warunków eksperymentalnych.

Klient MUSI być przygotowany na przyjęcie jednej lub więcej odpowiedzi statusu 1xx przed regularną odpowiedzią, nawet jeżeli klient nie oczekuje odpowiedzi 100 (Continue). Nieoczekiwane odpowiedzi statusu 1xx MOGĄ być ignorowane przez klienta.

Proxy MUSZĄ przekazywać odpowiedzi 1xx, chyba że połączenie pomiędzy proxy a jego klientem zostało przerwane, albo jeżeli sam proxy żądał utworzenia odpowiedzi 1xx, np. jeżeli proxy dodaje pole „Expect: 100-continue” kiedy przekazuje żądanie, nie musi przekazywać odpowiednich (odpowiedniej) odpowiedzi 100 (Continue).

3.1.1. 100 Continue

Klient POWINIEN kontynuować żądanie. Ta pośrenia odpowiedź jest używana do informowania klienta, że początkowa część żądania została otrzymana i nie została jeszcze odrzucona przez serwer. Klient POWINIEN kontynuować poprzez wysłanie pozostałej części żądania lub, jeżeli całe żądanie zostało wysłane, ignorować tą odpowiedź. Serwer MUSI wysłać finalną odpowiedź po ukończeniu żądania.

3.1.2. 101 Switching Protocols

Serwer rozumie i chce wypełnić żądanie klienta, poprzez nagłówek komunikatu Upgrade zmieniając protokół aplikacji używany przy połączeniu. Serwer przełączy protokół na ten określony w nagłówku Upgrade odpowiedzi natychmiast po pustej linii kończącej odpowiedź 101.

Protokół POWINIEN być przełączony jedynie, kiedy jest to korzystne. Na przykład, przełączenie do nowszej wersji HTTP ma przewagę nad starszymi wersjami, a przełączanie do synchronicznych protokołów czasu rzeczywistego może być korzystne podczas dostarczania zasobów korzystających z tych cech.

3.2. Successful 2xx

Ta klasa kodów statusu wskazuje, że żądanie klienta zostało poprawnie otrzymane, zrozumiane i zaakceptowane.

3.2.1. 200 OK

Żądanie zostało wypełnione. Informacja zwrócona z odpowiedzią jest zależna od metody używanej w żądaniu, np.:

GET encja odpowiadająca żądanemu zasobowi jest przesyłana w odpowiedzi;

HEAD pola nagłówka encji odpowiadającej żądanemu zasobowi są wysyłane w odpowiedzi bez ciała komunikatu;

POST encja opisująca lub zawierająca wynik działania;

TRACE encja zawierająca komunikat żądania w postaci otrzymanej przez końcowy serwer.

3.2.2. 201 Created

Żądanie zostało wypełnione i zaowocowało utworzeniem nowego zasobu. Nowo utworzony zasób może być dostępowany poprzez URI zwrócony/e w encji odpowiedzi, z najbardziej specyficznym URI zasobu danym przez nagłówek Location. Odpowiedź POWINNA zawierać encję zawierającą listę charakterystyk zasobów i lokalizacji, poprzez którą/e użytkownik lub jego klient mogą wybrać najbardziej odpowiednią. Format encji jest określony przez typ nośnika (media type) dany w nagłówku Content-Type. Serwer MUSI utworzyć zasób przd zwróceniem kodu statusu 201. Jeżeli działanie nie może być przeprowadzone natychmiast, serwer powinien w zamian odpowiedzieć poprzez 202 (Accepted).

3.2.3. 202 Accepted

Żądanie zostało zaakceptowane do przetwarzania, jednak przetwarzanie nie zostało ukończone. Żądanie może być w końcu wykonane lub nie, tak samo jak może zostać zabronione podczas właściwego przetwarzania. Nie istnieje mechanizm powtórnego wysyłania kodu statusu z takich asynchronicznych operacji.

Odpowiedź 202 jest celowo niepotwierdzalna. Jej celem jest umożliwienie serwerowi akceptowania żądań dla innego procesu (np. procesu opartego na wykonywaniu „batcha” raz dziennie) bez wymagania utrzymania połączenia z klientem użytkownika do chwili ukończenia procesu. Encja zwracana z tą odpowiedzią POWINNA zawierać wskazanie bieżącego statusu żądania i, albo wskaźnik do monitora statusu, albo pewne przybliżenie, kiedy użytkownik może oczekiwać wypełnienia żądania.

3.2.1. 203 Non-Authoritative Information

Zwrócona metainformacja w nagłówku encji nie jest definiowalnym zbiorem jak osiągalna z serwera, lecz jest złączona z kopii lokalnej lub należącej do innych stron. Prezentowany zbiór może być podzbiorem lub nadzbiorem oryginalnej wersji. Na przykład włączając lokalną informację komentarza na temat zasobu może zaowocować nadzbiorem metainformacji znanych przez serwer. Użytek tego kodu odpowiedzi nie jest wymagany i jest odpowiedni jedynie, kiedy w przeciwnym wypadku odpowiedzią byłoby 200 (OK).

3.2.5. 204 No Content

Serwer wypełnił żądanie, jednak nie musi zwracać ciała encji i może chcieć zwrócić zaktualizowaną metainformację. Odpowiedź MOŻE zawierać nową lub zaktualizowaną metainformację w formie nagłówków encji, które - jeżeli są obecne - powinny być powiązane z żądanym wariantem.

Jeżeli klient jest klientem użytkownika, NIE POWINIEN zmieniać swojego widoku dokumentu, który spowodował wysłanie żądania. Ta odpowiedź jest przede wszystkim zamierzona w celu dopuszczenia wprowadzania akcji bez powodowania zmiany aktywnego widoku dokumentu na kliencie użytkownika.

Odpowiedź 204 NIE MOŻE zawierać ciała komunikatu i dlatego jest zawsze zakończona pierwszą pustąlinią po polach nagłówka.

3.2.6. 205 Reset Content

Serwer wypełnił żądanie i klient użytkownika POWINIEN zresetować widok dokumentu na podstawie którego wysłąno żądanie. Ta odpowiedź jest przede wszystkim zamierzona do umożliwienia wprowadzania akcji przez użytkownika, po którym następuje wyczyszczenie stosowanego formularza, tak że możliwe jest łatwe rozpoczęcie wprowadzania kolejnych akcji. Odpowiedź NIE MOŻE zawierać encji.

3.2.7. 206 Partial Content

Serwer wypełnił częściowe żądanie zasobu metodą GET. Żądanie MUSI zawierać nagłówek Range wskazujący wymagany zakres i MOŻE zawierać nagłówek If-Range w celu uczynienia żądania warunkowym.

3.3. Redirection 3xx

Ta klasa kodów statusu wskazuje, że muszą być podjęte dasze działania przez klienta użytkownika w celu wypełnienia żądania. Żądane działanie MOŻE być przeprowadzone przez tego klienta bez interakcji z użytkownikiem tylko wtedy, gdy metodą używaną w drugim żądaniu jest GET lub HEAD. Klient POWINIEN wykryć nieskończone pętle przekierowujące, gdyż takie pętle generują ruch w sieci dla każdego przekierowania.

3.3.1. 300 Multiple Choices

Żądany zasób odpowiada jednemu ze zbioru reprezentacji, przy czym każda z nich posiada specyficzną lokalizację, i zapewniona jest informacja na temat negocjacji przez klienta, tak że użytkownik (lub jego klient) może wybrać preferowaną reprezentację i przekierować swoje żądanie na jej lokalizację.

Jeżeli żądanie nie było żądaniem HEAD, odpowiedź POWINNA zawierać encję zawierającą listę charakterystyk zasobu i lokalizacji, z których użytkownik lub jego klient mogą wybrać najbardziej odpowiednią. Format encji jest określony poprzez typ nośnika dany w nagłówku Content-Type. Zależnie od formatu i możliwości klienta użytkownika, wybór najbardziej odpowiedniej opcji MOŻE być dokonany automatycznie. Jednakże, ta specyfikacja nie definiuje standardu automatycznej selekcji.

Jeżeli serwer posiada preferowaną opcję reprezentacji, POWINIEN włączyć specyficzny URI tej reprezentacji w polu Location, klienty użytkownika MOGĄ użyć wartości tego pola dla automatycznego przekierowania.

3.3.2. 301 Moved Permanently

Żądany zasób ma przypisany nowy trwały URI i dowolne przyszłe odniesienie do tego zasobu POWINNO użyć jednego ze zwróconych URI. Klienty posiadające zdolność edycji odnośników powinny automatycznie przepisać odniesienia do URI żądania na jedno lub więcej odniesień zwróconych przez serwer, gdzie jest to możliwe.

Nowy trwały URI POWINIEN być dany w polu Location odpowiedzi. Jeżeli metodą żądania nie było HEAD, encja odpowiedzi POWINNA zawierać krótką notę hipertekstową z hiperłączem do nowego/ych URI.

Jeżeli otrzymanym kodem statusu na żądanie inne niż GET czy HEAD jest 301, klientowi użytkownika NIE WOLNO automatycznie przekierować żądania, chyba że jest to potwierdzone przez użytkownika, gdyż mogłoby to zmienić warunki, w których wysłano żądanie.

3.3.3. 302 Found

Żądany zasób znajduje się czasowo pod innym URI. Ponieważ przekierowanie może być zmienione w każdej chwili, klient POWINIEN używać URI żądania przy przyszłych żądaniach.

Tymczasowy URI POWINIEN być podany w polu Location odpowiedzi. Jeżeli metoda żądania była inna niż HEAD, encja odpowiedzi powinna zawierać krótką notę hipertekstową z hiperłączem do nowego/ych URI.

Jeżeli klient użytkownika otrzyma na żądanie inne niż GET czy HEAD kod statusu 302, NIE WOLNO mu automatycznie przekierowywać żądania, chyba że może to być potwierdzone przez użytkownika, gdyż mogłoby to zmienić warunki, w których wysłano żądanie.

3.3.1. 303 See Other

Odpowiedź na żądanie może być odnaleziona pod innym URI i POWINNA być dostarczona przy użyciu metody GET względem tego zasobu. Ta metoda istnieje przede wszystkim w celu umożliwienia wyjściu skryptów uruchomionych przez POST przekierowania klienta użytkownika na wybrany zasób. Nowy URI nie zastępuje starego odniesienia oryginalnie żądanego zasobu.

Inny URI POWINIEN być podany w polu Location odpowiedzi. Jeżeli metodą żądania nie było HEAD, encja odpowiedzi POWINNA zawierać krótką notę hipertekstową z hiperłączem do nowego/ych URI.

3.3.5. 304 Not Modified

Jeżeli klient wykonał warunkowe żądanie GET i ma pozwolenie dostępu, jednak dokument nie został zmodyfikowany, serwer powinien odpowiedzieć tym kodem.

3.3.6. 305 Use Proxy

Żądany zasób musi być dostępowany poprzez proxy dany w polu Location, zawierającym URI proxy. Oczekuje się, że odbiorca powtórzy to pojedyncze żądanie poprzez proxy. Odpowiedź 305 MOŻE być generowana jedynie przez właściwe serwery.

3.3.7. 306 (Unused)

Kod statusu 306 był używany w poprzedniej wersji specyfikacji, teraz nie jest wykorzystywany, a sam kod jest zarezerwowany.

3.3.8. 307 Temporary Redirect

Żądany zasób istnieje tymczasowo pod innym URI. Ponieważ przekierowanie może być zmienione w każdej chwili, klient POWINIEN używać URI żądania przy przyszłych żądaniach.

Tymczasowy URI POWINIEN być dany w polu Location odpowiedzi. Jeżeli metodą żądania nie było HEAD, encja odpowiedzi POWINNA zawierać krótką notę hipertekstową z hiperłączem do nowego/ych URI. Ponieważ wiele klientów użytkownika zgodnych ze starszymi wersjami HTTP nie rozumie odpowiedzi 307, nota POWINNA zawierać informację konieczną dla użytkownika w celu powtórzenia oryginalnego żądania na nowym URI.

3.1. Client Error 4xx

Klasa 4xx kodów statusu ma na celu przypadki, kiedy najprawdopodobniej klient popełnił błąd. Poza odpowiadaniem na żądanie HEAD, serwer POWINIEN załączyć encję zawierającą wyjaśnienie błędnej sytuacji i powiadomienie, czy jest to stan trwały czy czasowy. Te kody statusu mają zastosowanie względem dowolnej metody żądania. Klienty użytkownika POWINNY wyświetlać użytkownikowi załączoną encję.

Jeżeli klient wysyła dane, implementacja serwera używająca TCP POWINNA zapewnić, że klient potwierdza odbiór pakietów zawierających odpowiedzi zanim serwer zamknie połączenie wejściowe. Jeżeli klient nadal wysyła dane do serwera po zamknięciu, stos TCP serwera wyśle klientowi pakiet reset, który może wymazać niepotwierdzone wejściowe bufory klienta zanim będą odczytane i zinterpretowane przez aplikację HTTP.

3.1.1. 400 Bad Request

Żądanie nie mogło byc zrozumiane przez serwer z powodu błędnej składni. Klient NIE POWINIEN powtarzać żądania bez modyfikacji.

3.1.2. 401 Unauthorized

Żądanie wymaga uwierzytelnienia. Odpowiedź MUSI zawierać nagłówek WWW-Authenticate zawierający wezwanie do uwierzytelnienia mające zastosowanie względem żądanego zasobu. Klient MOŻE powtórzyć żądanie z odpowiednim nagłówkiem Authorization. Jeżeli żądanie już zawierało informacje dotyczące uwierzytelnienia, odpowiedź 401 wskazuje, że uwierzytelnianie nie powiodło się dla tego zestawu. Jeżeli odpowiedź 401 zawiera to samo wezwanie do uwierzytelnienia jak poprzednia odpowiedź i klient użytkownika już próbował uwierzytelniania co najmniej raz, użytkownik POWINIEN mieć przedstawioną encję daną w odpowiedzi, ponieważ ta encja może zawierać niezbędne informacje diagnostyczne.

3.1.3. 402 Payment Required

Ten kod jest zarezerwowany dla wykorzystania w przyszłości.

3.1.1. 403 Forbidden

Serwer rozumie żądanie, jednak odmawia wypełnienia go. Uwierzytelnienie nic nie pomoże i żądanie NIE POWINNO być powtórzone. Jeżeli metodą żądania nie było HEAD i serwer chce ujewnić, dlaczego żądanie nie było spełnione, POWINIEN opisać powód odmowy w encji. Jeżeli serwer nie chce ujawniać tej informacji klientowi, może użyć w zamian kodu 404 (Not Found).

3.1.5. 404 Not Found

Serwer nie odnalazł niczego pasującego do URI żądania. Nie istnieje żadne wskazanie, czy jest to stan przejściowy czy trwały. Status 410 (Gone) POWINIEN być użyty, jeżeli serwer wie, poprzez pewne wewnętrzne konfigurowalne mechanizmy, że stary zasób jest trwale niedostępny i nie posiada adresu przekazującego. Ten kod statusu jest powszechnie używany, kiedy serwer nie chce ujawniać dokładnie dlaczego żądanie zostało odrzucone lub żadna inna odpowiedź nie ma zastosowania.

3.1.6. 405 Method Not Allowed

Metoda określona w linii żądania nie jest dopuszczona dla zasobu określonego w URI żądania. Odpowiedź MUSI zawierać nagłówek Allow zawierający listę ważnych metod względem żądanego zasobu.

3.1.7. 406 Not Acceptable

Zasób identyfikowany przez żądanie może jedynie generować w odpowiedzi encje, które zawierają charakterystykę zawartości nieakceptowalne zgodnie z nagłówkami żądania.

3.1.8. 407 Proxy Authentication Required

Ten kod jest podobny do 401 (Unauthorized), jednak wskazuje, że klient musi uprzednio uwierzytelnić się poprzez proxy. Proxy MUSI zwrócić nagłówek Proxy-Authenticate zawierający wezwanie do uwierzytelnienia mające zastosowanie względem proxy dla żądanego zasobu. Klient MOŻE powtórzyć żądanie z odpowiednim nagłówkiem Proxy-Authorization.

3.1.2. 408 Request Timeout

Klient nie utworzył żądania w czasie, na który przygotowany był serwer. Klient MOŻE powtórzyć żądanie bez modyfikacji w dowolnym czasie.

3.1.10. 409 Conflict

Żądanie nie mogło być wypełnione ze wzgłedu na konflikt z obecnym stanem zasobu. Ten kod jest dopuszczony jedynie w sytuacjach, kiedy oczekuje się, że użytkownik może być w stanie rozwiązać konflikt i ponownie przedłożyć żądanie. Ciało odpowiedzi POWINNO zawierać wystarczająco informacji dla użytkownika, ażeby rozpoznał źródło konfliktu. W idealnym przypadku, encja odpowiedzi zawierałaby wystarczająco informacji dla użytkownika lub jego klienta do rozwiązania problemu. Jednak może to być niemożliwe i nie jest wymagane.

Konflikty są najbardziej prawdopodobne w odpowiedzi na żądanie PUT. Na przykład, jeżeli było wykorzystane wersjonowanie i encja przesłana przez PUT zawierałaby zmiany zasobu, co stanowiłoby konflikt z tymi dokonanymi przez wcześniejsze żądanie (przez kogoś innego), serwer mógłby użyć odpowiedzi 409 dla wskazania, że nie może wypełnić żądania. W tej sytuacji, encja odpowiedzi najprawdopodobniej zawierałaby listę różnic pomiędzy dwoma wersjami w formacie określonym przez Content-Type odpowiedzi.

3.1.11. 410 Gone

Żądany zasób nie jest już dostępny na serwerze i nie jest znany adres przekierowujący. Oczekuje się, że ten stan jest trwały. Klienty z możliwościami edytowania odnośników POWINNY usunąć odniesienia do URI żądania po zgodzie użytkownika. Jeżeli serwer nie wie, lub nie ma możliwości wyznaczenia, czy stan jest stały, czy też nie, POWINIEN użyć kodu 404 (Not Found).

Odpowiedź 410 jest przede wszystkim zamierzona w celu zapewnienia utrzymania WWW poprzez powiadamianie odbiorców, że zasób jest celowo niedostępny i że właściciele serwera chcą usunięcia odnośników do zasobu. Takie zdarzenie jest powszechne dla usług promocyjnych o ograniczonym czasie i dla zasobów należących do osób już nie pracujących po stronie serwera. Nie ma konieczności oznaczania wszystkich trwale niedostępnych zasobów jako „gone” ani utrzymywania tego znacznika przez dłuższy czas - jest to pozostawione dyskrecji właściciela serwera.

3.1.12. 411 Length Required

Serwer odmawia akceptacji żądania bez określonego nagłówka Content-Length. Klient MOŻE powtórzyć żądanie po dodaniu ważnego nagłówka Content-Length zawierającego długość ciała komunikatu żądania.

3.1.13. 412 Precondition Failed

Wstępny warunek dany przez jeden lub więcej nagłówków żądania jest oceniony jako fałszywy podczas testowania na serwerze. Odpowiedź pozwala klientowi umieścić wstępne warunki w metainformacji bierzącego zasobu (dane pól nagłówka) i dlatego zapobiega stosowaniu metody żądania względem zasobu innego niż zamierzony.

3.1.11. 413 Request Entity Too Large

Serwer odmawia przetworzenia żądania, ponieważ encja żądania jest większa niż serwer chce lub może przetworzyć. Serwer MOŻE zamknąć połączenie w celu zapobieżenia powtarzania żądania przez klienta.

Jeżeli stan jest chwilowy, serwer POWINIEN włączyć nagłówek Retry-After dla wskazania, że jest to tymczasowe i określenia czasu, kiedy klient MOŻE ponownie próbować.

3.1.15. 414 Request-URI Too Long

Serwer odmawia obsługi żądania, ponieważ URI żądania jest dłuższe niż serwer chce interpretować. Ten rzadki warunek może się zdarzyć kiedy klient niepoprawnie konwertuje żądanie POST na GET z długim zapytaniem, kiedy klient zszedł w „czarną dziurę” przekierowania URI (np. przedrostek przekierowanego URI wskazuje na jego przyrostek), lub kiedy serwer jest atakowany przez klienta próbującego znaleźć dziury w zabezpieczeniach obecne w pewnych serwerach używających buforów o stałej długości dla odczytu i manipulowania URI żądań.

3.1.16. 415 Unsupported Media Type

Serwer odmawia obsługi żądania, ponieważ encja żądania jest w formacie nieobsługiwanym przez żądany zasób za pomocą żądanej metody.

3.1.17. 416 Requested Range Not Satisfiable

Serwer POWINIEN zwrócić odpowiedź z tym statusem kodu, jeżeli żądanie zawierało nagłówek Range, a żadne wartości określające zakres tego pola nie nakładają się na bieżące rozszerzenie wybranego zasobu, a żądanie nie zawiera nagłówka If-Range.

3.1.18. 417 Expectation Failed

Oczekiwanie podane w nagłówku Expect żądania nie mogło być odnalezione na serwerze lub, jeżeli serwer jest proxy, serwer ma niedwuznaczny dowód, że żądanie nie może być odnalezione na kolejnym serwerze.

3.5. Server Error 5xx

Kody statusu odpowiedzi rozpoczynające się od cyfry „5” wskazują przypadki, w których serwer jest świadomy, że popełnił bład lub, że nie jest w stanie wykonać żądania. Poza odpowiadaniem na żądanie HEAD, serwer POWINIEN włączyć encję zawierającą wytłumaczenie błędnej sytuacji i określenie, czy jest to stan chwilowy, czy trwały. Klienty użytkownika POWINNY wyświetlić całą zawartą encję użytkownikowi. Te kody odpowiedzi mają zastosowanie względem dowolnej metody żądania.

3.5.1. 500 Internal Server Error

Serwer napotkał nieoczekiwane warunki uniemożliwiające wypełnienie żądania.

3.5.2. 501 Not Implemented

Serwer nie wspiera funkcjonalności wymaganej dla wypełnienia żądania. Jest to odpowiedź pasująca do sytuacji, kiedy serwer nie rozpoznaje metody żądania i kiedy nie jest w stanie wykonać jej dla żadnego zasobu.

3.5.3. 502 Bad Gateway

Serwer podczas działania jako brama lub proxy otrzymał nieważną odpowiedź od kolejnego serwera, z którym komunikował się w celu wypełnienia żądania.

3.5.1. 503 Service Unavailable

Serwer nie jest aktualnie w stanie obsłużyć żądania za sprawą chwilowego przeciążenia lub konserwacji serwera. Wskazuje to, że stan jest chwilowy i ustąpi po pewnym czasie. Jeżeli jest on znany, MOŻE być wskazany w nagłówku Retry-After. Jeżeli nagłówek nie jest podany, klient powinien obsłużyć odpowiedź tak samo jak odpowiedź 500.

3.5.5. 504 Gateway Timeout

Serwer podczas działania jako brama lub proxy nie otrzymał odpowiedzi od kolejnego serwera określonego przez URI (np. HTTP, FTP, LDAP) lub innego pomocniczego serwera (np. DNS) w zadanym czasie, z którym komunikował się w celu wypełnienia żądania.

3.5.6. 505 HTTP Version Not Supported

Serwer nie wspiera lub odmawia wspierania wersji protokołu HTTP użytej w komunikacie żądania. Serwer wskazuje, że nie jest w stanie lub nie chce wypełnić żądania przy użyciu tej samej głównej wersji co klient w sposób inny niż ten komunikat błędu. Odpowiedź POWINNA zawierać encję opisującą, dlaczego ta wersja nie jest wspierana i jakie inne protokoły są wspierane przez serwer.

4. Testowanie HTTP przez telnet

Z wiersza poleceń DOSu lub Linuxa proszę wpisać:

telnet [host] [port]

w celu połączenia sie przez Telnet z serwerem. Port 80 jest domyślnym portem (jakkolwiek zależy od konfiguracji serwera HTTP) dla protokołu HTTP (strony WWW). Na przykład:

telnet www.yahoo.com 80

Kiedy tylko zostanie nawiązane połączenie, pojawia się czarny ekran. Teraz można wprowadzać polecenia, naztępie naciskając 2 razy ENTER dla wysłania polecenia. Wszystkie polecenia muszą być pisane wielkimi literami.

4.1. Przykład polecenia GET

Polecenie GET jest stosowane w celu otrzymywania zwykłego tekstu.

Składnia:

GET filename HTTP/1.0 (or 1.1)

Przykład:

GET /index.html HTTP/1.0

Odpowiedź może wyglądać następująco:

HTTP/1.0 200 OK

Date: Thu, 13 Jun 2002 17:37:53 GMT

Cache-Control: private

P3P: policyref="http://p3p.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV T AI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE GOV"

Connection: close

Content-Type: text/html

Następnie jest wysyłana strona w HTML.

Wyjaśnienie:

Pierwsza linia "HTTP/1.0 200 OK" potwierdza, że komenda została wykonana poprawnie. Pozostałe komuikaty wysyłane z i do przeglądarki zawierają olbrzymie ilości informacji ukrytej przed użytkownikiem. Podobnie jak polecenie, wysyłane są dodatkowe informacje, np.:

GET /path/file.html HTTP/1.0

From: [e-mail]

User-Agent: HTTPTool/1.0

[blank line here]

4.2. Przykład polecenia POST

POST jest metodą normalnie uzywaną do wysyłania informacji do skryptów CGI, np. silników wyszukiwarek, np.:

POST /path/script.cgi HTTP/1.0

From: [e-mail]

User-Agent: HTTPTool/1.0

Content-Type: application/x-www-form-urlencoded

Content-Length: 32

user=1&the+word=monty

4.3. Używanie proxy

Proxy są używane do przekazywania plików za zachwaniem anonimowości. Polecenia są dokładnie takie same, jednak zamiast nazwy serwera podaje się nazwę pliku, np.:

GET http://www.host.com/index.html HTTP/1.0

SKiSO, lab. 4

studia dzienne magisterskie

specyfikacja HTTP: http://www.w3.org/Protocols/rfc2616/rfc2616.html

14

---