Protokół HTTP

Ostatnio aktualizowano 15 kwietnia 2006 r.

HTTP jest to skrót od HyperText Transfer Protocol, jest to protokół znajdujący się w warstwie aplikacji w modelu OSI/ISO. HTTP jest stosowany do przekazywania informacji w Internecie od 1990 roku. Pierwsza wersja protokołu HTTP oznaczona jako HTTP/0.9 służyła do surowego przesylania danych przez Internet. Wraz z nadejściem HTTP/1.0 ( opisanym w dokumencie RFC 1945 ) stało sie możliwe przesyłanie informacji zachowujących charakter wiadomości MIME, zawierających metainformacje o transportowanych danych oraz modyfikatory w schemacie żądanie/odpowiedź. Jednakże, HTTP/1.0 nie bierze wystarczająco pod uwagę efektów zastosowania hierachicznego proxy, caching-u, potrzeby trwałych połączeń, czy wirtualnych host-ow. W dodatku, rozprzestrzenienie się "niekompletnie-zaimplementowanych" aplikacji nazywających się jako obsługujących HTTP/1.0 wymusiło zmianę wersji protokołu aby dwie komunikujące się ze sobą aplikacje mogły określić swoje prawdziwe możliwości.

HTTP to protokół żądania/odpowiedzi. Klient wysyła żądanie w formie: metody żądania, URI (ang. Uniform Resource Identifier - jest standardem internetowym określonym w RFC 2396 umożliwiającym łatwą identyfikację zasobów w sieci.URI składa się z URL (ang. Uniform Resource Locator) i URN ( ang. Uniform Resource Name ). ), wersji protokołu za którymi podąża wiadomość przypominająca MIME, zwierająca modyfikatory żądania, informacje klienta i możliwą zawartość ciała wiadomości.

Większość komunikacji HTTP jest inicjowana przez klienta i zawiera żądanie dotyczące zasobów na jakimś serwerze. W najprostszym przypadku, może to być osiągnięte poprzez pojedyńcze połączenie (v) pomiędzy klientem użytkownika (KU) a serwerem (S).

   łańcuch żądań ------------------------>
KU -------------------v------------------- S
   <-------------------- łańuch odpowiedzi

Bardziej skomplikowana sytuacja jest w przypadku gdy w łańcuchu wymiany żądań i odpowiedzi pojawią się inne elementy pośredniczące między klientem a serwerem. Są trzy podstawowe elementy pośredniczące: proxy, bramki i tunele. Proxy jest to "agent przekazywania" ( ang. forwarding agent ), otrzymujący żądania o URI, przeformatowujacy część lub całość wiadomości, i przekazujący przeformatowane żądanie do serwera identyfikowanego przez URI. Bramka jest to "agent odbierania", zachowujący sie jak warstwa znajdująca się nad jakimś innym serwerem i jeżeli jest to konieczne, tłumaczący żądania na protokół docelowego serwera. Tunel zachowuje się jak punkt transmisyjny pomiędzy dwoma połączeniami, nie zmieniając wiadomości, tunele są stosowane aby ominąć jakiś element pośredniczący którym może być np.: firewall, nawet jeżeli punkt pośredniczący nie potrafi zinterpretować zawartości wiadomości.

   łańcuch żądań -------------------------------------->
KU -----v----- A -----v----- B -----v----- C -----v----- S
   <---------------------------------- łańuch odpowiedzi

Rysunek powyżej przedstawia 3 elementy pośredniczące ( A, B i C ) pomiędzy klientem użytkownika a serwerem.
Komunikacja HTTP/1.1 jest realizowana za pośrednictwem protokołu TCP, domyślnym portem TCP jest port 80 lecz mogą być wykorzystane inne porty. Nic nie zmusza aby protokół HTTP został zbudowany na innym protokole transportowym. HTTP zakłada "zaufany" transport ( pewność w dostarczaniu danych ).
W przypadku HTTP/1.0 większość implementacji używa nowego połączenia dla każdej wymiany żądań i odpowiedzi. W HTTP/1.1 jedno połączenie może być wykorzystane do wymiany jednego lub więcej żądań i odpowiedzi, jednakże połączenia mogą być zamykane z wielu powodów.

Parametry protokołu:
1) Wersja HTTP - HTTP Version
HTTP używa następującego schematu oznaczania wersji protokołu "<major>.<minor>". Oznaczanie wersji protokołu ma służyć klientowi jako sposob okreslenia formatu wiadomosci co pozwoli na zrozumienie daleszej komunikacji z serwerem. Wersja protokołu HTTP jest zaznaczona za pomocą pola HTTP-Version w pierwszej linii wiadomości.

HTTP-Version = "HTTP" "/" 1*CYFRA "." 1*CYFRA

Wersja protokołu HTTP jaką przedstawia się aplikacja jest najwyższą możliwą wersja protokołu, która ta aplikacja obsługuje.

2) URI - Uniform Resource Identifiers
URI znane jest pod wieloma nazwami takimi jak: adresy WWW, UDI ( ang. Universal Document Identifiers ), URL ( ang. Uniform Resource Locators ), w przypadku HTTP , URI są poprostu przeformatowanymi łańcuchami znaków, identyfikującymi przez nazwę, lokalizację lub inną chcarakterystyczną wartość, zasób. HTTP nie narzuca jakiegoś górnego limitu na długość łańcucha URI, serwery muszą obsłużyć adres URI każdego zasobu jaki udostępniają. Jeżeli serwer nie jest w stanie obsłużyć żądanego URI spowodu jego długości powienien zwrócic odpowiedź 414 ( Request-URI Too Long - Żądany-URI za długi ).
Schemat "http" używany jest do lokalizowania zasobów sieciowych za pomocą protokołu HTTP, typowy adres można przedstawić jako:

http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

gdzie:
Jeżeli miejsce na port jest puste lub nie zostało podane przyjmuje się domyślnie port 80, identyfikowany zasób jest zlokalizowany na serwerze nasłuchującym połączeń TCP na podanym porcie, jednostki podanej jako host, a URI-żądania dla poszukiwanego zasobu podane jest w abs_path. Jeżeli abs_path nie jest podany musi być podany znak "/" jako zastępstwo.

3) Formaty Daty/Czasu
Aplikacje HTTP historycznie dopuszczały 3 różne formaty reprezentacji daty i czasu:

Sun, 06 Nov 1994 08:49:37 GMT Sunday, 06-Nov-94 08:49:37 GMT Sun Nov 6 08:49:37 1994

Pierwszy jest uważany za Internetowy standard i reprezentuje łańuch znaków Daty/Czasu o stałej długości zdefiniowany w dokumencie RFC 1123. Drugi format jest powszechnie używany, ale został stworzony na poodstawie przestarzałego formatu daty opisanego w RFC 850 brakuje mu bowiem 4 cyfrowego opisu roku. Klienty i serwery obsługujące HTTP/1.1 parsujące datę muszą akceptować wszystkie 3 formaty zapisu ( dla kompatybilności z HTTP/1.0 ). Trzeci z formatów zapisu daty to format generowany przez funkcje asctime() ze standardu ANSI C.
Wszystkie formaty daty i czasu muszą być reprezentowane bez wyjątku w formacie GMT ( Greenwich Mean Time ), jest to zaznaczone przez 3 znakowy specyikator strefy czasowej. Format daty i czasu HTTP jest wrażliwy na wielkość liter. Niekiedy do określenia "wartości" czasu stosuje się liczbę całkowitą sekund reprezentowaną w formie dziesiętnej.

Żądnie:
Wiadomość zawierająca żądanie klienta dla serwera zawiera w pierwszej linii, metodę jaka ma być zastosowana w stosunku do zasobu, łańuch identyfikujący zasób oraz wersje protokołu którą używa, pierwsza linia kończona jest znakami CRLF, kolejne "elementy" oddzielone sa spacjami, znaki CR i LF są dozwolone tylko na końcu linii.

Metody - pierwsza linią wiadomości zaczyna się od metody która określa "czynność" jaka ma być wykonana na wybranym zasobie serwera identyfikowanym przez podane URI. Oto lista możliwych metod: OPTIONS, GET, HEAD, POST, PUT, DELETE, TRACE, CONNECT. Nazwa metody jest wrażliwa na wielkość liter, zwracany kod odpowiedzi zawsze powiadami klienta czy dana metoda jest w danym momencie dostępna na zasobie, szczególnie że zestaw dozwolonych metod może zmieniać się dynamicznie. Serwer powinien zwrócić kod odpowiedzi 405 ( Method Not Allowed - Metoda Niedozwolona ) jeżeli serwer zna metodę ale nie jest dozwolna dla żądanego zasobu, i kod 501 ( Not Implemented - Nie zaimplementowana ) jeżeli metoda nie jest rozpoznawana przez serwer lub nie została poprawnie rozpoznana. Metody GET i HEAD muszą być wspierane przez wszystkie serwery ogólnego użycia, wszystkie pozostałe metody są opcjonalne.

* OPTIONS - metoda ta reprezentuje żądanie o informacje na temat opcji komunikacyjnych dostępnych na łańcuchu żądań/odpowiedzi. Pozwala ona klientowi na określenie opcji jak i wymagań związanych z zasobem, możliwości serwera bez wymuszania działania związanego z zasobem lub inicjowania pobierania zasobu.

* GET - metoda ta oznacza dosłownie "pobierz jakiekolwiek" dane identyfikowane przez URI. Jeżeli URI wskazuje na "proces generujący dane" dane te zostaną zwrócone, "kod" procesu nie zostanie zwrócony.

Składnia metody GET zmienia się w "warunkowy GET" ( "conditional GET" ) jeżeli wiadomość z rządaniem zawiera pola: If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match, lub If-Range. "Warunkowy GET" pobiera dane tylko jeżeli zajdą warunki opisane w wymienionych nagłówkach warunkowych. Metoda "warunkowego GET" została pomyślana jako sposób na zniwelowanie niepotrzebnego ruchu sieciowego, aby nie transefrowano danych posiadanych juz przez klienta etc.

Składnia metody GET zmienia się w "częściowy GET" ( "partial GET" ) jeżeli wiadomość z rządaniem zawiera pole Range ( Zakres ). Metoda "częściowego GET" została pomyślana jako sposób na zniwelowanie niepotrzebnego ruchu sieciowego, pozwalając na dokończenie pobieranych już wcześniej danych, bez ponownego wysłania danych posiadanych juz przez klienta.

* HEAD - metoda ta jest praktycznie identyczna jak GET za wyjątkiem tego, że serwer nie zwraca ciała wiadomości w odpowiedzi. Meta informacje zawarte w nagłówku HTTP odpowiedzi powinny być identyczne do tych jakie znajdują sie w odpowiedzi na metodę GET. Ta metoda powinna byc stosowana w celu uzyskania informacji o obiekcie bez pobierania go, można ją stosować np.: do sprawdzania poprawności hiperłączy.

* POST - metoda ta została stworzona by serwer zaakceptował "dodatkowe" dane zawarte w żądaniu, metoda ta została zaprojektowana tak by spełniała następujące funkcje:
- Wysłanie wiadomości na forum dyskusyjne, grupę usenet, listę mailingową lub do podobnego zbioru wiadomości
- Wysłanie bloku danych np.: z formularza do procesu przetwarzającego dane
- Rozszerzenie obsługi bazy danych jako interfejs dodawania danych

Faktyczna funkcja spełniana przez metodę POST jest uzależniona od konfiguracji serwera i zazwyczaj zależy od URI żądania.

* PUT - metoda ta wymusza aby załączone dane zostały umieszczone na serwerze pod wskazanym URI, Jeżeli podane URI wskazuje na istniejący na serwerze zasób, załączone dane mają być uznane za uaktualnioną wersję zasobu. Jeżeli URI nie wskazuje na istniejący zasób i jeżeli podane URI jest możliwe do stworzenia, serwer może stworzyć zasób o podanym URI. Jeżeli nowy zasób został stworzony, serwer musi powiadomić klienta zwracając odpowiedź 201 ( Created ). Jeżeli został zmodyfikowany istniejący zasób serwer może zwrócić odpowiedź 200 ( OK ) lub 204 ( No Content ) aby poinformować o tym, że operacja zakończona została sukcesem. Jeżeli zasób z jakiego kolwiek powodu nie mógł zostać stworzony, powinna zostać zwrócona odpowiedź odzwierciedlająca właściwie naturę problemu.
Fundamentalną różnicą pomiędzy metoda POST i PUT jest sposób rozumienia URI. POST utożsamia URI jako "adres" procesu obsługującego dane.

* DELETE - metoda ta żąda aby serwer usunął zasób identyfikowany przez podane URI. Ta metoda ( to żądanie ) może być zlekceważona przez interwencję administratora serwera. Serwer nie może zagwarantować klientowi wykonania operacji, nawet jeżeli zwrócona odpowiedź wskazuje na zakończenie operacji sukcesem.

* TRACE - metoda ta pozwala klientowi na sprawdzenie co dociera do końca łańcucha komunikacyjnego, użycie danych do testowania i pozyskania informacji diagnostycznych.

* CONNECT - specyfikacja zarezerwowuje sobie słowo CONNECT dla proxy które może dynamicznie zmienić się w tunel ( np.: tunel SSL )

URI - Uniform Resource Identifier identyfikujący zasób ma postac wskazną poniżej:

Request-URI = "*" | absoluteURI | abs_path | authority

Te cztery opcje URI są zależne od natury żądania. Znak "*" oznacza, że żądanie nie odnosi się do konkretnego zasobu ale do serwera. Przykładem może być:

OPTIONS * HTTP/1.1

Forma absoluteURI jest wymagana kiedy żądanie kierowane jest do serwera proxy, który ma przekazać żądanie do właściwego serwera. Przykładem może być:

GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.1

Forma authority jest stosowana wyłącznie w przypadku metody CONNECT

Najbardziej powszechny sposób identyfikowania zasobów na serwerze jest wysłanie abs_path URI ( ścieżki absolutnej ) i adresu sieciowego w polu Host. Przykładem może być:

GET /pub/WWW/TheProject.html HTTP/1.1 Host: www.w3.org

Pola nagłówka żądania - pozwalają klientowi na przekazanie dodatkowych informacji na temat ządania, i samego klienta serwerowi. Pola te zachowują się jak modyfikatory żądania, ze składnią rownoważna przekazywaniu parametrów w językach programowania. Oto one: Accept, Accept-Charset, Accept-Encoding, Accept-Language, Authorization, Expect, From, Host, If-Match, If-Modified-Since, If-None-Match, If-Range, If-Unmodified-Since, Max-Forwards, Proxy-Authorization, Range, Referer, TE, User-Agent.

* Accept - pozwala na określenie rodzaju typu odpowiedzi oczekiwanej od serwera. Pole to pozwala stwierdzić, że żądanie jest konkretnie skierowane na uzyskanie danych z małego zakresu typów. Znak "*" pozwala na grupowanie typów mediów w zakresy, "*/*" oznacza wszystkie media, "typ/*" oznacza wszystkie podtypy podanego typu. Za wskazniem typu mediów oczekiwanych mogą znajdować się dodatkowe parametry, zaczyna je parametr "q" określający relatywny wskaźnik jakości. Pierwszy parametr "q" o ile występuje oddziela typy mediów od dodatkowych parametrów ( tzw.: parametrów akceptacji - accept-params ). Wskaźniki jakości pozwalają klientowi użytkownika na pokazanie relatywnego stopnia preferowania danego typu mediów. Używane są do tego wartości od 0 do 1, domyślna wartością jest q=1. Przykładem może być:

Accept: audio/*; q=0.2, audio/basic

Powinno to zostać zinterpretowane jako: "Preferuję audio/basic, ale wyślij mi jaki kolwiek typ audio jeżeli jest on najlepszy z dostępnych"

* Accept-Charset - pozwala na określenie jakie strony kodowe są dostepne dla odpowiedzi

* Accept-Encoding - jest to nagłówek podobny do Accept ale określa kodowanie zawartości jakie jest dostępne w odpowiedzi

* Accept-Language - jest to nagłówek podobny do Accept ale określa zestaw języków naturalnych ktore preferowane są jako odpowiedź na żądanie.

* Authorization - klient użytkownika który chce dokonać autoryzacji przed serwerem, określa zawartość tego pola.

* Expect - służy do określenia, że niektóre zachowania serwera są wymagane przez klienta.

* From - jeżeli jest podane powinno zawierać adres skrzynki email użytkownika używającego wysyłającego żądanie klienta.

* Host - określa adres oraz port serwera zawierającego zasób

* If-Match - pole to jest stosowane razem z metoda aby spowodowac jej warunkowość. Jeżeli klient posiada wiele instancji korzystających wcześniej z zasobu serwera, może sprawdzić że zasób pobrany przez inna instancję jest aktualny, przez podanie w właściwości zasobu w polu If-Match. Pole to zostało pomyślane jako efektywny sposób na zapobieganie niepotrzebnym aktualizacjom.

* If-Modified-Since - jeżeli zasób serwera nie został zmodyfikowany od czasu podanego w polu nie zostanie on zwrócony przez serwer, serwer powinien zwrócić jedynie odpowiedź 304 ( Not Modified )

* If-None-Match - klient posiadający kilka zasobów może sprawdzić czy posiadany zasób odpowiada temu na serwerze, jeżeli nie to pobiera zasób z serwera.

* If-Range - jeżeli klient posiada częśc zasobu i chciałby posiadać całą kopię zasobu z serwera stosuje pole IF-Range w połączeniu z metodą GET.

* If-Unmodified-Since - jeżeli zasób serwera nie został zmodyfikowany od czasu podanego w polu serwer powinien wykonać żądanie tak jakby pole If-Unmodified-Since nie było obecne.

* Max-Forwards - pole to razem z metodą TRACE lub OPTIONS pozwala na ogranicznie ilości proxy lub bram, które mogą przekazać żądanie do następnego serwera. Pole to jest przydatne gdy klient próbuje wyśledzić łańcuch żądań, który nie może dotrzeć do celu.

* Proxy-Authorization - pozwala klientowi na zidentyfikowanie się serwerowi proxy, który tego wymaga.

* Range - pozwala określić ile bajtów danych, chce pobrać klient.

* Referer - pole to służy do przekazania serwerowi informacji o tym skąd zasób został pierwotnie pobrany.

* TE - ??

* User-Agent - pole to zawiera informacje o kliencie używanym przez użytkownika.

Odpowiedź:
Pierwsza linia odpowiedzi jest linią statusu zawiera oddzielone spacją: wersję protokołu, kod statusu, i tekstowe wyjaśnienie, linia zakończona jest znakami CRLF. Kod statusu jest trzy cyfrową liczbą całkowitą określającą status wykonania żądania. Tekstowe wyjaśnienie jest pomocne tylko administratorowi np.: podczas analizowania błędów, klient HTTP nie jest zobligowany do wyświetlania tekstowych wyjaśnień, powinien za to wiedzieć jak poprawnie zanalizować kod statusu. Pierwsza cyfra określa klasę odpowiedzi, dwie pozostałe cyfry nie mają skategoryzowanej roli, klasy przedstawiają się następująco:
- 1xx: Informational - Informacyjna, żądanie otrzymane, następuje realizacja.
- 2xx: Success - Sukces, żądanie zostało poprawnie odebrane, zinterpretowane i zaakceptowane.
- 3xx: Redirection - Przekierowanie, inna akcja musi zostać wykonana aby żądanie zostało wykonane.
- 4xx: Client Error - Błąd klienta, żądanie zawiera niepoprawną składnie lub nie może zostać wykonane.
- 5xx: Server Error - Błąd serwera, serwerowi nie udało się wykonać najprawdopodobnie poprawnego żądania.

Niektóre kody statusu:
* 100 Continue - klient powinien kontynuować ze swoim żądaniem, ten kod jest używany aby poinformować klienta, że wstępna część żądania została otrzymana i nie została jeszcze odrzucona przez serwer. Klient powinien wysyłać żądania a jeżeli jego żądanie zostało już zrealizowane powinien zignorować otrzymany kod statusu.

* 101 Switching Protocols - serwer zrozumiał i jest gotowy na zmianę protokołu zainicjowaną przez klienta.

* 200 OK - żądanie zostało wykonane pomyślnie, informacje przesłane razem z odpowiedzią zależą od metody jaka została zastosowana przez klienta. Mamy więc:
GET - wysłany zostaje zasób.
HEAD - wysłane zostają nagłówki określające zasób.
POST - wysłana odpowiedź zawiera informację określającą lub zawierającą rezultat żądania.
TRACE - odpowiedź zawiera żadanie jakie otrzymał serwer końcowy.

* 201 Created - żądanie zostało wykonane i został stworzony nowy zasób na serwerze, do nowo stworzonego zasobu można odwołać się przez URI zwrócone w odpowiedzi.

* 202 Accepted - żądanie zostało zaakceptowane do przetwarzania ale przetwarzanie nie zostało zakończone.

* 204 No Content - serwer wykonał żądanie ale nie musi wysyłać żadanych dodatkowych infromacji.

* 205 Reset Content - serwer wykonał żądanie i wysyła klientowi informację, że powinien "wyczyścic" interfejs użytkownika za pomocą którego zostało wysłane żądanie.

* 300 Multiple Choices - żądanie o zasób spowodowało, iż serwer odnalazł kilka zasobów spełniających wymagania o różnych lokalizacjach, wysyła więc klientowi informację o zasobach pozwalającą na dalszą negocjację, na którym zaosbie zostaną wykonane żądania.

* 301 Moved Permanently - zasób zmienił swoje URI i wszystkie następne odwołania do zasobu za pomocą starego URI zakończą się nie powodzeniem, klient powinin użyć URI dostarczonego z odpowiedzią.

* 302 Found - zasób tymczasowo zmienił swoje położenie, klient powinien w przyszłości używać nadal tego samego URI, tymczasowe URI przekazywane jest w odpowiedzi.

* 304 Not Modified - klient zastosował "warunkowy GET", posiada dostęp do zasobu ale zasób nie został zmodyfikowany.

* 305 Use Proxy - klient aby dostać dostęp do zasobów serwera musi korzystać z podanego w odpowiedzi serwera proxy.

* 306 (Unused) - kod statusu użuwany w poprzednich wersjach protokołu, obecenie nie używana zarezerwowany do poźniejszych zastosować.

* 400 Bad Request - żądanie nie mogło zostać zinterpretowane przez serwera, z powodu niepoprawnej składni.

* 401 Unauthorized - żądanie wymaga autoryzacji ze strony użytkownika.

* 402 Payment Required - kod statusu zarezerwowany do późniejszych zastosowań.

* 403 Forbidden - serwer poprawnie zinterpretował żądanie ale odmawia wykonania go.

* 404 Not Found - serwer nie odnalazł żądanego zasobu, opisanego za pomocą URI. Nie zostaje powiedziane czy stan jest tymczasowy czy permanentny.

* 405 Method Not Allowed - wysłane żądanie jest nie dozowolone na zasobie określonym przez podane URI.

* 406 Not Acceptable - żądanie wysłane w stosunku do zasobu, nie może zostać wykonane ponieważ zasób ten jest przystowoany do generowania danych i odpowiedzi, nie można na nim zastosować wysłanej metody.

* 407 Proxy Authentication Required - kod statusu podobny do kodu 401 ale w tym wypadku klient musi zidentyfikować się przy pomocy serwera proxy.

* 408 Request Timeout - klient nie wysłał żadnego żądania w czasi w którym serwer był gotowy na otrzymanie od niego żądania. Klient może powtórzyć żądanie w późniejszym czasie.

* 409 Conflict - żądanie nie może zostać zrealizowane spowodu konfliktu z bierzącym stanem zasobu.

* 410 Gone - zasób został usunięty z serwera ale serwer wie gdzie znajduje się obecnie poszukiwany zasób. Sytuacja zasobu na odpytywanym serwerze jest uważana za permanentną.

* 500 Internal Server Error - serwer napotkal na błąd, który spowodował niemożność zrealizowania żądania.

* 501 Not Implemented - serwer nie udostępnia funkcjonalności wymaganej przez żądanie. Jest to odpowiedź chcarakterystyczna dla sytuacji w której serwer nie rozpoznaje metody użytej w żądaniu.

* 503 Service Unavailable - serwer tymczasowo nie może zrealizować żądania, spowodowane jest to przeładowaniem serwera.

* 505 HTTP Version Not Supported - serwer nie obsługuje lub odmawia obsługi protokołu w podanej przez klienta wersji.

Odpowiedź posiada własne pola nagłówka pozwalające serwerowi na podanie dodatkowych danych na temat żądania. Poniżej niektóre z nich:
* Location - nagłówek ten posiada adres przekierowania dla klienta inny niż podany przez klienta URI, serwer podaje adres przekierowania w celu dokończenia żądania lub identyfikacji nowego zasobu.

* Proxy-Authenticate - pole to zawiera schemat identyfikacji jaką musi przeprowadzić klient aby dostać sie do zasobów serwera.

* Server - pole to zawiera informacje dotyczące oprogramowania używanego przez serwer.

* WWW-Authenticate - pole to zawiera schemat identyfikacji wymagany od klienta.


Analiza ruchu sieciowego:
Aby przeanalizować ruch sieciowy związany z protokołem HTTP, użyliśmy programu ethereal, wyłączyliśmy tryb promicious aby mieć dokładny widok pakietów skierowanych i wysyłanych dokładnie do naszego stanowiska. Nasze stanowisko o numerze 4 miało przydzielony adres IP: 10.4.18.4. Korzystaliśmy z przeglądarki Internet Explorer, do celów testowych łączyliśmy się ze stroną http://stud.ics.p.lodz.pl/~rabb/.
Istotne było zapytanie dns wysłane przez system na którym pracowaliśmy, system nie znalazł w pliku hosts wpisu odpowiedniego dla stud.ics.p.lodz.pl, więć resolver DNS wysłał zapytanie DNS do serwera nazw zlokalizowanego pod adresem 172.16.0.12. Zapytanie to można sobie wyobrazić sobie jako pytanie "Czy posiadasz rekord adresu A dla komputera znajdującego się pod nazwą stud.ics.p.lodz.pl?" W odpowiedzi serwer zwraca żądany rekord A z adresem. Całe zapytanie DNS jest kapsułkowane w protokole UDP i wysyłane na port 53. Poniżej znajduje się fragment logu z ethereal zawierający zapytanie DNS ( konkretny fragment odnoszący sie już do samej prośby o rekord A klasy IN [ Internet ] )

Queries
        stud.ics.p.lodz.pl: type A, class IN
            Name: stud.ics.p.lodz.pl
            Type: A (Host address)
            Class: IN (0x0001)

Serwer DNS wysłał odpowiedź zawierającą adres komputera o nazwie domenowej stud.ics.p.lodz.pl jest to 212.51.220.231. Oto fragment odpowiedzi z serwera ( odpowiedź była również kapsułkowana w pakiecie UDP ):

Queries
        stud.ics.p.lodz.pl: type A, class IN
            Name: stud.ics.p.lodz.pl
            Type: A (Host address)
            Class: IN (0x0001)
    Answers
        stud.ics.p.lodz.pl: type A, class IN, addr 212.51.220.231
            Name: stud.ics.p.lodz.pl
            Type: A (Host address)
            Class: IN (0x0001)
            Time to live: 5 hours, 15 minutes
            Data length: 4
            Addr: 212.51.220.231

Na potwierdzenie tego iż podany adres 212.51.220.231 należy do komputera stud.ics.p.lodz.pl, sprawdziliśmy baze whois na stronie www.ripe.net, z niej wyciągnelismy log dla adresu 212.51.220.231.
Obszerny log z dwóch pakietów zapytania i odpowiedzi znajduje się tutaj, rozwienięte są tylko dwa pakiety, plik tekstowy z logami jest częściowo obkomentowany.

Po otrzymaniu adresu IP nastąpiła próba ustanowienia połączenia TCP. Połączenie TCP wymaga trójstopniowej procedury wymiany potwierdzeń, kolejno wykorzystywane są następujące kombinacje znaczników SYN i ACK (Three-way handshake):
SYN = 1 i ACK = 0 - Pakiet otwarcia połączenia
SYN = 1 i ACK = 1 - Potwierdzenie żądania połączenia
SYN = 0 i ACK = 1 - Pakiet danych lub pakiet ACK ( potwierdzenia )
Obok zamieszczamy log z ethereal zawierający przebieg tego trójstopniowego uzgadniania połączenia. W pliku tym zostały dodane komentarze wskazujące na zmieniające się flagi TCP i elementy uzgadniania połączenia.

Po ustanowieniu połączenia przeglądarka www z której korzystaliśmy Mozilla Firefox wysłała żądanie do serwera HTTP o przesłanie zasobu znajdującego się po URI: http://stud.ics.p.lodz.pl/~rabb/
Wysłała żądanie zaczynające się od linji: GET /~rabb HTTP/1.1, mamy tutaj w pierwszej linii podaną metodę żądania oraz absolutną ścieżkę wskazującą na lokalizację zasobu oraz wersje protokołu jakim posługuje się klient w komunikacji z serwerem. Jednak serwer nie będzie mógł zrealizować takiego żądania ponieważ nie ma zasobu znajdującego się pod podanym adresem, jak mówi specyfikacja protokołu HTTP jeżeli w podanym w żądaniu URI znajduje się ścieżka absolutna wskazująca nie na konkretny zasób ( np.: plik ) lecz cały katalog na serwerze, ścieżka powinna być zakończona znakiem "/". Takie zapytanie zostało wysłane celowo aby pokazać, jak zareaguje serwer HTTP na "niepoprawną" ścieżkę absolutną. Serwer zwrócił odpowiedź o kodzie 301 Moved Permanently i w polu nagłówka odpowiedzi: Location zwrócił poprawny URI zasobu: http://stud.ics.p.lodz.pl/~rabb/. Firefox jest na tyle dobrym klientem, że informacje zawarte w odpowiedzi serwera wykorzystał do ponownego wysłania żądania o zasób tym razem żądanie wyglądało następująco: GET /~rabb/ HTTP/1.1. Wysłane żądanie może być zrealizowane i serwer zwrócił odpowiedź o kodzie 200 OK (text/html), przesyłając od razu treść strony www znajdującej się w pliku index.html. W załączonym obok pliku znajduje się dokładniej opisany log z tego krótkiego wstępu pobierania danych ze strony www.

Przeglądarka analizuje treść pobranego dokumentu html w poszukiwaniu wszystkich elementów które musi pobrać takich jak pliki graficzne, muzyczne, pliki z animacjami czy pliki ze skryptami javascript. W przypadku tej prostej strony przeglądarka musi pobrać rysunek samochodziku, aby to wykonać wysyła żądanie: GET /~rabb/Obrazki/samochod.jpg HTTP/1.1 w odpowiedzi serwer potwierdza istnienie obrazka jako zasobu i informuje ile ramek zostanie wysłanych, pierwsza linia odpowiedzi zawiera kod: 200 OK (JPEG JFIF image) oraz informacje o typie przesyłanego zasobu. W załączonym obok pliku znajduje się log z ethereal z przebiegiem łańucha żądań i odpowiedzi.

Kliknięcie na link prowadzący do obrazka, a potem na link prowadzący do pliku tekstowego spowodowało wysłanie kolejnych dwóch żądań HTTP, listing znajduje się tutaj.

Po wyłączeniu przeglądarki połączenie z serwerem jest zamykane. Kiedy połączenie TCP ma być zamknięte, przesyłany jest znacznik FIN, nie powoduje to natychmiastowego rozłączenia. Znacznik przesłany przez obie strony jako sygnał zgody na zakończenie komunikacji. Taki sposób zakończenia połączenia określa się jako zamknięcie łagodne ( graceful close ) co podkreśla że obie strony uzgodniły zamiar. Gdyby jeden z uczestników komunikacji zakończył połączenie nie informując drugiego, tamten mógłby w nieskończoność podejmować próby retransmisji danych, które nigdy nie zostałby odebrane. W kilku słowach na zmianę klient oraz serwer wysyłają do siebie znaczniki FIN i ACK, gdy wszystko zostanie uzgodnione połączenie jest zamykane. Przedstawia to log.

Wiedza tylko wtedy jest wiedzą, kiedy zdobyta została wysiłkiem własnej myśli, a nie wyłącznie dzięki pamięci.

Poprawny XHTML 1.0! Poprawny styl CSS!hacker emblem open source emblem