Rozdział 18.

Skrypty CGI dla początkujących

CGI jest skrótem angielskiego określenia Common Gateway Interface, które jest interfej­sem umożliwiającym uruchamianie programów na serwerze WWW, w odpowiedzi na dane po­chodzące z przeglądarki. Skrypty CGI pozwalają odwiedzającemu na interakcję z Two­imi stronami WWW — wyszukiwanie rekordów w bazach danych, komentowanie wprowa­dzone­go tekstu, wybieranie kilku elementów na stronie w celu otrzymania szczegółowej od­powie­dzi. Niegdyś skrypty CGI były sporadycznie wykorzystywane. WWW była wtedy przeważnie używana do prezentowania statycznych informacji umieszczanych w standardowych dokumentach HTML. Aktualnie skrypty CGI bądź inne technologie tworzenia aplikacji WWW są wykorzystywane niemal we wszystkich aspektach projektowania witryny. Wiele witryn prezentuje zawartość dostosowaną do zainteresowań użytkowników, a umieszczone na nich informacje są przechowywane w bazach danych, a nie w statycznych plikach. Aplikacje WWW stały się także coraz szerzej rozpowszechnione. Za pośrednictwem WWW można czytać listy poczty elektronicznej, sprawdzać harmonogram zajęć i kalendarz, sprawdzać stan portfela akcji. Wszystkie te aplikacje zostały stworzone przy wykorzystaniu programów CGI bądź technologii stanowiących rozwinięcie CGI.

W tym rozdziale nauczysz się prawie wszystkiego na temat skryptów CGI, w tym:

• co to jest skrypt CGI i jak działa,

• jak wygląda rezultat działania skryptu,

• jak pisać skrypty CGI z parametrami i bez,

• jak pisać skrypty zwracające specjalne odpowiedzi,

• jak pisać skrypty przetwarzające dane z formularzy,

• o najważniejszych problemach związanych ze skryptami CGI,

• o zmiennych CGI, których można użyć w skryptach,

• o skryptach działających bez przetwarzania nagłówków (non-parsed headers),

• o przeszukiwaniu z użyciem <ISINDEX>.

	Rozdział ten koncentruje się głównie na serwerach WWW działających na systemach UNIX, a większość przykładów i instrukcji będzie dotyczyć jedynie tego systemu. Jeśli korzystasz z innego systemu operacyjnego, niektóre informacje, zawarte w części dotyczącej pisania skryptów CGI, mogą go nie dotyczyć. Ten rozdział pozwoli Ci przynajmniej poznać ideę działania CGI, a informacje w nim zawarte będziesz mógł wykorzystać wraz z dokumentacją CGI dla używanego serwera WWW.

Co to jest skrypt CGI?

Skrypt CGI jest to, najprościej mówiąc, program, który działa na serwerze WWW, uru­chamiany poprzez dane pochodzące z przeglądarki. Skrypt jest zazwyczaj łącznikiem pomiędzy serwerem WWW i innymi programami działającymi w systemie, na przykład, bazami danych.

Skrypty CGI właściwie nie muszą być skryptami. W zależności od możliwości naszego serwera mogą to być skompilowane programy, pliki wsadowe lub inne pliki wykonywalne. Dla uproszczenia terminologii będziemy je w tym rozdziale nazywać skryptami.

Skrypt CGI to dowolny program wykonywany na serwerze WWW. CGI to akronim słów Common Gateway Interface. Jest to standaryzowany interfejs wymiany informacji pomiędzy serwerem WWW a programami zewnętrznymi.

Skrypty CGI są zazwyczaj wywoływane na dwa sposoby: bezpośrednio (za pomocą połączenia) oraz jako atrybut ACTION formularzy. Skrypt do przetwarzania formularzy używany jest nieco inaczej niż zwykły skrypt CGI, ale oba wyglądają i działają podobnie. W pierwszej części tego rozdziału poznasz ich ogólne właściwości, a później zajmiemy się skryptami przetwarzającymi formularze.

Jak działają skrypty?

Skrypty CGI są wywoływane przez serwer na podstawie informacji z przeglądarki. Rys. 18.1 pokazuje sposób, w jaki informacja jest przetwarzana pomiędzy przeglądarką, ser­werem i skryptem.

Rysunek 18.1 Przeglądarka, serwer, skrypt

Poniżej znajduje się skrócony opis tego, co się dzieje.

1. URL wskazuje na skrypt CGI. Taki URL może pojawić się wszędzie tam, gdzie można użyć zwykłego URL-a, na przykład, w odnośniku lub obrazku. Zazwyczaj wykorzys­tywany jest w polu ACTION formularza. Przeglądarka kontaktuje się z serwerem za pomocą tego URL-a.

2. Serwer odbiera zlecenie, zauważa, że URL wskazuje na skrypt (na podstawie lokalizacji pliku lub jego rozszerzenia, w zależności od serwera) i wykonuje go.

3. Skrypt wykonuje pewne działania w oparciu o dane z przeglądarki, jeśli takowe wystą­piły. Może to być wyszukanie rekordów w bazie danych, obliczenie war­tości lub po prostu wywołanie innego programu w systemie.

4. Skrypt generuje pewną odpowiedź, którą serwer WWW jest w stanie zrozumieć.

5. Serwer WWW odbiera odpowiedź od skryptu i odsyła ją do przeglądarki, która forma­tuje dane i wyświetla je.

Proste? Nie? Nie martw się, cały ten proces może wydawać się nieco złożony. Czytaj da­lej. Dzięki kilku przykładom będzie go łatwiej zrozumieć.

Prosty przykład

Poniżej znajduje się prosty przykład, objaśniający krok po kroku, co się dzieje po obu stro­nach całego procesu. W przeglądarce możemy napotkać stronę, która wygląda podobnie do przedstawionej na rys. 18.2.

Rysunek 18.2 Strona z odnośnikiem do skryptu

Odnośnik Wyświetl datę jest odnośnikiem do skryptu CGI. Jest zawarty wewnątrz kodu HTML strony, tak jak dowolny inny odnośnik. Jeśli przyjrzymy się źródłu strony, możemy tam znaleźć następujący kod:

<A href="http://www.serwer.com/cgi-bin/getdate">Wyświetl datę</a>

Fakt, że cgi-bin pojawia się w ścieżce jest ważną podpowiedzią, że patrzymy na skrypt CGI. W przypadku wielu serwerów, cgi-bin jest jedynym miejscem, gdzie mogą być prze­chowy­wane skrypty CGI.

Kiedy wybierzesz odnośnik, przeglądarka odwołuje się do URL-a z serwera www.jserwer.com. Serwer odbiera zlecenie i wnioskuje na podstawie swojej konfigu­racji, że URL odnosi się do skryptu o nazwie getdate. Następnie serwer wykonuje skrypt.

Skrypt getdate w tym przypadku jest prostym skryptem powłoki UNIX-owej wyglądają­cym następująco:

#!/bin/sh

echo Content-type: text/plain

echo

/bin/date

Skrypt ten ma dwojakie działanie. Najpierw wyświetla nagłówek Content-type: text/plain, a za nim pustą linię. Następnie wywołuje standardowy program UNIX-owy date, który wyświetla datę i czas. Rezultat działania skryptu wygląda więc następująco:

Content-type: text/plain

Tue May 25 16:15:57 EDT 1997

Co oznacza ten zapis Content-type? Jest to specjalny kod, który serwer WWW przesyła do przeglądarki, aby powiedzieć jej, z jakiego typu dokumentem ma do czynienia. Przeglądarka następnie używa go do określenia, czy potrafi wyświetlić dokument takiego typu i czy nale­ży wykonać w tym celu dodatkowy, zewnętrzny program. W dalszej części tego rozdziału poznamy specyfikę tej linii.

Po zakończeniu wykonywania skryptu, serwer odbiera rezultat i przesyła go z powrotem do przeglądarki poprzez sieć. Przeglądarka dotychczas czekała cierpliwie na odpowiedź. Kiedy otrzymuje dane z serwera, po prostu je wyświetla, tak jak to pokazano na rys. 18.3.

Rysunek 18.3 Rezultat działania skryptu wyświetlającego datę

Tak wygląda cała idea. Mimo że proces może być dużo bardziej złożony, taka interakcja pomiędzy przeglądarką, serwerem i skryptem jest główną zasadą działania CGI.

Czy mogę używać skryptów CGI?

Nim użyjesz skryptów CGI na swojej witrynie, będziesz musiał sprawdzić, czy dysponujesz uprawnieniami pozwalającymi instalować skrypty na serwerze WWW. Jeśli prowadzisz własny serwer, to zazwyczaj nie będzie to stanowiło żadnego problemu. W takim przypadku możesz robić dosłownie wszystko, czyli także instalować i wykonywać skrypty CGI. Jeśli jednak Twoja witryna znajduje się na serwerze prowadzonym przez dostawcę usług internetowych, to będziesz musiał sprawdzić, czy dysponujesz prawami do instalowania skryptów.

Przed przystąpieniem do lektury dalszej części rozdziału upewnij się, że jesteś w stanie odpowiedzieć na poniższe pytania.

Czy Twój serwer jest skonfigurowany w sposób pozwalający na wykonanie skryptów CGI?

Aby pisać i uruchamiać skrypty CGI, potrzebny jest serwer WWW. W odróżnieniu od zwykłych plików HTML, skryptów CGI nie można pisać i testować na własnym kompute­rze, potrzebny jest do tego serwer WWW. Na szczęście serwery WWW są dostępne niemal dla wszystkich istniejących platform komputerowych, a zatem zazwyczaj będziesz w stanie skonfigurować swój system w taki sposób, iż będziesz w stanie testować skrypty CGI bez konieczności umieszczania ich na produkcyjnym serwerze WWW.

Jednak, jeśli nawet masz serwer WWW, musi on być specjalnie skonfigurowany, aby pozwalał na wykonanie skryptów CGI. Oznacza to zazwyczaj, że wszystkie skrypty są przechowywane w spec­jalnym katalogu o nazwie cgi-bin. To zwyczajny katalog, który zgodnie z informacjami konfiguracyjnymi serwera służy do przechowywania skryptów CGI. Jeśli tylko dysponujesz dostępem do pliku konfiguracyjnego serwera WWW, to możesz sam wybrać katalog, który będzie pełnił funkcję katalogu CGI.

Zanim zaczniesz wypróbowywać jakiekolwiek skrypty, zapytaj swojego administratora, czy możesz je instalować i uruchamiać, a jeśli tak, to gdzie należy je umieszczać.

Jeśli korzystasz z własnego serwera, musisz utworzyć odpowiedni katalog cgi-bin i skonfi­gu­rować serwer, tak aby rozpoznawał go jako katalog ze skryptami (należący do konfiguracji serwera, która oczywiście zależna jest od typu serwera). Musisz również pamiętać o nastę­pujących zagadnieniach, które wiążą się z zastosowaniem skryptów CGI.

• Każdy skrypt CGI jest programem i zostaje uruchomiony, kiedy przeglądarka tego zażąda, zużywając podczas wykonania czas procesora i pamięć. Co się stanie z systemem, jeśli dziesiątki lub setki takich skryptów zostaną jednocześnie uruchomione? System może nie wytrzymać takiego obciążenia i zawiesić się lub uczynić dalszą pracę niemożliwą.

• Jeśli nie będziesz wystarczająco ostrożny przy pisaniu własnych skryptów, możesz przypadkowo otworzyć dostęp do systemu poprzez wykorzystanie parametrów, których skrypt nie oczekiwał; ktoś się do niego włamie lub go uszkodzi.

Czy umiesz programować?

Uwaga początkujący! Do pisania skryptów CGI będzie wam potrzebna umiejętność programowania. Jeśli nie macie takich podstaw, doradzam zwrócenie się o pomoc do kogoś, kto je ma, przeczytanie książki na temat podstaw programowania lub odpowiedni kurs. Ta książka jest zbyt krótka na to, żeby wyjaśnić zarówno podstawy programowania, jak i programowanie CGI jednocześnie. Szczególnie w tym rozdziale zakładam, że czytelnik umie odczytać i zrozumieć przykładowe fragmenty kodu.

Nawet jeśli nie potrafisz programować, to nie jest to powód do rozpaczy. Dostępnych jest wiele witryn WWW, na których można znaleźć skrypty napisane przez inne osoby. Skrypty te można skopiować i zaadoptować do wykorzystania na własnej witrynie. Do uruchomienia skryptów CGI na serwerze WWW będziesz potrzebował choćby minimalnej znajomości zasad ich działania, niemniej jednak wykorzystanie skryptów napisanych przez inne osoby jest nieporównanie prostsze do tworzenia ich samemu.

Jakich języków programowania należy używać?

Do pisania programów CGI możesz użyć dowolnego języka programowania, który znasz, pod warunkiem, że skrypty będą pisane zgodnie z regułami objaśnionymi w dalszej części i programy w tym języku dają się uruchamiać na tym samym komputerze, na którym działa serwer WWW.

W tym rozdziale oraz w dalszej części tej książki, będę wykorzystywała dwa języki progra­mowania: powłokę Bourne systemu UNIX oraz język Perl. Powłoka Bourne jest dostępna praktycznie na każdym systemie UNIX-owym i łatwo ją opanować, ale trudniej zastosować do bardziej złożonych zadań. Perl natomiast jest dostępny za darmo. Język ten jest osiągalny w wersjach dla maszyn UNIX-owych oraz dla systemów Windows i Macintosh. Jest bardzo elastyczny i wydajny, ale jest również bardzo trudny do opano­wania. Na szczęście Perl jest językiem skryptowym i wystarczy poznać jego podstawy, aby rozpocząć tworzenie własnych skryptów CGI. Naucz się tylko tego, co jest Ci niezbędnie konieczne do osiągnięcia zamierzonych celów, a całą resztę pomiń.

Czy Twój serwer jest skonfigurowany prawidłowo?

W celu umożliwienia wykonywania skryptów CGI, bez względu na to czy są to proste, czy też bardziej złożone skrypty do przetwarzania formularzy, serwer musi być do ich urucho­mienia odpowiednio skonfigurowany. Możliwe, że będziesz musiał je trzymać w odpowied­nim katalogu lub używać specjalnego rozszerzania. Zależy to od typu serwera i jego konfi­guracji.

Jeśli dzierżawisz miejsce na cudzym serwerze WWW lub administruje nim ktoś inny, musisz uzgodnić, czy skrypty CGI można tam wykorzystywać, a jeśli tak, gdzie nale­ży je umieszczać.

Jeśli korzystasz z własnego serwera, sprawdź w jego dokumentacji, w jaki sposób obsługuje skrypty CGI.

A jeśli nie korzystasz z systemu UNIX?

Jeśli nie korzystasz z systemu Unix, mimo wszystko, czytaj dalej. Swego czasu programy CGI były wykorzystywane niemal wyłącznie w systemach UNIX. Teraz jednak skrypty CGI można także pisać i wykonywać na serwerach WWW działających w systemach Windows a nawet Macintosh.

Najpopularniejszym serwerem WWW, działającym w systemie Windows NT, jest Internet Information Server. Jest on dostarczany wraz z systemem Windows NT Server i dostępny bezpłatnie. Na szczęście produkt ten obsługuje interfejs CGI. Także Microsoft Personal Web Serwer, produkt używany zazwyczaj do lokalnego testowania witryn, umożliwia obsługę skryptów CGI. Także serwer WWW firmy Netscape, działający w systemie Windows NT, został wyposażony w pełną obsługę interfejsu CGI.

Server MacHTTP dysponuje możliwościami obsługi skryptów CGI pisanych w języku AppleScript. (MacHTTP to oryginalna, shareware-owa wersja komercyjnego serwera WWW firmy StarNine o nazwie WebStar.) Jon Wiederspan napisał doskonały podręcznik na temat pisania skryptów CGI w języku AppleScript, został on dołączony do dokumentacji serwera MacHTTP.

Lokalne testowanie skryptów CGI

Jednym z problemów, który wielu programistów CGI napotyka podczas nauki pisania skryptów, jest brak możliwości testowania skryptów poza produkcyjnym serwerem WWW. Zdarza się również, iż osoby pragnące nauczyć się programowania CGI nie dysponują sposobami tworzenia skryptów. W tej części rozdziału opiszę pokrótce, w jaki sposób użytkownicy systemu Windows, pragnący pisać skrypty CGI w języku Perl, mogą szybko stworzyć wymagane środowisko programistyczne na swoich lokalnych komputerach.

Aby pisać skrypty CGI w języku Perl, konieczne są dwa elementy: serwer WWW oraz interpreter języka Perl. Polecam wykorzystanie serwera WWW Apache for Windows oraz wersji języka Perl przeznaczonej dla systemu Windows, Perl for Windows. Serwer Apache można znaleźć na WWW pod adresem http://www.apache.org/. Odszukanie połączeń umożliwiających skopiowanie najnowszej wersji serwera Apache for Windows nie powinno stanowić żadnego problemu. Instalacja programu jest bardzo prosta; warto jednak zapamiętać jedno ostrzeżenie, iż nie należy instalować serwera w folderze, którego nazwa zawiera odstęp. Innymi słowy, zamiast instalowania serwera w folderze C:\Program Files\Apache, lepiej zainstalować go w folderze C:\Apache, w przyszłości może Ci to znacznie ułatwić życie.

Po zainstalowaniu serwera można go uruchomić, dwukrotnie klikając jego ikonę umieszczoną na pulpicie lub wykonując program apache.exe w oknie trybut MS-DOS. Można także zainstalować serwer w formie serwisu, dzięki czemu będzie mógł on działać nieprzerwanie. Po uruchomieniu, można bardzo prosto sprawdzić czy działa poprawnie — wystarczy zażądać wyświetlenia strony o następującym adresie URL:

http://localhost/

Po upewnieniu się, że serwer Apache działa poprawnie, powinieneś zdobyć kopię języka Perl. Można ją znaleźć na witrynie http://www.perl.com. Po skopiowaniu wymaganych plików, należy zainstalować język przy użyciu dostarczonego programu instalacyjnego. Także tym razem radziłabym instalowanie Perl-a w folderze, którego nazwa nie zawiera odstępów. Gdy proces instalacji dobiegnie końca, będziesz mógł rozpocząć pisanie skryptów CGI.

Skrypty CGI należy umieszczać w folderze cgi-bin, wewnątrz katalogu, w którym został zainstalowany serwer Apache. Aby skrypty te mogły działać, powinieneś poinformować serwer, gdzie się znajduje interpreter języka Perl. W tym celu, w pierwszej linii skryptu, należy podać położenie programu będącego interpreterem Perl-a. Zakładając, że pełna ścieżka dostępu do interpretera języka Perl to C:\perl\bin\perl.exe, w pierwszej linii skryptu powinieneś umieścić poniższy kod:

#!C:\perl\bin\perl.exe

Od tej chwili jesteś już gotów do tworzenia i testowania skryptów CGI w systemie Windows.

Anatomia skryptu CGI

Gdy już upewnisz się, że będziesz w stanie pisać skrypty CGI i umieszczać je na serwerze WWW, możesz zacząć dokładniej poznawać zasady ich tworzenia. Wszystkie skrypty CGI są wywoływane w taki sam sposób i muszą zwracać wyniki w ściśle określonej postaci, dlatego też mają pewne wspólne cechy. W tej części rozdziału przedstawię wspólny szkielet wykorzystywany we wszystkich skryptach CGI.

Nagłówki odpowiedzi

Sposób działania skryptów CGI wyjaśnię w odwrotnej kolejności. Pierwszą rzeczą, jaką omówię będą nagłówki odpowiedzi, czyli ostatnia rzecz, o jaką powinieneś zadbać, tworząc skrypty CGI. Po wykonaniu skryptu CGI, wyniki jego wykonania zostają przekazane do przeglądarki. Ogólnie rzecz biorąc, wyniki skryptu zazwyczaj będą miały postać kodu HTML. Skrypty mogą jednak generować dowolne wyniki, które przeglądarki są w stanie zinterpretować. Zanim skrypt zacznie generować faktyczne dane wyjściowe, należy jednak przekazać serwerowi WWW informacje dotyczące typu generowanych informacji.

	Mówiąc o odpowiedzi skryptu, mam na myśli dane, które skrypt odsyła do serwera. W przypadku UNIX-a, dane są wysyłane na standardowe wyj­ście programu i z tego miejsca serwer je odbiera. W przypadku innych syste­mów odpowiedź skryptu może się znajdować gdzie indziej i serwer musi ją stamtąd pobrać. Może to być plik dyskowy lub dane mogą zostać przekazane bezpośrednio do innego pro­gramu. Aby dokładniej dowiedzieć się, w jaki sposób skrypty CGI są zaimplemen­towane na Twoim serwerze, powinie­neś sprawdzić dokumentację swojego serwe­ra.

Pierwszą rzeczą, jaką skrypt powinien zwrócić w odpowiedzi, jest specjalny nagłówek, okreś­lający, jakiego typu informacja znajduje się w dalszej części. Nagłówek nie jest, w zasadzie, częścią dokumentu i nie jest nigdzie wyświetlany. Należy on do informacji przesyłanych przez serwer WWW do przeglądarki i umożliwia jej określenie rodzaju danych, jakie zostaną przekazane. Zawsze podczas przesyłania żądań i odpowiedzi HTTP, nagłówki wykorzystywane są do przesyłania informacji pomiędzy serwerem i przeglądarką. Na przykład, gdy przeglądarka zgłasza żądanie to wraz z nim zazwyczaj przesyła informacje dotyczące typu zawartości, jakie akceptuje, adresu IP komputera zgłaszającego żądanie oraz używanej przeglądarki.

Za każdym razem, gdy serwer przesyła odpowiedź do przeglądarki, umieszczane są w niej, między innymi, nagłówki określające typ przesyłanych informacji. Gdy żądanie dotyczy obrazu GIF lub dokumentu HTML, serwer określa typ zawartości na podstawie rozszerzenia pliku. Jednak serwer nie ma żadnego sposobu, aby określić typ wyników, jakie zostaną wygenerowane przez skrypt CGI, a zatem to właśnie skrypt musi wygenerować nagłówek Content-type i przekazać go serwerowi, który z kolei prześle go do przeglądarki. Nagłówek ten składa się ze słów Content-type, specjalnego kodu, określającego typ przesyłanego pliku oraz znaku nowej linii:

Content-type: text/html

Każdemu typowi pliku lub zasobu odpowiada unikalny typ zawartości. To nie przypadek, że typy zawartości żądań HTTP są takie same, jak typy MIME używane przy przesyłaniu poczty elektronicznej z załącznikami MIME. W tabeli 18.1 przedstawione zostały te najczęściej używane w żądaniach HTTP.

Tabela 18.1: Powszechnie stosowane formaty plików i odpowiednie wartości content-type

Format	Wartość Content-type
HTML	text/html
tekst	text/plain
GIF	image/gif
JPEG	image/jpeg
Postscript	application/postscript
MPEG	video/mpeg

Zwróć uwagę, iż po wierszu zawierającym określenie typu zawartości musi się pojawić pusty wiersz. Oznacza on, że nie będą już przesyłane żadne inne nagłówki, a wszystkie dalsze informacje stanowią treść żądania.

Dane zwracane w odpowiedzi

Gdy już określisz typ zawartości przesyłanych informacji, będziesz mógł rozpocząć przesyłanie właściwej treści odpowiedzi. Oczywiście powinna ona odpowiadać nagłówkowi content-type, który wysłaliśmy do serwera. To znaczy, że jeśli użyliśmy nagłówka zawierającego typ text/html, reszta danych powinna zawierać kod HTML. Jeśli użyjemy typu image/gif, wtedy reszta zwracanych danych powinna zawierać binarny plik GIF. Podobnie w przypadku innych typów.

Ćwiczenie 18.1: Spróbuj


To ćwiczenie jest podobne do prostego przykładu, który służył nam do wyświetlania daty z wcześniejszej części tego rozdziału. Poniższy skrypt CGI sprawdza, czy Aki korzysta z serwera i zwraca odpowiednią odpowiedź, która pokazana jest na rys. 18.4.

Rysunek 18.4 Rezultat działania skryptu pingaki

Ten przykład jest najprostszą formą skryptu CGI, który wywoływany jest ze strony WWW poprzez odnośnik taki, jak ten:

<A HREF="http://helion.pl/cgi-bin/books/html4/pingaki.cgi">Czy Aki pracuje w systemie?</A>

Kiedy wybierzemy odnośnik prowadzący do skryptu CGI, skrypt zostanie uruchomiony. Skrypt nie otrzymuje żadnych parametrów, po prostu uruchamia się i zwraca odpowiednie dane.

Najpierw określmy, jakiego typu dane będziemy generować. Ponieważ będzie to dokument HTML, content-type będzie mieć wartość text/html. Tak więc pierwsza część skryptu, która następuje poniżej, wyświetla po prostu linię zawierającą nagłówek a następnie pustą linię (nie wolno zapomnieć o pustej linii!):

#!/bin/sh

echo Content-type: text/html

echo

Teraz dodajemy dalszą część skryptu, treść dokumentu HTML, którą musimy przygotować samodzielnie z wnętrza skryptu. Będziemy musieli w niej wykonać następujące czynności:

• wyświetlić znaczniki, tworzące pierwszą część dokumentu HTML,

• sprawdzić, czy użytkownik Aki akurat korzysta z systemu i wyświetlić wiadomość,

• wyświetlić resztę znaczników HTML kończących dokument.

Zacznijmy od pierwszych linii kodu HTML. Generujemy je za pomocą następujących po­leceń, wykorzystujących powłokę systemu UNIX:

echo "<HTML><HEAD>"

echo "<TITLE>Co robi Aki?</TITLE>"

echo "</HEAD><BODY>"

Teraz sprawdźmy, czy Aki pracuje akurat w systemie. Wykorzystamy do tego polecenie who i zapamiętamy rezultat w zmiennej ison. Jeśli akurat korzysta z systemu, zmienna ta będzie miała jakąś wartość. W przeciwnym razie będzie pusta.

ison=`who | grep aki`

Teraz sprawdźmy rezultat i zwróćmy odpowiednią informację jako część odpowiedzi gene­rowanej przez skrypt.

if [ ! -z "$ison" ]; then

echo "<P>Aki pracuje w systemie.</P>"

else

echo "<P>Aki chwilowo nie pracuje w systemie.</P>"

fi

Wreszcie zamykamy stronę HTML:

echo "</BODY></HTML>"

I to wszystko. Jeśli uruchomimy ten program w celu przetestowania z linii poleceń, otrzy­mamy następujący rezultat:

Content-type: text/html

<HTML><HEAD>

<TITLE>Co robi Aki?</TITLE>

</HEAD><BODY>

<P>Aki chwilowo nie pracuje w systemie.</P>

</BODY></HTML>

Wygląda jak zwykły dokument HTML, prawda? I o to właśnie chodzi. Odpowiedź genero­wana przez skrypt jest odsyłana do serwera a później do przeglądarki. Tak więc powinna mieć postać, którą serwer i przeglądarka będą w stanie zrozumieć, w tym przypadku, plik HTML.

Teraz trzeba zainstalować skrypt w odpowiednim miejscu na serwerze. Ten krok jest zależ­ny od typu serwera, którego używamy. W większości przypadków, na serwerach UNIX-owych można znaleźć specjalny katalog cgi-bin przeznaczony na skrypty. Należy tam skopiować skrypt i upewnić się, że ma ustawione prawa do wykonania.

	Jeśli nie masz dostępu do katalogu cgi-bin, poproś swojego administratora serwe­ra WWW o udostępnienie go. Nie możesz po prostu założyć sobie katalogu o takiej nazwie i skopiować tam skrypty — to nie będzie działać.

Teraz, kiedy masz już gotowy do uruchomienia skrypt, możesz wywołać go z wnętrza stro­ny WWW poprzez użycie odnośnika, jak opisaliśmy to wcześniej. W całości skrypt będzie wyglądał następująco:

#!/bin/sh

echo Content-type: text/html

echo

echo "<HTML><HEAD>"

echo "<TITLE>Co robi Aki?</TITLE>"

echo "</HEAD><BODY>"

ison=`who | grep aki`

if [ ! -z "$ison" ]; then

echo "<P>Aki pracuje w systemie.</P>"

else

echo "<P>Aki chwilowo nie pracuje w systemie.</P>"

fi




echo "</BODY></HTML>"

Skrypty z parametrami

Skrypty CGI są najbardziej użyteczne, jeśli napiszemy je tak, żeby były możliwie uogól­nio­ne, na przykład, jeśli chcesz sprawdzić, czy różne osoby korzystają z systemu, za pomo­cą skryptu z poprzedniego przykładu mógłbyś napisać kilka różnych skryptów (pingaki, pingkrzys, pingewa, itd.). Jednak bardziej sensownie jest napisać jeden skrypt i przesyłać do niego identyfikator poszukiwanej osoby jako parametr.

Aby przekazać do skryptu argumenty, wyszczególniamy je w URL-u, oddzielając znakiem zapytania (?) od nazwy skryptu. Do rozdzielania poszczególnych argumentów wykorzystu­jemy znak plus (+). Na przykład:

<A HREF="/cgi-bin/mojskrypt?arg1+arg2+arg3">Uruchom mój skrypt</A>

Kiedy serwer otrzyma zlecenie dostępu do skryptu, prześle do niego argumenty arg1, arg2, arg3. Następnie można je wykorzystać wewnątrz skryptu.

Taka metoda przesyłania argumentów nazywana jest czasem zapytaniem, ponieważ w taki sposób przeglądarki korzystały kiedyś z informacji przeszukiwanych za pomocą pewnych kluczy, kiedy używano do tego celu znacznika ISINDEX. (Więcej na ten temat napiszemy w dalszej części tego rozdziału.) Obecnie większość przeszukiwań wykonuje się za po­mocą formularzy, jednak poprzedni sposób kodowania argumentów jest wciąż używany. Jeśli często korzystasz ze skryptów CGI, powinieneś go już znać.

Ćwiczenie 18.2: Sprawdźmy, czy wskazana osoba korzysta akurat z systemu


Teraz, kiedy wiemy już, jak przekazywać parametry do skryptu, możemy zmodyfikować skrypt pingaki, aby uogólnić jego działanie. Tak zmieniony skrypt nazwiemy pinggen.

Zacznijmy podobnie jak w przypadku skryptu z poprzedniego przykładu, z nieznacznie zmienionym tytułem:

#!/bin/sh

echo Content-type: text/html

echo

echo "<HTML><HEAD>"

echo "<TITLE>Co robisz?</TITLE>"

echo "</HEAD><BODY>"

W poprzednim przykładzie następnym krokiem było sprawdzenie, czy Aki akurat korzysta z systemu. To jest miejsce, gdzie możemy spróbować uogólnić działanie skryptu. Zamiast korzystać z identyfikatora wpisanego „na sztywno” w treści programu, użyjemy zmiennej ${1}. ${1} oznacza pierwszy argument przekazany do skryptu, ${2} drugi, ${3} trzeci itd.

ison=`who | grep "${1}"`

	Po co stosujemy dodatkowe cudzysłowy wokół zmiennej ${1}? Dzięki nim zapobiegamy przesyłaniu niewłaściwych argumentów do skryptu. Więcej na ten temat znajduje się w rozdziale 30 „Bezpieczeństwo serwera WWW i kontrola dostępu”.

Wszystko, co zostało jeszcze do zrobienia, to modyfikacja reszty skryptu, aby używał prze­słanego argumentu, zamiast na stałe wpisanego identyfikatora:

if [ ! -z "$ison" ]; then

echo "<P>$1 pracuje w systemie.</P>"

else

echo "<P>$1 chwilowo nie pracuje w systemie.</P>"

fi

Następnie kończymy dokument, zamykając otwarty znacznik <HTML>:

echo "</BODY></HTML>"

Po zakończeniu pisania skryptu, możesz zmodyfikować stronę HTML, która z niego ko­rzysta. Skrypt pingaki był wywoływany za pomocą następującego odnośnika:

<A HREF="http://helion.pl/cgi-bin/books/html4/pingaki.cgi">Czy Aki pracuje w systemie?</A>

W wersji uogólnionej wywołanie jest bardzo podobne, ale zawiera dodatkowy argument do­łączony na końcu URL-a. (W tym przypadku sprawdzamy, czy z serwera korzysta użytkow­nik o identyfikatorze Jan.)

<A HREF=" http://helion.pl/cgi-bin/books/html4/pinggene.cgi?jan">Czy Jan pracuje w systemie?</A>


Wypróbuj ten skrypt na własnym serwerze WWW, z własnym identyfikatorem i URLem do skryptu, i sprawdź rezultat .

Przesyłanie innych informacji do skryptu

Oprócz przesyłania argumentów w sposób opisany powyżej, można również skorzystać z innej metody (to jeszcze nie są formularze). Drugi sposób, nazywany przesyłaniem infor­macji o ścieżce, jest używany do przekazywania informacji, które nie zmieniają się pomię­dzy kolejnymi wywołaniami skryptu, jak, na przykład, nazwa pliku tymczasowego lub nazwa pliku, który odwołał się do skryptu. Jak przekonasz się w dalszej części poświęconej formu­larzom, parametry po znaku zapytania mogą się zmieniać w zależności od danych wprowa­dzonych przez użytkownika. Informacja o ścieżce służy do przesyłania innych parametrów (i w gruncie rzeczy mogą to być dowolne informacje).

Informacja o ścieżce pozwala na przesyłanie dodatkowych informacji do skryptu CGI, które nie zmieniają się tak często, jak zwykłe parametry. Informacja o ścieżce często odnosi się do plików umieszczonych w obszarze ser­wera WWW, takich jak pliki konfiguracyjne, pliki tymczasowe lub pliki, z których nastąpiło odwołanie do skryptu.

Aby wykorzystać informację o ścieżce, należy ją dołączyć na końcu URL-a po nazwie skryptu, ale przed znakiem zapytania i resztą argumentów. Na przykład:

http://myhost/cgi-bin/myscript/remaining_path_info?arg1+arg2

Kiedy skrypt jest uruchomiony, informacja w ścieżce jest umieszczona w zmiennej środo­wiskowej PATH_INFO. Można jej później użyć w dowolny sposób wewnątrz skryptu.

Załóżmy, że na wielu stronach znajduje się mnóstwo odnośników do tego sa­mego skryptu. Mo­żesz wykorzystać dodatkowy parametr w ścieżce do przesłania nazwy pli­ku HTML, z które­go nastąpiło odwołanie. Następnie po wykonaniu skryptu, kiedy w odpo­wiedzi zwracany jest dokument HTML, możesz dołączyć odnośnik z powrotem do strony, z której nastąpiło odwołanie.

Generowanie specjalnych odpowiedzi

W kilku przykładach wymienionych dotychczas w tym rozdziale, napisałeś skrypty, które generowały w odpowiedzi dane, zazwyczaj dane HTML. Były one następnie odsyłane do przeglądarki w celu interpretacji i wyświetlenia. Ale co się stanie, jeśli nie chcesz wysyłać strumienia danych jako rezultatu działania skryptu? Co będzie, jeśli zamiast tego zechcesz załadować inną istniejącą stronę? Co, jeśli chcesz, żeby skrypt wykonał jakąś czynność bez zwracania odpowiedzi do przeglądarki?

Nie martw się, wszystkie te czynności są możliwe w skryptach CGI. Kolejna sekcja wyjaś­nia, jak się to robi.

Odpowiedź polegająca na odesłaniu innego dokumentu

Odpowiedź CGI nie musi mieć postaci strumienia danych. Czasem łatwiej jest powiedzieć przeglądarce, żeby pobrała inną stronę z Twojego serwera (lub nawet z dowolnego serwe­ra, jeśli ma to jakieś znaczenie). Aby ją o tym powiadomić, wysyłamy w odpowiedzi nastę­pujący nagłówek:

Location: ../docs/final.html

Linia Location jest użyta w miejsce normalnej odpowiedzi. To znaczy, że używając nag­łów­ka Location, nie musimy już stosować Content-type lub dołączać do odpowiedzi jakich­kolwiek innych danych (i faktycznie, nawet nie bardzo można to zrobić). Podobnie jednak, jak w przypadku Content-type, trzeba dodać na końcu pustą linię.

Ścieżka do pliku może być zarówno pełnym URL-em, jak i ścieżką względną. Wszystkie ścieżki względne są tworzone względem lokalizacji samego skryptu. Poniższy szuka doku­mentu final.html w katalogu docs znajdującym się powyżej bieżącego:

echo Location: ../docs/final.html

echo

	Nie można mieszać nagłówków Content-type i Location. Na przykład, jeśli chcemy wygenerować standardową stronę, a później dodać na dole jakiś dodatkowy na­pis, musimy użyć nagłówka Content-type i wygenerować stronę w całości same­mu. Zauważmy, że można stosować polecenia skryptowe do otwarcia pliku lokalne­go i wyświetlenia go. Polecenie cat nazwa_pliku wysyła zwartość pli­ku wskazanej nazwie na standardowe wyjście.

Brak odpowiedzi

Czasem może być przydatne, aby skrypt CGI w ogóle nie generował żadnych danych. Cza­sem chcemy jedynie pobrać informację od użytkownika. Możemy nie chcieć wysyłać nowe­go dokumentu ani poprzez generowanie go, ani poprzez wysyłanie gotowego pliku. Doku­ment, który poprzednio znajdował się w przeglądarce, powinien pozostać na swoim miejscu.

Na szczęście, jest na to dość łatwy sposób. Zamiast wysyłać nagłówek Content-type lub Location, wykorzystujemy następującą linię (również z pustą linią bezpośrednio po niej).

Status: 204 No Response

Nagłówek Status pozwala na wysłanie do serwera kodu statusu odpowiedzi (i również do przeglądarki). W szczególności, do przeglądarki przesyłany jest wtedy kod 204 i ta, jeśli go rozumie, nie powinna wyświetlić nowej strony.

W takim przypadku nie ma potrzeby wysyłania jakichkolwiek innych danych, ponieważ nie chcemy, żeby przeglądarka cokolwiek z nimi robiła, po prostu poprzestajemy na pojedyn­czej linii Status. Oczywiście, sam skrypt powinien wykonywać jakieś zadania. Inaczej po co byłby potrzebny?

	Mimo, że No Response jest częścią oficjalnej specyfikacji HTTP, może się zdarzyć, że nie będzie poprawnie zaimplementowany we wszystkich przeglądarkach lub może powodować dziwne skutki. Zanim użyjemy go w swoich progra­mach, dobrze jest przeprowadzić kilka prób na różnych przeglądarkach, aby przekonać się samemu, jakie będą rezultaty. Ogólnie rzecz biorąc, lepiej przesłać do przeglądarki odpowiedź informującą, że coś poszło nie tak, żeby użytkownicy wiedzieli co się dzieje.

Skrypty przetwarzające formularze

W większości przypadków, skrypty CGI są wykorzystywane do przetwarzania danych z for­mularzy. Wywołanie skryptu bezpośrednio poprzez odnośnik nie pozwala użytkownikowi na przekazanie do niego argumentów. Formularze pozwalają na wprowadzanie dowol­nej ilości informacji, przesyłanie ich do serwera i przetwarzanie przez skrypt CGI. Są to takie same skrypty i zachowują się podobnie. Również w ich przypadku można stosować na­główki Content-type i Location w odpowiedzi wysyłanej do przeglądarki. Są jednak pewne różnice w sposobie wywołania skryptu oraz przesyłania do niego danych.

Formularze i skrypty je przetwarzające

Jak już nauczyłeś się wcześniej, każdy formularz, który można znaleźć w Internecie ma dwie części: kod HTML formularza, który wyświetlany jest w oknie przeglądarki oraz skrypt przetwarzający zawartość formularza. Są one ze sobą połączone poprzez kod HTML.

Atrybut ACTION znacznika <FORM> zawiera nazwę skryptu przetwarzającego formularz, jak poniżej:

<FORM ACTION="http://www.mojserwer.com/cgi-bin/processorscript">

Oprócz tego odnośnika do skryptu, na każdym polu formularza (pole tekstowe, przycisk radiowy itd.) jest atrybut NAME, który zawiera nazwę elementu. Kiedy dane z formularza są dos­tarczone do skryptu określonego w ACTION, nazwy pól oraz ich zawartość zostają przesłane do niego w postaci par nazwa-wartość. Wewnątrz skryptu możesz sprawdzić zawartość każdego pola (wartość), wykorzystując jego nazwę.

GET i POST

Jedną z części formularzy, o której nie wspomniałam w poprzednim rozdziale, jest atrybut METHOD. METHOD określa sposób, w jaki dane będą przesłane z przeglądarki do serwera, a później do skryptu. Może on przyjmować jedną z dwóch wartości: GET lub POST.

GET działa, tak jak w przypadku skryptów, które poznałeś w poprzedniej sekcji. Dane for­mularza są spakowane i dołączone do URL-a, który został wskazany jako atrybut ACTION. Tak więc, jeśli twój atrybut ACTION wygląda następująco:

ACTION="/cgi-bin/mojskrypt"

i w przypadku, gdy mamy w formularzu takie pola, jak w poprzedniej sekcji, ostateczny URL może wyglądać tak:

http://mojkomputer/cgi-bin/mojskrypt?username=Agamemnon&phone=555-6666

Zauważmy, że taki sposób formatowania różni się od argumentów, które przekazywaliśmy do skryptu ręcznie. Ten format nazywany jest kodowaniem URL i wyjaśniony jest szcze­gółowo w dalszej części tego rozdziału.

Kiedy serwer wykonuje skrypt CGI w celu przetworzenia formularza, ustawia wartość zmiennej środowiskowej o nazwie QUERY_STRING na to, co znajduje się po znaku zapytania w URL-u.

POST działa podobnie do GET, poza tym, że przesyła dane niezależnie od odwołania do skryptu. Twój skrypt otrzymuje je na standardowym wejściu. (Niektóre serwery WWW mogą przechowywać parametry w oddzielnym pliku tymczasowym, serwery UNIX-owe używają standardowego wejścia.) Zmienna QUERY_STRING nie jest ustawiona w przypadku, gdy korzystamy z metody POST.

Kiedy należy używać każdej z tych metod? POST jest bezpieczniejsza, szczególnie jeśli oczekujemy bardzo wielu danych z formularza. Kiedy używamy GET, serwer przypisuje zmiennej QUERY_STRING zakodowaną wartość wszystkich przesłanych danych; wielkość tych danych może być ograniczona wielkością zmiennej. Innymi słowy, jeśli formularz zawiera bardzo dużo danych i przesyła je metodą GET, to część spośród nich może zostać utracona.

Jeśli używamy metody POST, można przekazywać dowolne ilości danych, ponieważ są one przesyłane jako oddzielny strumień i nigdy nie są przypisywane pojedynczej zmiennej.

Kodowanie URL

Kodowanie URL jest formatem, jakiego przeglądarka używa do pakowania danych wejścio­wych przy przesyłaniu ich do serwera. Przeglądarka zbiera wszystkie nazwy i wartości pól, koduje je jako pary nazwa-wartość, tłumacząc wszystkie znaki, których nie można wprost przesłać. Następnie ustawia je w ciąg i w zależności od tego czy stosujemy metodę GET, czy POST, przesyła je jako część URL lub oddzielnie. W obu przypadkach, dane formularza docierają do serwera (i do skryptu) w formacie wyglądającym tak:

nazwisko=Jan+Kowalski&plec=mezczyzna&status=zaginiony

Kodowanie URL przebiega zgodnie z następującymi regułami.

• Każda para nazwa-wartość jest oddzielona od innych znakami ampersand (&).

• Nazwa i wartość w każdej z par są od siebie oddzielone znakiem =. Jeśli użytkownik pozostawi jakieś pole puste, jego nazwa i tak pojawi się w danych wejściowych z pustą wartością.

• Wszystkie znaki specjalne (znaki, które nie są prostymi siedmiobitowymi kodami ASCII) są kodowane w postaci heksadecymalnej, poprzedzonej znakiem procenta (%). Również sam znak procenta jest kodowany.

• Odstępy (spacje) zamieniane są na znaki plus (+).

Ponieważ dane z formularza są przesyłane do skryptu w formie zakodowanej, przed użyciem należy je najpierw zdekodować. Jednakże, ponieważ jest to proces powta­rzal­ny, są narzędzia, które mogą nam w tym pomóc. Nie ma potrzeby pisania włas­nych programów do dekodowania, chyba że chcemy użyć ich do czegoś specjalnego. Dos­tępne programy dekodujące mogą wykonać większość pracy, mogą również zajmować się obsłu­giwaniem sytuacji specjalnych, których my nie wzięliśmy pod uwagę i zapobiec zat­rzyma­niu skryptu, jeśli ktoś wprowadzi nieprawidłowe dane.

W dalszej części tego rozdziału wspomniane zostaną niektóre programy do dekodowania danych wejściowych. W dalszych przykładach będziemy posługiwać się programem uncgi, który dekoduje dane wejściowe przesłane z formularza i tworzy zestaw zmiennych środo­wiskowych, w oparciu o pary nazwa-wartość. Każda zmienna ma nazwę równą nazwie pola formularza poprzedzoną prefiksem WWW_ i wartość, odpowiadającą jego wartości. Tak więc, jeśli mamy formularz z polem o nazwie username, w rezultacie zostanie utworzona zmienna środowiskowa WWW_username i jej wartość będzie równa temu, co zostało wpisa­ne w odpo­wiednie pole formularza. Kiedy mamy już wszystkie dane w zmiennych środo­wiskowych, możemy łatwiej wykorzystać je w swoim programie.

Kod źródłowy programu uncgi możesz znaleźć na stronie http://www.midwinter.com/~koreth/uncgi.html. Po skopiowaniu programu, skompiluj go zgodnie z instrukcjami zamieszczonymi na podanej stronie WWW i zainstaluj w katalogu cgi-bin. Teraz będziesz już mógł go używać. Jedną z wielkich zalet programu uncgi jest fakt, iż można z niego korzystać w dowolnym języku programowania używanym do tworzenia skryptów CGI w systemie UNIX. Program ten, po prostu, zapisuje dane przesłane z formularza w postaci zmiennych środowiskowych. W tym momencie ich wartości mogą być odczytane i wykorzystane w skrypcie CGI napisanym w dowolnym języku programowania, pod warunkiem, iż język ten umożliwia dostęp do zmiennych środowiskowych.

Ćwiczenie 18.3: Część 2. Powiedz, jak się nazywasz?


Załóżmy, że dysponujesz formularzem, w którym użytkownicy mogą podawać swoje imię? Teraz możesz napisać skrypt, który będzie go obsługiwał. (Formularz pokazany jest na rys. 18.5). Używając go, można wpisać imię i nazwisko oraz wysłać, naciskając przycisk.

Rysunek 18.5 Formularz „Powiedz mi jak się nazywasz”

Co się stanie, jeśli nie wpiszesz nic w formularzu? Wtedy skrypt odsyła odpowiedź przed­stawioną na rys. 18.6.

Rysunek 18.6 Rezultat działania formularza pytającego o nazwisko

Dane są przesyłane do skryptu, który odsyła w odpowiedzi dokument HTML zawierający powitanie, którego częścią jest wprowadzone imię, tak jak to pokazano na rys. 18.7.

Rysunek 18.7 Inny rezultat

Modyfikacja kodu HTML w formularzu

We wcześniejszych przykładach używałeś testowego programu o nazwie post-query jako atry­butu ACTION znacznika <FORM>. Teraz, kiedy masz do czynienia z prawdziwym skryp­tem, możesz zmodyfikować go tak, żeby odwoływał się do tego skryptu. W poniższym przykła­dzie znacznik <FORM> wskazuje na skrypt o nazwie form-name, w katalogu cgi-bin znajdują­cym się o jeden poziom wyżej w stosunku do aktualnego katalogu:

<FORM METHOD=POST ACTION="../cgi-bin/form-name">

</FORM>

Jeśli używasz programu uncgi do dekodowania danych wejściowych, tak jak ja w tych przy­kładach, wygląda to nieco inaczej. Aby zmusić uncgi do prawidłowego działania, wy­wołu­jemy go najpierw w URL-u, a później podajemy właściwą nazwę skryptu do wykona­nia, tak jakby uncgi było katalogiem. Oto przykład:

<FORM METHOD=POST ACTION="../cgi-bin/uncgi/form-name">

</FORM>

Poza tymi modyfikacjami, w formularzu nie potrzeba wprowadzać żadnych poważniejszych zmian. Teraz musimy zająć się skryptem przetwarzającym formularz.

Skrypt

Skrypt przetwarzający dane formularza jest skryptem CGI, tak jak ten, który napisaliśmy w poprzedniej części rozdziału. Te same reguły, odnośnie nagłówka Content-type i prze­syła­nia danych do przeglądarki, dotyczą również tego skryptu

Pierwszym krokiem w skrypcie przetwarzającym formularz jest zazwyczaj zdekodowanie informacji przesłanej do niego metodą POST. W tym przykładzie, dzięki użyciu uncgi nie ma takiej potrzeby, ponieważ dane zostały już zdekodowane. Pamiętasz, jak wstawiliśmy odwołanie do uncgi w URL-u do skryptu? Kiedy formularz zostaje wysłany, serwer przeka­zuje go do skryptu uncgi, który dekoduje dane z formularza, a następnie wywołuje właś­ciwy skrypt. W tym skrypcie wszystkie pary nazwa - wartość są łatwo dostępne i gotowe do użycia.

W dalszym ciągu wyświetlamy standardowe nagłówki CGI i kod HTML rozpoczynający stronę:

echo Content-type: text/html

echo

echo "<HTML><HEAD>"

echo "<TITLE>Witaj</TITLE>"

echo "</HEAD><BODY>"

echo "<P>"

Teraz przechodzimy do właściwej części skryptu. Musimy zrealizować dwa zadania: po pierwsze, sprawdzić, czy użytkownik wprowadził swoje imię, po drugie, wyświetlić po­witanie.

Wartość elementu Imie, zgodnie z nazwą, zawarta jest w zmiennej środowiskowej WWW_Imie. Wykorzystując prosty test zmiennej (-z), dostępny z poziomu powłoki, możemy sprawdzić, czy zmienna jest pusta i wygenerować odpowiednią odpowiedź:

if [ ! -z "$WWW_Imie" ]; then

echo "Witaj, "

echo $WWW_Imie

else

echo "Nie masz imienia?"

fi

Wreszcie, dodajemy końcówkę kodu odpowiedzialną za wyświetlanie odnośnika, co prowadzi do poprzedniej strony (mającej tutaj nazwę imie1.html), w katalogu znajdującym się o jeden poziom wyżej w stosunku do cgi-bin:

echo "<a href=”../aki/imie1.html”>Poprzednia strona</a>"

echo "</BODY></HTML>"


I to wszystko, co musimy zrobić. Nauka tworzenia skryptów CGI jest dość trudna, ich łączenie z formularzami, względnie łatwe. Nawet, jeśli coś pozostaje jeszcze niejasne, nie martw się. Gdy zdobędziesz nieco więcej praktyki, wszystko stanie się jasne.

Najczęstsze problemy

Poniżej znajduje się lista najczęściej spotykanych problemów związanych z zastosowaniem skryptów CGI wraz z rozwiązaniami.

• Zawartość skryptu jest wyświetlana, a nie wykonywana.

Czy skonfigurowałeś swój serwer, tak aby akceptował skrypty CGI? Czy skrypty są umieszczone w odpowiednim katalogu (zazwyczaj cgi-bin)? Czy serwer pozwala na stosowanie skryptów z rozszerzeniem .cgi?

• Błąd 500: serwer nie umożliwia stosowania metody POST.

Ten błąd można napotkać wtedy, gdy użyliśmy metody POST. Zazwyczaj błąd ten oznacza, że serwer nie jest skonfigurowany do pracy ze skryptami CGI lub nastąpiła próba dostępu do skryptu, który nie znajduje się w katalogu CGI (zobacz wy­żej).

Czasem ten błąd może znaczyć, że pomyliłeś ścieżkę do skryptu. Sprawdź ścieżkę w formularzu i, jeśli jest poprawna, upewnij się, że skrypt znajduje się w odpowiednim katalogu CGI (zazwyczaj cgi-bin) lub ma odpowiednie rozszerzenie (.cgi).

• Dokument nie zawiera danych.

Sprawdź, czy między nagłówkami a treścią dokumentu znajduje się pusta linia.

• Błąd --> 500[Author:MMP] : nieprawidłowy dostęp do skryptu

Sprawdź, czy skrypt jest wykonywalny. (W przypadku systemów UNIX, upewnij się, że skrypt ma prawa do wykonania i ewentualnie je ustaw poleceniem chmod +x). Powinieneś mieć możliwość uruchomienia skryptu z linii poleceń, zanim wywołasz go poprzez przeglądarkę.

Zmienne CGI

Zmienne CGI są specjalnymi zmiennymi środowiskowymi ustawianymi przy wywołaniu skryptu CGI. Do wszystkich tych zmiennych można odwoływać się w skrypcie. Tabela 18.2 zawiera ich zestawienie.

Tabela 18.2: Zmienne środowiskowe CGI

Zmienna	Co oznacza
SERVER_NAME	Nazwa lub adres IP komputera, z którego nastąpiło odwołanie do skryptu CGI.
SERVER_SOFTWARE	Rodzaj serwera, z którego korzystamy, na przykład, CERN/3.0 lub NCSA/1.3.
GATEWAY_INTERFACE	Wersja CGI działającego na serwerze. W przypadku serwerów UNIX-owych powinno to być CGI/1.1.
SERVER_PROTOCOL	Protokół HTTP, z którego korzysta serwer. Powinien być to HTTP/1.0 lub HTTP/1.1.
SERVER_PORT	Port TCP, z którego korzysta serwer. Dla serwerów WWW jest to zazwyczaj port 80.
REQUEST_METHOD	Zawiera metodę HTTP użytą w zleceniu (GET, POST, HEAD).
HTTP_ACCEPT	Zmienna ta zawiera listę typów danych, które przeglądarka akceptuje.
HTTP_USER_AGENT	Określa typ przeglądarki używanej przez odwiedzającego. Zazwy­czaj składa się z nazwy przeglądarki oraz platformy systemowej.
HTTP_REFERER	URL dokumentu, z którego nastąpiło odwołanie do skryptu (np. dokument zawierający formularz).
PATH_INFO	Zawiera dodatkową informację o ścieżce.
PATH_TRANSLATED	Dodatkowa informacja o ścieżce, przekształcona do postaci pełnej ścieżki opisującej plik serwera. Składa się ze ścieżki do głównego katalogu oraz dołączonej informacji z PATH_INFO.
SCRIPT_NAME	Ścieżka dostępu do aktualnie wykonywanego skryptu CGI, w postaci, w jakiej została podana w adresie URL, na przykład: /cgi-bin/skryptcgi.
QUERY_STRING	Zawiera argumenty przekazane do skryptu z formularza (jeśli są one przesyłane metodą GET). Zmienna zawiera wszystko, co w URL-u pojawiło się po znaku zapytania.
REMOTE_HOST	Zawiera nazwę domenową komputera osoby korzystającej z naszego serwera.
REMOTE_ADDR	Zawiera adres IP komputera osoby korzystającej z naszego serwera.
REMOTE_USER	Zawiera identyfikator osoby korzystającej ze skryptu. Wartość ta jest ustawiana przy włączonej autoryzacji.
REMOTE_IDENT	Identyfikator osoby na zdalnym systemie, uzyskany poprzez wykorzystanie protokołu ident. Działa pod warunkiem, że oba systemy skonfigurowane są tak, żeby korzystać z tego protokołu.
CONTENT_TYPE	Zawiera typ danych dołączonych do zlecenia wysłanego poprzez formularz. Odpowiada atrybutowi ENCTYPE formularza. Może to być application/x-www-form-urlencoded lub, jeśli formularz wykorzys­tuje możliwość kopiowania plików, multipart/form-data.
CONTENT_LENGTH	Zawiera ilość bajtów danych dołączonych do zlecenia POST, dostępnych na standardowym wejściu programu.

Programy dekodujące dane z formularzy

Jedną z podstawowych różnic pomiędzy zwykłymi skryptami CGI, a skryptami przetwarza­jącymi formularze jest to, że umożliwiając wysyłanie danych w formacie URL, muszą zawierać metody pozwalające na ich dekodowanie. Na szczęście, ponieważ wiele osób pisze skrypty współpracujące z formularzami, jest dostępnych wiele gotowych progra­mów, które mogą wykonać za nas tę pracę. Osobiście lubię szczególnie dwa programy: uncgi do użytku ogólnego oraz cgi-lib.pl, bibliotekę do Perla, pozwalającą na pisanie skryptów w tym języku. Oczywiście, jeśli komuś nie wystarczają powyższe rozwiązania, może napisać własne.

Można również znaleźć dobre programy realizujące transfer plików poprzez formularze, mimo że jest ich trochę mniej. Na zakończenie tej sekcji wymienię kilka, które udało mi się znaleźć.

uncgi

Program uncgi Stevena Grimma jest napisany w C i dekoduje dane z formularzy. Więcej informacji oraz źródło programu można znaleźć pod adresem http://www.hyperion.com/ ~koreth/uncgi.html.

Uncgi należy zainstalować w katalogu cgi-bin. Należy się również upewnić, że zanim skompilujemy skrypt, wprowadzone zostaną niezbędne poprawki do pliku Makefile, w celu określenia lokalizacji tego katalogu w systemie. Dzięki temu program będzie w stanie odnaleźć skrypty CGI.

Dla wykorzystania uncgi w formularzach, należy zmodyfikować odpowiednio atrybut ACTION znacznika FORM. Zamiast wywoływać skrypt bezpośrednio, należy dodać do niego wywołanie skryptu uncgi. Na przykład, jeśli wywołujemy skrypt CGI o nazwie sleep2.cgi wedle wzorca:

<FORM METHOD=POST ACTION="http://www.mojserwer.com/cgi-bin/sleep2.cgi">

wtedy należy go zastąpić wywołaniem:

<FORM METHOD=POST ACTION="http://www.mojserwer.com/cgi-bin/uncgi/sleep2.cgi">

	Program uncgi jest doskonałym przykładem wykorzystania dodatkowej informacji o ścieżce. Skrypt uncgi wykorzystuje nazwę skryptu przekazaną jako informację o ścieżce wewnątrz URL-a.

Program uncgi automatycznie czyta dane wejściowe dostarczone przy pomocy metody POST lub GET (rozpoznaje je sam automatycznie), dekoduje je i tworzy zestaw zmiennych środowiskowych o nazwach odpowiadających atrybutom NAME, z dołączonym prefiksem WWW_. Tak więc, jeśli formularz zawiera pole o nazwie Imie, wtedy zostanie utworzona od­powiadająca mu zmienna uncgi o nazwie WWW_Imie.

Jeśli dane wejściowe zawierają kilka zmiennych o takich samych nazwach, uncgi tworzy tylko jedną zmienną o kilku wartościach, oddzielonych znakiem hash (#). Na przykład, jeśli dane wejściowe zawierają zmienną zakupy=ser, zakupy=chleb oraz zakupy=piwo, wtedy zmien­na WWW_zakupy będzie zawierać wartość ser#chleb#piwo. Informację w tej postaci należy w odpowiedni sposób przetworzyć w skrypcie.

CGI.pm

CGI.pm jest modułem używanym do dekodowania danych przesyłanych z formularzy i przygotowaniu ich do wykorzystania w skryptach CGI pisanych w języku Perl. Moduł ten został napisany przez Lincolna Steina i uzyskał tak wielką popularność, iż aktualnie jest dołączany do wszystkich wersji języka Perl. Oznacza to, że jeśli skopiujesz i zainstalujesz najnowszą wersję Perl-a, nie będziesz już potrzebował niczego więcej, aby rozpocząć tworzenie własnych skryptów CGI.

Prócz podstawowych możliwości funkcjonalnych umożliwiających dekodowanie danych przekazywanych z formularzy, moduł jest także w stanie ułatwić życie osobom, które wiedzą, jak pisać programy, lecz nie znają się na zasadach tworzenia kodu HTML. Został on wyposażony we wszelkiego typu metody służące do generowania pól formularzy oraz znaczników HTML, które możesz wykorzystywać zamiast podawania samych znaczników w wywołaniach funkcji print. Pisząc skrypty CGI, możesz wykorzystać tę metodę, która będzie Ci bardziej odpowiadać.

Głównym celem niniejszej książki jest przedstawienie języka HTML, z tego względu nie mam zamiaru prezentować tu możliwości modułu CGI.pm umożliwiających generację kodu HTML. Zamiast tego skoncentruję uwagę na pokazaniu, w jaki sposób można go użyć do odczytywania i przetwarzania danych przesyłanych z formularzy. Jeśli chciałbyś dowiedzieć się czegoś więcej na temat pełnych możliwości funkcjonalnych tego modułu, wystarczy wpisać polecenie perldoc CGI w wierszu poleceń w systemie UNIX lub w oknie MS-DOS w systemie Windows, zakładając oczywiście, że moduł CGI.pm został zainstalowany.

Wykorzystanie modułu CGI.pm do dekodowania danych przekazywanych z formularzy jest stosunkowo proste. W programie CGI napisanym w języku Perl będziesz musiał stworzyć obiekt zapytania, w którym będą przechowywane wszystkie informacje dotyczące żądania. Po jego utworzeniu, wszystkie dane przekazane z formularza będą dostępne za jego pośrednictwem. Poniżej przedstawiłam fragment kodu służący do utworzenia tego obiektu:

$query = new CGI;

Zmienna $query wskazuje na nowy obiekt zapytania CGI. Oczywiście zmiennej możesz nadać zupełnie dowolną nazwę. Po utworzeniu obiektu dostęp do danych przesłanych do skryptu z formularza będzie można uzyskać za pośrednictwem tablicy rozproszonej o nazwie param. Na przykład, jeśli formularz będzie zawierał pole o nazwie nazwa_uzytkownika, to jego wartość można pobrać w skrypcie przy użyciu następującego fragmentu kodu:

$zmienna = $query->param('nazwa_uzytkownika');

Korzystając z tej metody, można uzyskać dostęp do wartości każdego pola formularza, wystarczy zastąpić nazwę nazwa_uzytkownika nazwą pola, którego wartość chcesz pobrać. Kolejną ogromną zaletą modułu CGI.pm jest możliwość dostępu wartości cookies przekazywanych do skryptu, w identyczny sposób, jak do wartości pól formularzy. Przykładowo, jeśli przeglądarka użytkownika prześle do skryptu cookie o nazwie sesja, to jego wartość można pobrać przy użyciu następującego fragmentu kodu:

$cookie_sesja = $query->cookies('sesja');

Samodzielne dekodowanie danych z formularzy

Dekodowanie danych z formularzy jest jednym z tych zadań, które większość ludzi niechęt­nie rozwiązuje samodzielnie, pozostawiając je gotowym narzędziom, takim jak wymienione powyżej. Jednak, jeśli nie masz dostępu do tych programów lub korzystasz z systemu, który nie pozwala na ich zastosowanie albo uważasz, że możesz zrobić to lepiej, skorzystaj z poniższych informacji.

Pierwszą rzeczą, którą program dekodujący powinien sprawdzać, jest metoda, jaką dane zostały przesłane. Na szczęście, to jest akurat łatwe zadanie. Zmienna środowiskowa REQUEST_METHOD ustawiona przez serwer tuż przed wywołaniem programu CGI, zawiera tę informację.

Jeśli dane z formularza będą przesłane za pomocą metody GET, będą przechowywane w zmiennej QUERY_STRING.

Jeśli dane z formularza przesyłane są za pomocą metody POST, zostaną wysłane na standar­dowe wejście skryptu. Zmienna środowiskowa CONTENT_LENGTH wskazuje na ilość bajtów danych wysłanych z przeglądarki. W dekoderze powinieneś się upewnić, że czytasz dokład­nie tyle bajtów. Niektóre z przeglądarek potrafią w sposób niewłaściwy wysyłać na ich koń­cu dodatkowe dane.

Typowy skrypt dekodujący powinien działać zgodnie z poniższą instrukcją

1. Powinien rozdzielić pary nazwa-wartość (względem znaku &).

2. Następnie oddzielić nazwę od wartości (względem znaku =). Jeśli jakaś nazwa występuje kilka razy, to należy opracować sposób na uwzględnienie tej właściwości.

3. Później należy zmienić znaki plus na spacje.

4. Na koniec zdekodować wszystkie znaki zapisane heksadecymalnie.

Czy interesuje Cię dekodowanie zawartości plików przesyłanych z przeglądarki na serwer? W tym przypadku reguły działania są zupełnie inne. W szczególności, informacje otrzymywane w tym przypadku są zgodne z zasadami obsługi wieloczęściowych wiadomości MIME, a zatem będziesz musiał obsługiwać wiele różnych typów danych. Jeśli interesują Cię te zagadnienia, to bez trudu odnajdziesz specyfikacje przekazywania plików z przeglądarki na serwer, a w nich, wszelkie szczegółowe informacje.

Skrypty bez przetwarzania nagłówków

Jeśli prześledziłeś uważnie podstawowe reguły pisania skryptów CGI opisane w tej części, to wiesz już, że dane wyjściowe ze skryptów będą czytane przez serwer i odsyłane do przeglądar­ki poprzez sieć. W większości przypadków takie przetwarzanie jest wystarczające, gdyż ser­wer jest w stanie wykonać dodatkową kontrolę danych i dodać do nich własne nagłówki.

Jednak w pewnych przypadkach może się zdarzyć, że chcemy obejść przetwarzanie danych przez serwer i wysyłać je wprost do przeglądarki. Może to być przydatne do przyspieszenia działania lub wysyłania danych, które serwer mógłby zakwestionować. W większości zwyk­łych skryptów i tych obsługujących formularze, nie jest to potrzebne.

Skrypty CGI obsługujące taki sposób przekazu danych nazywane są skryptami NPH (od angielskiego skrótu Non-Parsed Headers). Jeśli chcesz skorzystać ze skryptu NPH, musisz go nieco zmodyfikować.

• Skrypt powinien mieć przedrostek nph-, na przykład, nph-pingaki lub
  nph-fixdata.

• Skrypt musi samodzielnie wysyłać dodatkowe nagłówki HTTP oprócz standardowego Content-type, Location i Status.

Nagłówki są najbardziej oczywistą zmianą, jaką należy wprowadzić w skrypcie. W szcze­gólności pierwsza linia powinna zawierać kod statusu, na przykład:

HTTP/1.0 200 OK.

Nagłówek ten oznacza, że „wszystko poszło dobrze, dane są w drodze”. Inny przykład nag­łówka to:

HTTP/1.0 204 No Response

Jak już nauczyliśmy się wcześniej, kod ten oznacza, że skrypt nie wysłał żadnych danych, więc przeglądarka nie powinna nic robić (na przykład, ładować strony).

Drugi nagłówek, który powinniśmy umieścić, to Server. To, czy jest on wymagany nie jest jednoznacznie określone, jednakże jego umieszczenie jest przydatne. W końcu zastosowa­nie skryptu NPH niejako symuluje bezpośrednio działanie serwera, więc dodanie nagłówka Server na pewno nie zaszkodzi.

Nagłówek ten wskazuje po prostu na wersję i nazwę serwera, z którego korzystamy. Na przykład:

Server: NCSA/1.3

Server: CERN/3.0pre6

Po dołączeniu tych nagłówków, należy również załączyć pozostałe, wśród nich Content-type i Location. Przeglądarka potrzebuje tych informacji do podjęcia decyzji, w jaki sposób ma obsłużyć nadchodzące dane.

I znów należy zaznaczyć, że w większości przypadków skrypty NPH nie będą nam do niczego potrzebne. Zwykły skrypt CGI zazwyczaj wystarczy w zupełności.

Skrypty ISINDEX

Na zakończenie dyskusji o CGI, pozwolę sobie wspomnieć o przeszukiwaniu ISINDEX. Użycie znacznika <ISINDEX> (przestarzałego w HTML-u 4.0) było w zamierzchłej przeszłości WWW wykorzystywane do wysyłania informacji z przeglądarki do serwera. Z chwilą wprowadzenia formularzy, użycie ISINDEX stało się niepotrzebne. Formularze są znacznie bardziej elastyczne, zarówno w sen­sie rozplanowania, możliwości wykorzystania różnych elementów, jak i przetwarzania ich za pomocą skryptów. Jednak ja lubię dokładność, dlatego też załączam krótki opis działania przeszukiwania ISINDEX.

Przeszukiwanie ISINDEX jest realizowane za pomocą skryptów CGI, które wywoływane są z argumentami, podobnie jak skrypty opisane wcześniej w tym rozdziale, które służyły nam do sprawdzenia, kto pracuje w systemie. Skrypty wykorzystujące ISINDEX działają w nastę­pujący sposób.

• Jeśli skrypt jest wywołany bez argumentów, zwracany HTML powinien zawierać pole do wprowadzenia kluczy przeszukiwania za pomocą znacznika ISINDEX. (Pamiętajmy, że to rozwiązanie pojawiło się przed formularzami.)

• Kiedy użytkownik wyśle klucz, wywoływany jest skrypt ISINDEX z argumentem zawierającym wpisaną informację. Następnie skrypt przetwarza jakieś informacje wedle wskazanego klucza, a później zwraca odpowiedni dokument HTML.

Głównym elementem przeszukiwania ISINDEX jest znacznik <ISINDEX>. Znacznik ten jest przeznaczony specjalnie do tego celu. Nie może zawierać wewnątrz dodatkowego tekstu ani innych znaczników.

Co więc robi? Powoduje w przeglądarce ustawienie informacji o przeszukiwaniu w doku­mencie. W zależności od typu przeglądarki, może to spowodować pojawienie się specjal­nego okna w przeglądarce. W nowszych przeglądarkach miejsce na wprowadzenie klucza pojawia się w treści strony (zobacz rys. 18.8). Użytkownicy mogą wpisać poszukiwany wyraz w polu i nacisnąć klawisz Enter, aby przesłać zapytanie na serwer.

Rysunek 18.8 Miejsce na wpisanie klucza wewnątrz strony

Zgodnie ze specyfikacją HTML 2.0, znacznik <ISINDEX> powinien znajdować się wewnątrz znacznika <HEAD> (podobnie jak <TITLE>). W starszych przeglądarkach nie było możliwoś­ci dowolnego pozycjonowania tego elementu na stronie. Wynikało to z tego, że znacznik ten nie był właściwie traktowany jak element strony. Jednakże, późniejsze wersje przeglą­darek umoż­liwiły jego zupełnie dowolne umiejscowienie, również poza nagłówkiem doku­mentu (HEAD). Większość współczesnych przeglądarek umożliwia jego ustawienie w dowol­nym miejscu do­kumentu, a odpowiednie pole do wprowadzenia informacji będzie się również tam pojawiało.

Wreszcie, rozszerzenie tego znacznika, wprowadzone w HTML 3.2, umożliwiło zdefinio­wanie komentarza dotyczącego tego pola. W starszych przeglądarkach był on stały i nie można go było zmienić (Szczególnie deprymujące było to, że było to angielskie wyrażenie w stylu „This is a searchable index. Enter keywords”). Nowy atrybut PROMPT pozwolił na jego swobodne definiowanie. Na przykład:

<P>Poszukiwanie studenta w bazie danych. Wprowadź jego dane (najpierw nazwisko)

<ISINDEX PROMPT="Nazwisko i imię studenta:">

Rysunek 18.9 pokazuje rezultat w oknie przeglądarki Internet Explorer.

Rysunek 18.9 Komentarz do wyszukiwania w oknie przeglądarki Netscape

Jedynym użytecznym zastosowaniem znacznika <ISINDEX> jest wyszukiwanie informacji. Mimo że można go umieścić w dowolnym dokumencie HTML, nie spełni on żadnej uży­tecznej funkcji, jeśli jego działanie nie będzie wsparte odpowiednim skryptem.

W większości przypadków wykorzystanie formularzy jest znacznie prostsze.

Podsumowanie

Skrypty CGI, czasem nazywane skryptami serwera, umożliwiają uruchamianie programów po stronie serwera i generowanie „w locie” dokumentów HTML oraz innych plików.

W tym rozdziale przejrzeliśmy podstawy tworzenia skryptów CGI zarówno prostych, jak i takich, które przetwarzają formularze, dodają specjalne nagłówki. Omówi­liś­my różnice między metodami GET i POST oraz sposoby dekodowania danych z formula­rzy. Ponadto, poznaliśmy zagadnienia dotyczące dodatkowych informacji o ścieżce, kodo­wania URL, przeszukiwania ISINDEX oraz różnych zmiennych CGI, których możemy użyć w swoich skryptach. Odtąd powinieneś już umieć samodzielnie pisać skrypty CGI do różnora­kich zastosowań.

Warsztat

W tej części rozdziału znajdziesz pytania, odpowiedzi, quiz oraz ćwiczenia związane tematycznie ze skryptami CGI.

Pytania i odpowiedzi

P. Co mam zrobić, jeśli nie umiem programować? Czy nadal mogę korzystać ze skry­ptów CGI?

O. Jeśli masz dostęp do serwera CGI w firmie świadczącej usługi internetowe, możesz spróbować uzyskać w tym zakresie pomoc bezpośrednio w tej firmie (oczywiście od­płatnie). Możesz również znaleźć wiele przykładów programów na różne platformy i spróbować je wykorzystać, szczególnie, jeśli choć trochę umiesz programować, lecz nie jesteś tego do końca pewien. Zazwyczaj programy takie są częścią dystrybucji serwera i znajdują się w tym samym repozytorium FTP. Przejrzyj dokumentację dostarczoną wraz z serwerem; często zawiera ona interesujące odnośniki do źródeł dalszych infor­macji. W wielu przypadkach problem, który chcesz rozwiązać za pomocą skryptu, może mieć już istniejące rozwiązanie, które wymaga jedynie niewielkich modyfikacji. Bądź jednak ostrożny, jeśli nie jesteś pewien, co robisz, możesz mieć spore problemy.

P. Mój serwer WWW ma katalog cgi-bin, ale ja nie mam do niego dostępu. Założy­łem więc w swoim katalogu domowym podkatalog o takiej nazwie i umieszczam tam skrypty, które nie chcą działać. Co robię źle?

O. Serwer WWW musi być w specjalny sposób skonfigurowany, aby pozwalał na urucho­mienie skryptów CGI i zazwyczaj wymaga wskazania odpowiednich katalogów. Nie możesz go po prostu stworzyć lub użyć specjalnego rozszerzenia, aby serwer natych­miast potraktował dane jako skrypt CGI. Do tego niezbędna jest wiedza na temat specy­ficznej konfiguracji serwera. Poproś o pomoc swojego administratora.

P. Mój administrator mówi, że mogę po prostu utworzyć katalog cgi-bin w swoim ka­talogu domowym, zainstalować tam skrypty i później korzystać z nich przy po­mo­cy specjalnego programu cgiwrap. W tej książce nic nie wspomniano o możli­wości posiadania prywatnych katalogów cgi-bin.

O. Cgiwrap jest użytecznym programem do bezpiecznego korzystania z CGI. Pozwala użyt­kownikom mającym konta w systemie UNIX na korzystanie z prywatnych katalogów CGI. Jednakże wymaga to od administratora zainstalowania go i odpowiedniego skon­figurowania. Jeśli Twój administrator już to zrobił, to masz szczęście. Będziesz mógł w prosty sposób skorzystać ze skryptów. Jeśli sam jesteś administratorem i interesujesz się informacjami na ten temat, możesz je znaleźć pod adresem: http:// wwwcgi.umr.edu/~cgiwrap.

P. Moje skrypty nie działają!

O. Czy przejrzałeś rozdział o najczęstszych problemach i możliwych rozwiązaniach? Tam opisano większość takich przypadków.

P. Firma, z której usług korzystam, nie da mi dostępu do cgi-bin. Naprawdę chciał­bym użyć formularzy. Czy jest na to jakiś sposób?

O. Jest jeden sposób — formularze „mailto”. Stosując je, korzystasz z URL-a wskazującego na Twój adres e-mail jako atrybut ACTION, na przykład:

<FORM METHOD=POST ACTION="mailto:[e-mail]">....</FORM>

Wtedy, przy wysłaniu formularza przez użytkownika, jego zawartość będzie przesłana pocztą elektroniczną (pod warunkiem, że wstawisz tam swój adres e-mail). Metoda ta nie wymaga stosowania żadnych skryptów.

Oczywiście to rozwiązanie posiada pewne wady. Pierwsza z nich polega na tym, że zawartość formularza będzie wysłana w sposób zakodowany. Czasem będzie ją bardzo trudno odczytać. Można to obejść, stosując program specjalny do formularzy mailto, który pozwoli na zdekodowanie danych.

Kolejny problem związany z wykorzystaniem formularzy „mailto” wynika z faktu, iż przesłanie takiego formularza nie daje żadnych widocznych rezultatów, nie pojawia się żadna strona z informacją: „Dziękuję! Podane informacje zostały przesłane”. Użytkownik kliknie przycisk Submit i pozornie nic się nie stanie. Brak potwierdzenia przesłania danych może spowodować, że użytkownik wyśle je kilkukrotnie. Z tego względu warto umieścić na stronie ostrzeżenie informujące użytkowników, że po wysłaniu danych nie należy oczekiwać jakiegokolwiek potwierdzenia.

Jest jeszcze jeden problem z formularzami „mailto”, otóż nie wszystkie przeglądarki są w stanie obsługiwać takie formularze. Oznacza to, że nie wszystkie osoby oglądające stronę będą mogły skorzystać z formularza. Na szczęście, większość najpopularniejszych przeglądarek poprawnie obsługuje formularze „mailto”.

P. Piszę własny dekoder do przetwarzania formularzy. Ostatnia para nazwa=wartość zawiera często dużo śmieci.

O. Czy na pewno czytasz jedynie tyle bajtów, ile wskazane jest w zmiennej CONTENT_LENGTH? Powinieneś najpierw sprawdzać ją i czytać tylko tyle informacji, ile potrzeba. Inaczej, może się okazać, że przeczytałeś ich zbyt dużo. Nie wszystkie przeglądarki prawidłowo kończą wysyłanie danych.

Quiz

1. Dlaczego, przeglądając kod źródłowy wyświetlonej strony WWW, nie można zobaczyć kodu skryptu CGI?

2. Jak się nazywa katalog serwera WWW, gdzie zazwyczaj są przechowywane skrypty CGI?

3. Jakie jest najczęstsze zastosowanie skryptów CGI?

4. Jaka jest nazwa atrybutu znacznika <FORM>, który określa nazwę skryptu CGI, jakiego należy użyć do przetworzenia danych z formularza?

5. Co to jest kodowanie URL?

Odpowiedzi

1. W odróżnieniu od skryptów pisanych w języku JavaScript oraz wszelkich innych rodzajów skryptów umieszczanych bezpośrednio w kodzie źródłowym dokumentów HTML i wykonywanych przez przeglądarkę, skrypty CGI są przechowywane i wykonywane na serwerze WWW.

2. Skrypty CGI są bardzo często przechowywane w katalogu o nazwie cgi-bin.

3. Aktualnie skrypty CGI są wykorzystywane do przetwarzania danych z formularzy.

4. Nazwa skryptu, którego należy użyć do przetworzenia danych z formularza jest podawana w atrybucie ACTION znacznika <FORM>.

5. Kodowanie URL to format zapisu informacji, którego przeglądarka używa do „spakowania” informacji podanych w formularzu i przesłania ich na serwer.

Ćwiczenia

1. Skontaktuj się ze swoim dostawcą usług internetowych i dowiedz się, czy daje on możliwość korzystania ze skryptów CGI. Jeśli takiej możliwości nie ma, a na swojej witrynie masz zamiar często korzystać z formularzy, to lepiej poszukaj innego dostawcy usług internetowych. Aktualnie, przeważająca większość dostawców usług internetowych zapewnia dostęp do katalogu cgi-bin jako standardową część pakietu świadczonych usług.

2. Jeśli Twój dostawca usług internetowych daje możliwość korzystania ze skryptów CGI, to sprawdź, czy oferuje on także skrypty gotowe do wykorzystania. Sprawdź, jakie skrypty są dostępne i spróbuj wykorzystać kilka z nich na swojej witrynie.

574

HTML 4 - Vademecum profesjonalisty

575

Skrypty CGI dla początkujących

dwa te same oznaczenia błędu, a zupełnie inne powody występowania, czy tak powinno być

19

---