Rozdział 29.
Porady i wskazówki
na temat serwera WWW

Serwer WWW jest mózgiem każdej witryny, można porównać go do centrum sterowania lotem kosmicznym. Bez niego to, co stworzyłeś, będzie tylko zbiorem nieistotnych i ni­komu niepotrzebnych stron WWW, przechowywanych na czyimś twardym dysku.

Z drugiej strony jest to w końcu tylko program komputerowy, który instaluje się i ustawia, tak jak inne programy. Oprócz tego, że jest odpowiedzialny za publikację Twoich stron w sieci, pozwala także na wykorzystywanie skryptów CGI, map odnośników i zabezpiecza pliki przed nieupoważnionym dostępem (o czym powiem w rozdziale 30. — „Bezpieczeństwo serwera WWW i kontrola dostępu”).

W tym rozdziale opiszę kilka sztuczek, które ułatwią Ci zarządzanie witryną po stronie serwera i sprawią, że będzie ona bardziej przejrzysta dla czytelników. Będą to następujące zagadnienia:

• mechanizm SSI serwerów NSCA oraz jego wykorzystanie do umieszczania na stronach informacji na bieżąco aktualizowanych,

• automatyczne przekierowanie przez serwer połączeń do przeniesionych stron,

• log — jego struktura, wykorzystanie i programy do generowania statystyk,

• tworzenie własnych dokumentów informujących o błędach.

Tak jak w poprzednich rozdziałach, moje uwagi dotyczą przede wszystkim serwerów HTTPD działających w systemie Unix. Jednakże większość podawanych informacji dotyczy serwerów w ogóle, dlatego też treść tego rozdziału może okazać się przydatna nawet wtedy, gdy używasz innego serwera na innej platformie programowej.

Mechanizm NCSA SSI

Mechanizm SSI (ang. Server Side Include) jest udostępniany przez wiele serwerów WWW, umożliwia tworzenie stron WWW przetwarzanych przez serwer i umieszczanie w nich specjalnych poleceń. W momencie zgłoszenia żądania odczytu pliku HTML, serwer przetwarza umieszczone w nim polecenia, a ich wyniki umieszcza w kodzie pliku. Mechanizm SSI pozwala na wykonywanie następujących operacji:

• umieszczanie plików wewnątrz innych (z reguły są to pliki z podpisami lub notki o prawach autorskich),

• umieszczanie na stronie HTML bieżącej daty i czasu,

• umieszczanie na stronie informacji o pliku, na przykład, jego wielkości lub daty ostatniej modyfikacji,

• umieszczanie na stronie wyniku działania skryptu CGI — przykładem może być licznik odwiedzin danej strony.

SSI wprowadza sporą elastyczność dotyczącą typu informacji, które można dołączyć do strony WWW. Wadą tego rozwiązania jest to, że każdy plik zawierający specjalne kody musi być dodatkowo przetworzony przez serwer, co powoduje jego większe obciążenie i wolniejsze ładowanie strony. Oprócz tego wywoływanie skryptów CGI osłabia bezpie­czeństwo serwera.

W tej części rozdziału przedstawię pokrótce każde z wyrażeń, które może zostać umiesz­czone w kodzie strony. Opiszę również, jak skonfigurować serwer i pliki, aby mechanizm SSI mógł zadziałać.

Zarówno teraz, jak i w dalszej części rozdziału przyjmuję założenie, że masz do dyspozycji własny serwer WWW, który możesz konfigurować w dowolny sposób. Jeżeli korzystasz z usług serwera, będącego pod opieką kogoś innego, może okazać się, że nie posiada on opisywanych tu możliwości. Porozmawiaj z jego administratorem i dowiedz się, jakie cechy potrafi on obsłużyć.

Konfiguracja serwera

Pierwszym warunkiem korzystania z mechanizmu SSI jest jego obsługa przez serwer. Jeżeli jest on spełniony, należy jeszcze skonfigurować oprogramowanie tak, aby go uruchomić.

W serwerach opartych o NSCA należy dokonać dwóch modyfikacji w plikach konfiguracyjnych, a więc trzeba:

• dodać opcję Include do dyrektywy Options,

• Zdefiniować specjalny typ dla plików, które mają być przetwarzane przez serwer.

Może się zdarzyć, że serwer, którego używasz, obsługuje SSI, ale sposób włączania tego mechanizmu jest nieco inny. W takim razie należy dokładnie przejrzeć dokumentację i znaleźć odpowiedni opis.

SSI może zostać zainicjowane dla całego serwera lub tylko dla niektórych katalogów. Po­dobnie, pewnym katalogom można odebrać prawo dostępu do tej usługi.

Aby udostępnić SSI dla wszystkich plików w drzewie katalogów serwera, należy dokonać zmian w pliku access.conf, który znajduje się w katalogu konfiguracyjnym (zwykle nosi on nazwę conf).

Plik kontroli dostępu dla całego serwera może znajdować się gdzie indziej i nosić inną nazwę. Jest to zdefiniowane w pliku httpd.conf. W nowszych wersjach serwera Apache, wszystkie dyrektywy konfiguracyjne umieszczane są w pliku httpd.conf, dotyczy to także dyrektyw określających prawa dostępu.

Aby udostępnić SSI dla wszystkich katalogów, dopisz do pliku access.conf następującą linię:

Options Includes

Zamiast umożliwiać przetwarzanie plików znajdujących się we wszystkich katalogach, mo­żesz je ograniczyć tylko do kilku wybranych. Aby włączyć mechanizm SSI tylko dla plików, znajdujących się w katalogu /home/www/includes, musisz w pliku access.conf wpisać następujące linie:

<Directory /home/www/includes>

Options Includes

</Directory>

Włączenia SSI dla konkretnego katalogu można dokonać również za pomocą pliku kontroli dostępu, znajdującego się właśnie w tym katalogu. Plik ten nosi zwykle nazwę .htaccess, a więcej na jego temat opowiem w następnym rozdziale.

Zarówno globalnie, jak i tylko dla określonych katalogów można uaktywnić mechanizm SSI z pewnym ograniczeniem, nie będą wykonywane polecenia, które powodują wywołanie skryptów CGI. W tym celu, zamiast linii podanej powyżej, należy wstawić:

Options IncludesNoExec

Przejdźmy teraz do edycji pliku srm.conf (lub http.conf, w zależności do posiadanej wersji serwera Apache), który powinien również znajdować się w katalo­gu konfiguracyjnym. W tym miejscu należy określić rozszerzenie dla plików HTML, które będą przetwarzane przez serwer i będą zawierały odpowiednie polecenia. Zwykle pliki te posiadają rozszerzenie .shtml. Aby serwer mógł przetwarzać pliki z takim właśnie rozsze­rzeniem, nale­ży dopisać następującą linię:

AddType text/x-server-parsed-html .shtml

Możesz też spowodować, że wszystkie pliki znajdujące się na serwerze będą przezeń przetwarzane:

AddType text/x-server-parsed-html .html

Zwróć jednak uwagę, że jeżeli serwer będzie analizował każdy wysyłany przez siebie plik HTML, jego działanie ulegnie znacznemu spowolnieniu.

Po dokonaniu tych zmian należy ponownie uruchomić serwer, aby je uaktywnić i w zasa­dzie wszystko będzie już przygotowane.

Tworzenie plików z poleceniami SSI

Teraz, kiedy serwer jest już odpowiednio ustawiony, można rozpocząć wstawianie poleceń SSI do plików HTML, tak aby serwer przetwarzał je w momencie, w którym ktoś zażąda dostępu do nich.

Polecenia SSI umieszczane są w komentarzach HTML (w ten sposób są one ignorowane przez serwery, które nie wiedzą, co to jest SSI). Mają one swój specyficzny format, który wygląda następująco:

<!--#polecenie arg1="wartość1"-->

W wyrażeniu tym polecenie oznacza polecenie SSI, które zostanie wykonane (np. include, exec lub echo — z każdym z nich zapoznasz się bliżej, kontynuując lekturę tego rozdziału). Każde polecenie posiada jeden lub więcej argumentów, których wartości podawane są w cudzysłowach. Tak skonstruowane wyrażenie można umieścić w dowolnym miejscu kodu HTML. Po przetworzeniu pliku przez serwer całość komentarza zostanie zastąpiona przez to, co jest wynikiem wykonania danego polecenia: może być to zawartość innego pliku, war­tość zmiennej lub efekt działania skryptu.

Aby serwer wiedział, że powinien przetworzyć dany plik, należy nadać mu odpowiednie rozszerzenie (to samo, które zostało zdefiniowane w pliku konfiguracyjnym, czyli .shtml). Jednakże, jeżeli skonfigurowałeś serwer tak, aby przetwarzał wszystkie pliki, nie musisz zmie­niać rozszerzenia.

Wiele z powstających obecnie, bardzo rozbudowanych serwerów WWW zawiera różnorakie mechanizmy, umożliwiające tworzenie dość złożonych skryptów. Jednym z przykładów takich rozwiązań jest środowisko tworzenia aplikacji LiveWire firmy Netscape, które umożliwia wykonywanie przez serwer programów w języku JavaScript.

Konfiguracja SSI

Istnieje polecenie SSI, które nie powoduje wstawiania żadnych dodatkowych elementów, lecz służy do konfiguracji formatu innych poleceń. Polecenie #config określa konfigurację wszystkich innych wyrażeń SSI, występujących po nim w danym pliku HTML. #config może posiadać trzy argumenty.

errmsg	Jeżeli w trakcie wykonywania polecenia SSI wystąpi błąd, na stronie HTML oraz w logu błędów pojawi się komunikat określony za pomocą tej opcji.
timefmt	Argument ten określa format wyświetlania daty oraz czasu i jest wykorzystywany przez wiele poleceń SSI. Standardowy format wygląda następująco: Wednesday, 14-May-98 21:04:46
sizefmt	Ten argument określa format wyświetlania wartości polecenia SSI, które zwraca rozmiar zadanego pliku. Jego możliwe wartości to „bytes”, która powoduje podanie pełnej liczby bajtów oraz „abbrev”, która sprawia, że liczba jest przeliczana na kilobajty lub megabajty oraz dodatkowo zaokrąglana. Standardowo przyjmowana jest wartość „abbrev”.

Oto kilka przykładów użycia polecenia #config:

<!--#config errmsg="Wystąpił błąd"-->

<!--#config timefmt="%m/%d/%y"-->

<!--#config sizefmt="bytes"-->

<!--#config sizefmt="abbrev"-->

Tabela 29.1 przedstawia elementy możliwe do wykorzystania przy specyfikacji formatu daty i czasu za pomocą polecenia timefmt. Pełną ich listę można znaleźć w systemie pod­ręczników Uniksa (man strftime).

Tabela 29.1.

Formaty daty i czasu

Format	Efekt
%c	Pełna data i czas: Thu, May 21 20:45:34 1998.
%x	Skrócona data: 05/21/98.
%X	Skrócony czas (24 godziny): 20:45:44.
%b	Skrócona nazwa miesiąca: Jan, Feb, Mar.
%B	Pełna nazwa miesiąca: January, February, March.
%m	Numer miesiąca (od 1 do 12).
%a	Skrócona nazwa dnia tygodnia (Mon, Tue, Thu).
%A	Pełna nazwa dnia tygodnia (Monday, Tuesday).
%d	Numer dnia tygodnia (od 1 do 7).
%y	Skrócony rok (96, 97, 98).
%Y	Pełny rok (1996, 1997, 1998).
%H	Aktualna godzina (wg zegara 24-godzinnego).
%I	Aktualna godzina (wg zegara 12-godzinnego).
%M	Aktualna minuta (od 0 do 60).
%S	Aktualna sekunda (od 0 do 60).
%p	a.m. lub p.m. — wskazanie pory przed lub popołudniowej.
%Z	Strefa czasowa (EST, PST, GMT).

Włączanie innych plików do stron WWW

Najprostszym zastosowaniem SSI jest włączanie do plików HTML zawartości innych pli­ków. Służy do tego polecenie #include wraz z argumentami file lub virtual:

<!--#include file="signature.html"-->

<!--#include virtual="~/foozle/header.html"-->

Argument file służy do określania względnej ścieżki dostępu do włączanego pliku (względem pliku bieżącego). W pierwszym przykładzie plik singniture.html znajduje się w tym samym katalogu, co edytowana strona. W ten sposób można również włączać pliki znajdujące się w podkatalogach katalogu bieżącego (np. file=signatures/mysig.html), nie można natomiast odwoływać się do katalogów nadrzędnych (co oznacza, że w ścieżce nie może znaleźć się symbol „..”).

Argument virtual służy do określenia pełnej ścieżki dostępu do włączanego pliku w postaci, w jakiej pojawia się w URL-u, nie w systemie operacyjnym. Jeżeli więc URL pliku będzie następujący: http://myhost.com/~myhomedir/file.html, ścieżka będąca argumentem polecenia #include powinna wyglądać tak: /~myhomedir/file.html (bez pierwszego ukośnika).

Plik, który jest w ten sposób włączany do strony, może być zwykłym plikiem HTML, ale może też zawierać dalsze polecenia SSI (w ten sposób można stworzyć kilka poziomów zagnieżdżenia). Za pomocą #include nie można jednakże zamieszczać skryptów CGI, do tego służy polecenie #exec, o którym będziesz mógł przeczytać w dalszej części tego rozdziału — „Wyniki działania poleceń i skryptów jako część stron WWW”.

SSI pozwala na umieszczanie na stronach wartości predefiniowanych zmiennych, takich jak nazwa czy data ostatniej modyfikacji danego pliku HTML lub bieżąca data.

Do wyświetlania wartości zmiennych służy polecenie #echo oraz argument var z nazwą zmiennej:

<!--#echo var="LAST_MODIFIED"--><P>Dzisiejsza data:

<!--#echo var= "DATE_LOCAL"--></P>

Tabela 29.2 przedstawia kilka zmiennych, które mogą zostać wyświetlone za pomocą pole­cenia #echo.

Tabela 29.2.

Zmienne SSI

Zmienna	Wartość
DOCUMENT_NAME	Nazwa bieżącego pliku.
DOCUMENT_URL	Ścieżka do bieżącego dokumentu w postaci URL.
DATE_LOCAL	Bieżąca data w lokalnej strefie czasowej.
DATE_GMT	Bieżąca data w czasie Greenwich (GMT).
LAST_MODIFIED	Data i czas ostatniej modyfikacji bieżącego dokumentu.

Ćwiczenie 29.1: Tworzenie automatycznie wstawianego podpisu

Jeżeli stosowałeś się do moich rad z poprzednich rozdziałów, każda stworzona przez Ciebie strona WWW zwieńczona jest podpisem lub znacznikiem adresu, który zawiera Twoje imię i nazwisko, informacje kontaktowe itp. Jednakże, za każdym razem, kiedy zdecydujesz się zmienić coś w tym podpisie, zmuszony jesteś robić to w każdym pliku, co może wyprowa­dzić z równowagi nawet najbardziej cierpliwego człowieka.

Włączanie do każdej strony pliku z podpisem jest znakomitym zastosowaniem mechanizmu SSI, pozwala bowiem na przechowywanie go poza właściwymi stronami. Wtedy wprowa­dzenie do niego jakichkolwiek poprawek staje się banalnie proste, wystarczy zmienić tylko jeden plik i po sprawie.

W naszym ćwiczeniu spróbujemy utworzyć dokument HTML, który będzie zawierał pole­cenie włączenia pliku z podpisem. Ten plik będzie z kolei zawierał aktualna datę, wstawia­ną również za pomocą SSI. Końcowy rezultat, jaki powinniśmy uzyskać, widoczny jest na rysunku 29.1 (data będzie oczywiście codziennie inna).

Rysunek 29.1. Plik z podpisem włączony do dokumentu

Rozpocznijmy od utworzenia pliku z podpisem. Znajdą się w nim standardowe informacje umieszczane w tym miejscu strony (notka o prawach autorskich, dane kontaktowe itp.), po­przedzone poziomą linią:

<HR>

<ADDRESS>

Ta strona: Copyright &#169 1995 Zuzanna Agawa [e-mail]

</ADDRESS>

Ponieważ plik ten będzie częścią innej strony, nie ma potrzeby umieszczania w nim znaczników struktury dokumentu, takich jak <HTML> czy <HEAD>.

Żeby było ciekawiej, spróbujemy w pliku z podpisem umieścić bieżącą datę. Aby to wyko­nać, wstawimy polecenie #echo wyświetlające wartość zmiennej DATE_LOCAL, poprzedzone krótkim tekstem:

<BR>Dzisiejsza data: <!--#echo var="DATE_LOCAL"-->

Zachowajmy ten plik pod nazwą signature.shtml. Teraz należy umieścić go na serwerze WWW i przetestować w różnych przeglądarkach. Rysunek 29.2 prezentuje efekt dotychczasowej pracy. W zasadzie wszystko jest w porządku, ale data prezentuje się raczej nieciekawie. Byłoby lepiej, gdyby na stronie pojawiał się tylko dzień, miesiąc i rok.

Aby zmienić format daty, należy skorzystać z polecenia SSI #config oraz dyrektywy timefmt %x (zgodnie z opisem w tabeli 27.1 będzie to format, który chcemy uzyskać). Wyrażenie to może znaleźć się w dowolnym miejscu pliku HTML, ale koniecznie przed


Rysunek 29.2. Plik z podpisem

poleceniem #include. W naszym przykładzie umieścimy je w pierwszej linii. Ostateczna postać pliku signature.shtml wygląda następująco:

<!--#config timefmt="%x"-->

<HR>

<ADDRESS>

Ta strona: Copyright &#169 1995 Zuzanna Agawa [e-mail]

<BR>Dzisiejsza data: <!--#echo var="DATE_LOCAL"-->

</ADDRESS>

Przejdźmy teraz do strony, w której zawarty zostanie plik z podpisem. Wykorzystamy do tego celu skróconą wersję dobrze nam znanej strony głównej ogrodu kaktusów Zuzanny. Oto jej kod HTML:

<HTML>

<HEAD>

<TITLE>Ogród kaktusów Zuzanny: Katalog</TITLE>

</HEAD>

<BODY>

<IMG SRC="cactus.gif" ALIGN=MIDDLE>

<STRONG>Ogród kaktusów Zuzanny</STRONG>

<H1>Wybór i zamawianie roślin</H1>

<UL>

<LI><A HREF="browse.html">Obejrzyj nasz katalog</A>

<LI><A HREF="order.html">Jak zamówić</A>

<LI><A HREF="form.html">Formularz zamówienia</A>

</UL>

</BODY>

</HTML>

Na końcu pliku (zaraz po znaczniku końca listy, przed </BODY>) wstawimy linię z pole­ceniem SSI:

<!--#include file="signature.shtml"-->

Zachowaj ten plik z odpowiednim rozszerzeniem, które pozwoli na jego przetworzenie przez serwer (niech będzie cactus.shtml). Kiedy wpiszesz w przeglądarce jego URL, za­równo on sam, jak i plik z podpisem zostanie przetworzony przez serwer, a podpis wraz z datą znajdą się na właściwym miejscu.

Dołączanie informacji o pliku

Polecenia #fsize i #flastmod pozwalają na zamieszczenie danych o wielkości i dacie ostatniej modyfikacji przetwarzanego pliku, czego nie można było wykonać za pomocą #include. Argumenty obydwu tych poleceń są identyczne, jak w przypadku #include.

file	Określa nazwę pliku podaną względem bieżącego katalogu.
virtual	Określa pełną ścieżkę dostępu do pliku w postaci, takiej jak w URL.

Format wartości polecenia #fsize zależny jest od uprzednio zdefiniowanej dyrektywy #config sizefmt. Jeżeli, na przykład, wielkość pliku signature.html wynosi 223 bajty, poniższa linia spowoduje wyświetlenie komunikatu: Ten plik ma wielkość 1K bajtów.

<BR>Ten plik ma wielkość <!--#fsize file="signature.shtml"--> bajtów

Natomiast po przetworzeniu takiej sekwencji, na stronie pojawi się napis: Ten plik ma wielkość 223 bajtów:

<!--#config sizefmt="bytes"-->

<BR>Ten plik ma wielkość <!--#fsize file="signature.shtml"--> bajtów

W przypadku polecenia #flastmod format zwracanych danych zależny jest od ustawienia #config timefmt. Poniższe przykładowe linie spowodują wyświetlenie komunikatu: Ostatnia modyfikacja pliku: 5/26/01 (przy założeniu, że plik signature.html był rzeczywiście ostatnio poprawiany tego dnia)

<!--#config timefmt="%x"-->

<BR>Ostatnia modyfikacja pliku:

<!--#flastmod file="signature.shtml"-->

Wyniki działania poleceń i skryptów jako część stron WWW

Jeżeli opisane do tej pory polecenia SSI nie spełniają Twoich oczekiwań, masz możliwość uzupełnienia tych braków za pomocą poleceń systemu operacyjnego lub skryptów CGI. Mogą one być umieszczane na stronach HTML i uruchamiane przez serwer WWW, a rezul­tat ich działania pojawi się w kodzie przesyłanym do przeglądarki. Do realizacji tego typu zadań służy polecenie SSI #exec.

#exec może posiadać dwa argumenty.

cmd

Nazwa polecenia, które może zostać uruchomione przez shell Bourne'a (/bin/sh). Może być to polecenie systemu operacyjnego (np. grep lub echo) lub napisany przez Ciebie skrypt (w takim przypadku należy podać pełną ścieżkę dostępu do niego).

cgi

Nazwa i ścieżka dostępu do skryptu CGI w postaci, jaka pojawia się w adresie URL. Skrypt uruchamiany w ten sposób nie różni się niczym od innych skryptów, a więc w pierwszej linii musi zawsze zwrócić kontekst i może z powodzeniem wykorzystywać wszystkie zmienne CGI, o których pisałam w rozdziale 18. — „Skrypty CGI dla początkujących”. Oprócz tego można tu wykorzystać wszystkie zmienne, które pojawiają się przy okazji polecenia #echo, a więc DATE_LOCAL, DOCUMENT_NAME itd.

Oto klika przykładów uruchamiania skryptów z wykorzystaniem SSI:

<!--#exec cmd="last | grep lemay | head"-->

<!--#exec cmd="usr/local/bin/printinfo"-->

<!--#exec cgi="cgi-bin/pinglaura"-->

Jedyny kłopot z uruchamianiem skryptów CGI za pomocą poleceń SSI polega na tym, że nie można w ten sposób przekazywać do skryptu danych, umieszczanych po jego nazwie, czyli nie można użyć poniższego wywołania:

<!--#exec cgi="cgi-bin/test.cgi/path/to/the/file"-->

Jak więc przekazać skryptowi jakiekolwiek argumenty? Można to zrobić, wykorzystując URL, prowadzący do pliku .shtml, w którym znajduje się polecenie SSI wywołujące skrypt.

Że co proszę? Czy mógłabyś powtórzyć to zdanie?

Właśnie tak. Jest to dość skomplikowana procedura i nie ma raczej wielkiego sensu. Oto przykład, który być może odrobinę przybliży tę ideę. Załóżmy, że dysponujemy skryp­tem o nazwie docolor, który wymaga podania dwóch argumentów — współrzędnych x i y — a wynikiem jego działania jest numer koloru (jest to przykład czysto teoretyczny, nie wiem po co program miałby zwracać numer koloru, ale coś takiego akurat przyszło mi do głowy).

Oprócz tego mamy też plik color.shtml, w którym znajduje się linia wywołująca skrypt z zakodowanymi argumentami (na przykład 45 i 64). Jest to więc następujące wywołanie:

<P>Twój kolor, to <!--#exec cgi="cgi-bin/docolor?45,64"-->.</P>

Skrypt uruchomiony bezpośrednio z przeglądarki lub jako połączenie z pliku HTML poradzi sobie z takim wywołaniem, ale próba takiego przekazania argumentów do skryptu wywoływanego za pomocą SSI skończy się błędem.

Możesz jednak umieścić owe argumenty w URL-u prowadzącym do pliku color.shtml. Za­łóżmy, że istnieje trzeci plik, z którego poprowadzimy połączenie do naszego pliku:

<A HREF="color.shtml">Sprawdź kolor</A>

Aby skrypt został wywołany z żądanymi argumentami, należy umieścić je w powyższym połączeniu:

<A HREF="color.shtml?45,64">Sprawdź kolor</A>

W pliku color.shtml należy teraz poprawić wywołanie skryptu, co polega na usunięciu nieszczęsnych argumentów i znaku zapytania po jego nazwie.

<P>Twój kolor, to <!--#exec cgi="cgi-bin/docolor"-->.</P>Gotowe.

Teraz skrypt będzie mógł pobrać argumenty w zwykły sposób (poprzez linię poleceń lub zmienną QUERY_STRING) i zwrócić wartość wyliczoną na ich podstawie.

Ćwiczenie 29.2: Tworzymy licznik trafień

Istnieje wiele programów, które można wykorzystać do umieszczania na stronie tzw. licz­nika trafień, niektóre z nich potrafią nawet wygenerować graficzne rysunki liczników. W tym przykładzie spróbujemy stworzyć prosty licznik, który będzie równie skuteczny w działaniu.

Do utworzenia licznika trafień potrzebne będą następujące elementy:

• plik zliczający, zawierający tylko i wyłącznie jedną liczbę (liczbę dotychczasowych odczytów strony),

• prosty program, który zwraca właściwą liczbę i aktualizuje plik zliczający,

• polecenie SSI umieszczone w pliku, którego odczyty chcemy zliczać, jego zadaniem będzie uruchamianie skryptu.

Przyjrzyjmy się bliżej naszemu plikowi zliczającemu. Liczba w nim zawarta reprezentuje ilość dotychczasowych odczytów strony WWW. Możesz wpisać do niego liczbę 1 albo też przeszukać logi serwera i znaleźć rzeczywistą wartość. Utwórzmy więc ten plik. W tym przykładzie nadamy mu nazwę home.count i jako pierwszą wpiszemy liczbę 0:

echo 0 > home.count

Poza tym prawo zapisu do tego pliku musi być tak ustawione, aby mógł tego dokonywać serwer WWW (pamiętaj, że jest on uruchamiany jako użytkownik nobody). Prawo zapisu dla każdego użytkownika można ustawić w następujący sposób za pomocą polecenia chmod:

chmod a+w home.count

Drugim potrzebnym elementem jest skrypt, który wyświetla liczbę i aktualizuje plik. Można do tego wykorzystać skrypt CGI (wiele popularnych liczników z nich korzysta), ale dużo prościej jest posłużyć się zwykłym skryptem shell-owym. Oto jego kod:

#!/bin/sh

countfile=/home/www/Web/Examples/More_HTML/chap09/home.count

nums=`cat $countfile`

nums=`expr $nums + 1`

echo $nums > /tmp/countfile.$$

cp /tmp/countfile.$$ $countfile

rm /tmp/countfile.$$

echo $nums

Jedynym miejscem, w którym musisz dokonać zmian jest linia druga. Zmienna countfile powinna zawierać pełną ścieżkę do pliku, który posłuży Ci jako plik zliczający. W mojej wersji znajduje się on w katalogu, zawierającym pozostałe przykłady z tego rozdziału.

Zapisz skrypt w tym samym katalogu, w którym uprzednio umieściłeś plik zliczający oraz stronę, której odczyty będziesz liczył. Nie ma potrzeby kopiowania go do katalogu cgi-bin. Poza tym powinieneś nadać mu atrybut wykonywalności i kilkakrotnie uruchomić, aby sprawdzić, czy rzeczywiście aktualizuje plik zliczeń. Mój skrypt nazywa się homecounter.

W tej chwili pozostaje nam tylko utworzenie strony, na której znajdzie się licznik. Wyko­rzystałem do tego celu stronę prywatną niejakiego Janka (który, jak widać, nie jest zbyt twórczym osobnikiem):

<HTML><HEAD><TITLE>Prywatna strona Janka</TITLE>

</HEAD></BODY>

<H1>Prywatna strona Janka</H1>

<P>Cześć, nazywam się Janek. Jesteś

<!--#exec cmd="./homecounter"--> osobą, która odwiedziła moją stronę.

</BODY></HTML>

Przedostatnia linia jest tu najistotniejsza. Uruchamia ona skrypt homecounter w bieżącym katalogu (dlatego właśnie w cudzysłowie znalazł się zapis ./homecounter, a nie po prostu homecounter). Skrypt ten na podstawie home.count wylicza aktualną liczbę trafień, po czym umieszcza ją w pliku oraz na stronie HTML. Jeżeli więc zapiszemy stronę z rozszerzeniem .shtml i otworzymy ją w przeglądarce, powinniśmy otrzymać efekt widoczny na rysunku 29.3.

Rysunek 29.3. Strona Janka z licznikiem trafień

I o to chodziło! Jest to przykład prostego licznika, który możesz z powodzeniem stworzyć własnymi siłami. Oczywiście, większość liczników wykorzystywanych w sieci WWW to nieco bardziej złożone programy, które pozwalają na wykorzystywanie jednego skryptu do zliczania trafień na wielu stronach i dodatkowo przedstawiają liczby w postaci przyjemnych dla oka obrazków GIF, ale tak naprawdę ich działanie opiera się na tych samych zasadach, z którymi przed chwilą się zapoznałeś.

Jeżeli jesteś zainteresowany innymi programami, realizującymi funkcje licznika trafień, zajrzyj na listę, znajdującą się na stronach Yahoo!:

http://dir.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/Programming /Access_Counters/.

Przekierowanie pliku

Jeżeli miałeś to szczęście i opublikowana przez Ciebie prezentacja stała się popularna wśród użytkowników sieci WWW, na pewno przyszło Ci do głowy, że jeżeli kiedykolwiek będziesz zmuszony do przeniesienia stron na inny serwer lub nawet w obrębie tego samego systemu plików, wszystkie połączenia prowadzące do nich (a przecież nie jesteś w stanie zliczyć, ile ich jest na całym świecie) przestaną być aktualne. Ludzie przyzwyczajeni do tego, że ich ulubione strony znajdują się pod takim, a nie innym adresem, będą bardzo za­wiedzeni i na pewno będą co jakiś czas sprawdzać, czy przypadkiem nie pojawiły się one z powrotem.

Co więc możesz zrobić, jeżeli z przyczyn od siebie niezależnych musisz przenieść prezen­tację gdzie indziej?

Jeżeli cały manewr wykonywany jest w obrębie jednego serwera i polega tylko na przenie­sieniu plików do innych katalogów, najprostszym sposobem jest utworzenie odpowiednich połączeń symbolicznych (tylko w systemie Unix, za pomocą polecenia ln), prowadzących do nowego położenia stron. W ten sposób wszystkie adresy URL będą wciąż prawidłowe i czytelnicy nie odczują żadnej zamiany.

W innym wypadku powinieneś w poprzedniej lokalizacji umieścić stronę z komunikatem „Strona zmieniła adres”. Przykład takiej strony przedstawia rysunek 29.4.

Rysunek 29.4. Komunikat o zmianie adresu strony

Innym sposobem sprawowania kontroli nad przeniesionymi plikami jest mechanizm prze­kierowywania adresu przez serwer WWW. W plikach konfiguracyjnych można zdefiniować pewne reguły, które będą instruować serwer, aby po otrzymania żądania przesłania plików, których już nie ma, przekierowywał przeglądarkę pod inny, aktualny adres (patrz rysunek 29.5). W ten sposób manewr przenoszenia prezentacji na inny serwer nie musi zakończyć się dezaktualizacją wszystkich połączeń, prowadzących do niej z różnych miejsc.

Rysunek 29.5. Przekierowywanie adresów

Do tworzenia przekierowań w plikach konfiguracyjnych serwera HTTPD służy dyrektywa Redirect, wywoływana z dwoma argumentami. Pierwszy z nich to ścieżka dostępu do plików, która pojawia się w nieaktualnych adresach URL, drugi natomiast to aktualny URL prezentacji.

Składnia dyrektywy Redirect jest następująca:

Redirect /stare/pliki http://nowastrona/nowemiejsce/pliki

Pierwszy argument (/stare/pliki) to ścieżka dostępu do starych plików (taka, jaka poja­wia się w adresach URL prowadzących do tych plików, ale bez przedrostka http:// i naz­wy serwera), drugi natomiast to pełny adres URL ich nowej lokalizacji. Metoda ta może być wykorzystywana zarówno dla pojedynczych plików, jak i całych katalogów.

Pamiętaj, że aby zmiany wprowadzone w plikach konfiguracyjnych przyniosły skutek, należy ponownie uruchomić serwer.

Logi serwera WWW

Za każdym razem, kiedy ktoś odczytuje plik z serwera WWW lub przesyła informacje wpisane w formularzu, w specjalnym pliku, zwanym dziennikiem serwera lub z angielskie­go logiem, zapisywane są wszelkie dane dotyczące tej operacji, czyli jej czas, nazwa pobra­nego pliku oraz nazwa lub adres komputera, z którego nadeszło żądanie. Jeżeli ktoś zażąda pliku o niewłaściwej nazwie, przerwie połączenie w trakcie przesyłania strony lub też poja­wi się jakikolwiek inny problem, zostanie to z kolei odnotowane w logu błędów.

Informacje znajdujące się w tych logach mogą okazać się bardzo pożyteczne dla projektanta prezentacji WWW. Pozwalają na śledzenie liczby odczytów (gdzie odczyt to pojedyncze żądanie z jednego komputera) każdego z plików, stopnia zainteresowania czytelników poszczególnymi stronami oraz kolejności, w jakiej poruszają się oni pomiędzy poszczególnymi elementami prezentacji. Sygnalizują też wszelkie nieudane próby połączeń wewnątrz prezentacji, co pozwala na wykrycie ewentualnych błędnie zdefiniowanych adresów.

Logi serwera oraz standardowy format logu

Funkcja zapisu informacji do logów jest standardowo włączona. W przypadku serwera Apache oraz NCSA HTTPD pliki access_log oraz error_log powinny znajdować się w katalogu log, który można znaleźć na tym samym poziomie drzewa katalogów, na którym znajduje się katalog conf (tzw. ServerRoot).

Większość serwerów zapisuje informacje do logów w standardowym formacie logu, który stał się normą, ponieważ każdy, kto go używa, zapisuje te same informacje w takiej samej kolejności. Każde żądanie, napływające do serwera zapisywane jest w osobnej linii. Rysunek 29.6 przedstawia schemat standardowego formatu logu (linia została tu podzielona na dwie części, aby mogła zmieścić się na stronie).

W przypadku logów należy zwrócić uwagę na następujące fakty:

• każdy plik wysłany przez serwer to jeden odczyt. Chcąc przesłać stronę, na której znajdują się cztery rysunki, musisz liczyć się z tym, że serwer musi w sumie przekazać pięć plików, co spowoduje zarejestrowanie w logu pięciu odczytów (1 to plik HTML, pozostałe 4 to pliki graficzne), oczywiście pod warunkiem, że przeglądarka potrafi wyświetlać grafikę. Nie chcę przez to powiedzieć, że jeżeli 10 ludzi zechce obejrzeć twoją stronę, będziesz mógł poszczycić się 50 odczytami — będzie ich dokładnie 10. Nie należy mylić ze sobą odczytów strony i odczytów plików, które się na nią składają. Taki sposób liczenia jest bardzo mylący;

Rysunek 29.6. Standardowy format logu

Nazwa użytkownika (przekazywana przez protokół identyfikacyjny) Nazwa użytkownika (autoryzowana przez serwer) Nazwa komputera Data death.lne.com - lemay [01/May/1995: 17:44:34 +0500] "GET /lmay/ HTTP/1.0" 200 3472 Plik Wersja Ilość wysłanych HTTP bajtów Metoda Kod zwrotny (GET, POST) HTTP

• w logu rejestrowane są wszystkie żądania pobrania plików z serwera, także te błędne, odnoszące się do nieistniejących stron. Dlatego też znajdzie się tam zapis wszystkich udanych i nieudanych prób odczytu Twoich stron;

• odczyt katalogu (na przykład, http://mysite.com/) i odczyt standardowej strony z tego katalogu (http://mysite.com/index.html) rejestrowane są w logu jako osobne zapisy, choć tak naprawdę powodują odczyt tego samego pliku (serwer po otrzyma­niu żądania bez nazwy pliku dokonuje przekierowania do pliku o nazwie standardowej). Pamiętaj o tym podczas liczenia odczytów takiej strony;

• nie wszystkie żądania pobrania stron zawierających obraz spowodują pobranie tych obrazów. Jeżeli przeglądarka okaże się tekstowa lub też przeglądarka graficzna będzie miała wyłączoną funkcję odczytu obrazów, w logu znajdzie się zapis odczytu strony, nie będzie jednak żadnych zapisów dotyczących obrazów. Dlatego też zwykle liczba odczytów obrazów jest mniejsza od liczby odczytów strony.

Kilka uwag na temat buforowania

Buforowanie to mechanizm przeglądarki, który umożliwia lokalne zapisywanie kopii często odwiedzanych stron. Jeżeli za wszelką cenę pragniesz poznać dokładną liczbę i kolejność odczytów Twoich stron, wiedz, że buforowanie może prowadzić do powsta­wania dziwnych zapisów w logu serwera.

Spójrz na poniższy, prosty przykład. Załóżmy, że mamy do dyspozycji proste drzewko zło­żone z trzech plików, takie jak pokazano na rysunku 29.7. Tak naprawdę trudno to nazwać drzewem, jest to po prostu strona główna z połączeniami do dwóch plików.

Rysunek 29.7. Prosta struktura stron WWW

Załóżmy teraz, że ktoś zechce obejrzeć wszystkie te strony. Rozpocznie on najprawdopo­dobniej swoją wędrówkę od strony głównej, później przejdzie do strony A.html, wycofa się do strony głównej i odczyta stronę B.html.

Jednakże efektem tych kilku operacji będzie następujący zapis w logu: (uprościłam go troszkę, aby był bardziej przejrzysty):

reader.com - - [28/Apr/1997] "GET /index.html"

reader.com - - [28/Apr/1997] "GET /A.html"

reader.com - - [28/Apr/1997] "GET /B.html"

W oparciu o te informacje należałoby przypuszczać, że czytelnik przeszedł bezpośrednio z pliku A.html do B.html, co jest przecież niemożliwe. Gdzie podział się odczyt pliku index.html, który powinien się znaleźć pomiędzy A i B?

Otóż odczyt taki nie miał miejsca, nie został więc odnotowany w logu. Przeglądarka zapi­sała lokalnie kopię pliku index.html i w chwili, gdy użytkownik wycofał się do tej stro­ny, została ona odczytana z jego lokalnego dysku, a nie z serwera.

W trakcie przeglądania sieci WWW przeglądarka, która potrafi lokalnie buforować odwie­dzane strony, może wydatnie przyspieszyć całą zabawę, nie musimy wtedy za każdym razem wyczekiwać na załadowanie stron, które raz już widzieliśmy. Jest to również bardzo pożyteczny mechanizm w przypadku stron, na których wielokrotnie wykorzystywany jest ten sam obraz. Przeglądarka odczytuje z sieci tylko jedną jego kopię, po czym wyświetla ją dowolną ilość razy, korzystając z tego, co wcześniej umieściła w pamięci lub na dysku.

Negatywną cechą buforowania jest jednak fakt, że pozostawia ono luki w logach serwera. W ten sposób rejestrowana jest mniejsza liczba odczytów niż byłoby to w przypadku, gdyby przeglądarka nie wykonywała tego typu operacji.

Jeszcze gorsze są serwery, które mają możliwość buforowania. Są to tzw. serwery pośredniczące (ang. proxy server), wykorzystywane przez duże przedsiębiorstwa i serwisy komercyjne. Jeżeli taki serwer będzie otrzymywał wiele żądań odczytu Twoich stron, pochodzących od jego wewnętrznych użytkowników, utworzy swoją własną kopię plików, aby nie pobierać ich z Twojego serwera, co przyspieszy ich ładowanie w prze­glądarce użytkownika. W ten sposób setki osób może przeglądać Twoje strony, a Ty nie będziesz miał o tym żadnych informacji w swoich logach.

Buforowanie jest jedną z głównych przeszkód, które uniemożliwiają dokładne określenie liczby czytelników stron WWW. To, jak poradzisz sobie z lukami w logach, zależy tylko i wyłącznie od Ciebie, a także od tego, czy Cię to w ogóle obchodzi. Jeżeli przeglądasz logi, aby stwierdzić, w jakiej kolejności czytelnicy odczytują strony, będziesz mógł samemu wypełnić luki spowodowane buforowaniem plików przez przeglądarki. Jeżeli zaś interesują Cię przede wszystkim liczby odczytów poszczególnych stron, będziesz musiał dodać do swoich wyliczeń mały procent przeznaczony na zapisy, które niewątpliwie pojawiłyby się, gdyby nie nieszczęsne buforowanie.

Możesz też oszukać przeglądarki i zabronić im buforowania stron. Istnieje na to pewien sposób, ale nie gwarantuję, że będzie on skuteczny w przypadku wszystkich przeglądarek i systemów.

Pamiętasz jeszcze znacznik <META HTTP-EQUIV>? Mówiliśmy o nim w rozdziale 13. — „Multimedia: dodawanie dźwięków, obrazów wideo i innych elementów multimedialnych”, przy okazji omawiania techniki samoczynnego pobierania stron przez przeglądarki. Można go również wykorzystać do zamieszczenia specjalnego nagłówka, mówiącego serwerowi lub przeglądarce, że nie może buforować tej strony:

<HTML>

<HEAD>

<TITLE>Moja strona, nigdy nie buforowana</TITLE>

<META HTTP-EQUIV="Pragma" CONTENT="nie ukryta">

</HEAD>

<BODY>

... zawartość strony ...

</BODY>

</HTML>

Strona z takim znacznikiem nie będzie buforowana przez żaden serwer pośredniczący ani przez żadną przeglądarkę, co oznacza, że za każdym razem będzie ponownie przesyłana po łączach sieciowych z macierzystego serwera. Pamiętaj przy tym, że jeżeli strona odczytywana po raz pierwszy ładuje się dość długo, będzie się również wolno ładować za każdym kolejnym razem, co może zdenerwować czytelników. Jeżeli już zdecydujesz się na wykorzystanie tego tricku na swoich stronach, używaj go tylko na tych mających dla Ciebie istotne znaczenie (np. na stronach głównych) lub też w plikach, których zwartość jest często zmieniana.

Tworzenie statystyk na podstawie logów

Jeżeli tylko masz dostęp do logów serwera WWW, możesz skorzystać z usług prostych programów, które na ich podstawie wygenerują różnego rodzaju statystyki. I tak poniższe polecenie Uniksa (dostępne także w systemach SunOS i Linux) drukuje listę zawierającą liczbę odczytów poszczególnych plików, uporządkowaną malejąco (access.log to nazwa pliku, zawierającego log):

awk '{print $7}' access_log | sort | uniq -c | sort -n -r

Co tak właściwie robi to polecenie? Jego pierwsza część (zaczynająca się od awk) odczytuje siódme pole z logu, które zawiera nazwę pliku. Polecenie sort sortuje wszystkie nazwy, jednocześnie je grupując. Trzecie polecenie (uniq) usuwa wszystkie powtarzające się linie z wyjątkiem jednej, ale oprócz tego drukuje ich liczbę. Ostatnia część, czyli kolejny sort, powoduje odwrotne uporządkowanie otrzymanej w ten sposób listy, tak aby najczęściej odwiedzane strony znalazły się na jej początku.

Nie jest to może najbardziej efektywna metoda przetwarzania logu, ale jest stosunkowo prosta i każdy może z niej bez problemów skorzystać. Jednakże, aby móc przeprowadzać bardziej wszechstronne analizy logów serwera WWW, należy zaopatrzyć się w jeden z powszechnie dostępnych w sieci programów, służących do przetwarzania danych z logów o formacie standardowym. Najpopularniejsze z nich to Analog, Getstats oraz Wusage (http://www.boutell.com/wusage/). Listę narzędzi, służących do pracy z logami znaleźć można pod adresem:

http://dir.yahoo.com/Computers_and_Internet/Software/Internet/World_Wide_Web/
Servers/Log_Analysis_Tools/.

Wspomniane programy pozwalają na analizę danych z logów i dostarczają na tej podstawie takich informacji, jak wspomniana już liczba odczytów każdej ze stron, pory dnia, kiedy obciążenie jest największe oraz nazwy komputerów, które najczęściej korzystają z danych Twojego serwera. Niektóre z nich potrafią nawet generować bardzo ładne wykresy różnego typu w postaci plików GIF. Większość tych programów jest powszechnie dostępna, tak więc postaraj się je przetestować i wybrać ten, który będzie Ci najbardziej odpowiadał.

Komercyjne serwery WWW wyposażone są z reguły w mechanizmy zapisywania zdarzeń do logów i analizowania ich na bieżąco. Przejrzyj dokumentację serwera i przekonaj się, czy te wbudowane programy będą dla Ciebie wystarczające.

User-agent i odnośniki

Niektóre serwery pozwalają na zapisywanie w logach rozszerzonych informacji na temat odczytu stron z serwera WWW. Mogą to być takie dane, jak typ przeglądarki, z której na­deszło żądanie odczytu lub też dane strony, z której zostało poprowadzone połączenie. Takie informacje zwane są odpowiednio: user-agent oraz odnośnikami (pierwsza nazwa pochodzi od nagłówka protokołu HTTP, który przekazuje serwerowi tę właśnie informac­ję).

Ale dlaczego ktokolwiek miałby być zainteresowany takimi informacjami? No cóż, user-agent mówi Ci, jakie przeglądarki są wykorzystywane do odczytu Twoich stron. Jeżeli zechcesz sprawdzić, ilu spośród Twoich czytelników używa przeglądarki Netscape 4.0 (jeżeli będzie ich dużo, może zechcesz zoptymalizować strony pod kątem tej właśnie przeglądarki), user-agent dostarczy Ci tej informacji (Netscape ukrywa się w tych danych pod nazwą „Mozilla”). Można stąd także odczytać nazwę platformy, na której działa przeglądarka oraz numer jej wersji.

User-agent to określenie danych przeglądarek, które są wykorzystywane do odczytu stron WWW z danego serwera. Dane te zawierają takie informacje, jak nazwa przeglądarki, jej wersja oraz platforma, na której funkcjonuje.

Odnośniki mogą okazać się jeszcze bardziej interesujące. Pod tym pojęciem kryje się stro­na, którą użytkownik oglądał tuż przed odczytaniem strony z Twojego serwera. Oznacza to, w większości przypadków, że w tym właśnie miejscu ktoś umieścił połączenie do jednej z Twoich stron. Możesz się stąd dowiedzieć, kto tworzy takie połączenia i sprawdzić, w ja­kim kontekście są one zamieszczane i czy dostatecznie dobrze reklamują Twoją prezen­tację.

Odnośniki to strony, które zostały odwiedzone przez użytkownika przeglądarki bezpośrednio przed odczytaniem jednej z twoich stron. Z reguły zawierają one połączenia do Twojej prezentacji.

Istnieją oczywiście programy, które generują raporty na podstawie tych informacji, choć równie dobrze można do tego celu wykorzystać ogólny analizator logów.

Własne dokumenty obsługi błędów

Jednym ze sposobów poprawienia przydatności witryny jest tworzenie własnych dokumentów obsługi błędów, które pomogą użytkownikom, gdy coś pójdzie nie tak jak trzeba. Na przykład, spójrz na domyślny dokument generowany przez serwer Apache w przypadku zgłoszenia błędu 404 Not Found. Dokument ten informuje użytkownika, iż nie udało się odnaleźć żądanego dokumentu, jednak oprócz tego, nie dostarcza żadnych użytecznych informacji. Większość serwerów WWW pozwala na określenie dokumentów HTML lub programów CGI, których można użyć zamiast domyślnych dokumentów informujących o błędach. Dzięki temu możliwe jest stworzenie dokumentów obsługi błędów zgodnych z charakterem oraz szatą graficzną całej witryny i dostarczających użytkownikom dodatkowych informacji.

Rysunek 29.8. Domyślny dokument obsługi błędu 404 Not Found serwera Apache

Aby określić własny dokument obsługi błędu (lub skrypt CGI) należy skonfigurować serwer WWW w taki sposób, aby wiedział, jakiego dokumentu należy użyć. Serwery WWW dające możliwość tworzenia własnych dokumentów obsługi błędów, zazwyczaj pozwalają na zdefiniowanie takich dokumentów dla wszystkich istniejących błędów HTTP. Na przykład, można zdefiniować dokument wyświetlany w momencie zgłoszenia błędów 404 informujący, że żądany dokument mógł zostać przeniesiony w inne miejsce, jak również zupełnie inny dokument wyświetlany w momencie zgłoszenia błędu 401 i wyjaśniający powody ograniczenia dostępu do strony.

W przypadku serwera Apache (lub NCSA) alternatywny dokument dla błędu o podanym kodzie, określany jest przy użyciu dyrektywy ErrorDocument. Oto składnia tej dyrektywy:

ErrorDocument kod_błędu /nazwa_pliku.html

A oto przykład praktycznego wykorzystania tej dyrektywy:

ErrorDocument 404 /error_documents/404.html

Jeśli użytkownik zażąda wyświetlenia nieistniejącej strony, w jego przeglądarce pojawi się dokument skojarzony z błędem o numerze 404. Dokument ten może zawierać informacje, które pomogą użytkownikowi w odnalezieniu poszukiwanej strony WWW. Na przykład, spójrz na dokument obsługi błędu 404 wykorzystywany przez witrynę Yahoo!, przedstawiony na rysunku 29.9.

Rysunek 29.9. Strona obsługi błędu 404 na witrynie Yahoo!

Programy CGI jako dokumenty obsługi błędów

Kolejną możliwością jest obsługa błędów przy wykorzystaniu programów CGI. Metoda ta jest szczególnie przydatna w sytuacjach, gdy chcesz wykonać jakieś czynności zależne od otrzymanego żądania. Jeśli korzystasz z serwera Apache (lub NCSA), to skonfigurowanie błędu w taki sposób, aby był on obsługiwany przez skrypt CGI jest wyjątkowo proste i sprowadza się do podania poprawnego adresu URL skryptu CGI w dyrek-tywie ErrorDocument. Oto przykład takiej dyrektywy:

ErrorDocument 404 /cgi-bin/404error.cgi

Jeśli zmieniłeś położenie często odwiedzanych stron WWW i użytkownicy mają problemy z ich odnalezieniem, to możesz stworzyć skrypt CGI obsługujący błąd 404, który będzie wyświetlał komunikat informujący o przeniesieniu strony i automatycznie przekieruje użytkownika pod właściwy adres.

Podsumowanie

Jeżeli masz dostęp do serwera WWW, na którym publikowane są Twoje strony, możesz za pomocą odpowiednich ustawień wprowadzić nowe możliwości, których nie da się osiągnąć, używając samego tylko HTML-a. Mechanizm SSI pozwala umieszczać pewne dodatkowe informacje, które są generowane przez serwer w momencie odczytu strony, stąd też są one zawsze aktualne. Przekierowanie plików umożliwia przenoszenie prezentacji w obrębie serwera bez konieczności modyfikacji już utworzonych połączeń. Istnieje też możliwość samoczynnego przesyłania zaktualizowanych danych do przeglądarki, bez konieczności podejmowania żadnych działań ze strony użytkownika. Z kolei zapisywanie wszystkich działań serwera do specjalnych plików, zwanych logami, pozwala na przeprowadzanie wszechstronnych analiz tego, kto i kiedy korzysta z Twoich prezentacji.

W tym rozdziale nauczyłeś się posługiwać wszystkimi wymienionymi mechanizmami. Ale to nie wszystko. Wspomniałam tu tylko o kilku możliwościach, pozostałych należy poszu­kać w dokumentacji konkretnego serwera, który na pewno potrafi zrobić dla Ciebie o wiele więcej.

Warsztat

W tym podrozdziale przedstawiłam pytania i odpowiedzi oraz quiz z zakresu administracji serwerem WWW.

Pytania i odpowiedzi

P. Utworzyłem plik .shtml, zawierający dwa polecenia SSI uruchamiające skrypty CGI. Obydwa skrypty wymagają przekazania argumentów. Ale, jeżeli dobrze zro­zumiałem, nie mogę przekazać argumentów zapisanych w pliku, lecz muszę przemycić je w URL-u w pliku .shtml. Jak więc mam przekazać w ten sposób argumenty do dwóch skryptów?

O. Jedyne, co przychodzi mi do głowy, to przekazanie wszystkich argumentów w URL-u strony, a następnie takie przygotowanie skryptów, aby umiały rozróżnić, które argumenty przeznaczone są dla którego z nich.

P. Bez problemów uruchamiam polecenia SSI, takie jak #include czy #fsize, ale nie mogę w żaden sposób wykonać polecenia #exec. Jedynym efektem są ciągłe błędy. Dlaczego?

O. Administrator serwera na pewno ze względów bezpieczeństwa zablokował możliwość uruchamiania skryptów SSI. Serwer NCSA HTTPD posiada taką możliwość. Radzę porozmawiać z nim (nią) na ten temat.

P. Nie mogę dostać się do moich logów, bowiem serwer znajduje się na komputerze o ograniczonym dostępie. Czy mogę zdobyć informacje o moich stronach w jakiś inny sposób?

O. Dostęp do logów powinien zapewnić administrator serwera WWW. Nie musi to być dostęp bezpośredni, może za pośrednictwem jakiegoś oprogramowania lub też formu­larza na stronie HTML. Może on również udostępnić Ci program analityczny, który będzie od razu generował odpowiednie raporty. W każdym razie należy rozpocząć od rozmowy z administratorem, bowiem wszystko znajduje się w jego rękach.

P. Prowadzę dość popularny serwis informacyjny, w którym informacje są codziennie aktualizowane. Ostatnio odebrałem kilka skarg od osób korzystających z usług du­żych dostawców usług internetowych, które twierdzą, że próbując odczytywać moje strony nie otrzymują aktualnych informacji. Dlaczego tak się dzieje?

O. Większość tego typu użytkowników korzysta mniej lub bardziej świadomie z serwerów buforujących, które, jak już wcześniej wspomniałem, przechowują lokalne kopie naj­częściej odczytywanych stron, tak aby szybciej mogły być przesyłane do przeglądarek. Przy założeniu, że większość z nich połączona jest z siecią za pomocą raczej wolnych modemów i droga, którą musi przebyć strona od serwera do przeglądarki jest dość długa, buforowa­nie wydaje się być całkiem dobrym pomysłem, bowiem wydatnie skraca czas ładowania pliku.

Serwery buforujące powinny z każdym żądaniem pobrania określonej strony sprawdzać, czy nie została ona zaktualizowana na serwerze macierzystym (jeżeli nie, serwer buforujący prześle lokalną kopię, jeżeli tak, powinien pobrać nową wersję). Jednakże niewiele serwerów rzetelnie wypełnia ten obowiązek, w związku z czym bardzo często ich użytkownicy oglądają nieaktualne strony.

Jedynym rozwiązaniem jest częste wykorzystywanie przycisku „Odśwież” przez użyt­kowników, w ten sposób zawsze można uzyskać aktualną wersję pliku bezpośrednio z właściwego serwera (pomijany jest bufor serwera). Powinieneś umieścić na stronie krótką notkę na ten temat.

Quiz

1. Czym jest mechanizm SSI?

2. Wymień przynajmniej dwie czynności, jakie można wykonać przy wykorzystaniu SSI.

3. W jaki sposób przekierowywanie żądań na serwerze może pomóc w obsłudze plików przeniesionych w inne miejsce?

4. Jaka nazwa zostanie zapisana w pliku dziennika rejestrującego programy zgłaszające żądania, jeśli używaną przeglądarką będzie Netscape Navigator?

Odpowiedzi

1. SSI to narzędzie, w jakie mogą być wyposażone serwery WWW. Pozwala ono na tworzenie plików przetwarzanych przez serwer i zawierających specjalne polecenia. W momencie otrzymania żądania serwer wykonuje te polecenia i umieszcza ich wyniki w pliku HTML.

2. Mechanizm SSI pozwala na: 1) wstawianie zawartości plików do innych plików, pozwala to na dołączanie, na przykład, podpisów lub informacji o prawach autorskich; 2) umieszczanie w dokumentach HTML aktualnej daty i czasu; 3) prezentację informacji o pliku, takich jak jego wielkość lub data ostatniej modyfikacji; 4) wyświetlanie w dokumencie HTML wyników wykonania skryptu CGI.

3. Dzięki przekierowaniom można stworzyć w pliku konfiguracyjnym serwera specjalną regułę, informującą serwer o konieczności przekierowania przeglądarki pod inny adres, w przypadku otrzymania żądania przesłania konkretnego pliku.

4. Przeglądarka Netscape Navigator jest określana w plikach dzienników serwera WWW jako „Mozilla”.

Ćwiczenia

1. Przyjrzyj się licznikom odwiedzić dostępnym na witrynie Yahoo pod adresem: http://dir.yahoo.com/Computers_and_Internet/Internet/World_Wide_Web/Programming/Access_Counters/. Skopiuj kilka z nich, porównaj ich możliwości i sprawdź, czy byłbyś w stanie użyć któregoś z nich na własnej witrynie WWW.

2. Sprawdź plik dziennika rejestrujący używane oprogramowanie i określ, jakiej przeglądarki najczęściej używają osoby odwiedzające Twoją witrynę WWW. Czy jest to przeglądarka Internet Explorer czy też Netscape Navigator? A może jeszcze inna przeglądarka? Jaka jest najczęściej używana wersja przeglądarki? Czy użytkownicy przeważnie korzystają już z wersji 4.x przeglądarek, a może z jeszcze nowszych? Czy jesteś w stanie określić, jakiej platformy systemowej używa większość osób odwiedzających Twoją witrynę, czy jest to Windows, Mac czy też Unix? Odpowiedzi na te pytania powinny mieć znaczący wpływ na projekt stron WWW, technologie, z jakich będziesz korzystać na witrynie oraz typ prezentowanej zawartości.

826 Część 10. Konfiguracja i administracja serwera WWW

Rozdział 29. Porady i wskazówki na temat serwera WWW 825

---