2. Podstawy
W niniejszym rozdziale przedstawiamy podstawy programowania internetowego. Jego głównym celem jest zapoznanie czytelnika z głównymi zasadami programowania internetowego, które są niezależne od konkretnej technologii wykorzystywanej do ich wdrażania. Zawiera on liczne przykłady, które warto przetestować, aby stopniowo „wczuć się” w filozofię tworzenia stron internetowych. Bezpłatne narzędzia niezbędne do ich przetestowania przedstawiono na końcu dokumentu w załączniku zatytułowanym „Narzędzia internetowe”.
2.1. Elementy składowe aplikacji internetowej
Machine Serveur
15Klient
Numer | Rola | Typowe przykłady |
OS Serwer | Linux, Windows | |
Serwer WWW | Apache (Linux, Windows) IIS (NT), PWS (Win9x), Cassini (Windows + platforma .NET) | |
Skrypty wykonywane po stronie serwera. Mogą być uruchamiane przez moduły serwera lub przez programy zewnętrzne względem serwera (CGI). | PERL (Apache, IIS, PWS) VBSCRIPT (IIS, PWS) JAVASCRIPT (IIS, PWS) PHP (Apache, IIS, PWS) JAVA (Apache, IIS, PWS) C#, VB.NET (IIS) | |
Baza danych – może znajdować się na tym samym komputerze co program, który z niej korzysta, lub na innym komputerze, z którym łączy się przez Internet. | Oracle (Linux, Windows) MySQL (Linux, Windows) Postgres (Linux, Windows) Access (Windows) SQL Server (Windows) | |
OS Klient | Linux, Windows | |
Przeglądarka internetowa | Netscape, Internet Explorer, Mozilla, Opera | |
Skrypty wykonywane po stronie klienta w przeglądarce. Skrypty te nie mają dostępu do dysków komputera klienckiego. | VBscript (IE) JavaScript (IE, Netscape) PerlScript (IE) Aplety JAVA |
2.2. Wymiana danych w aplikacji internetowej z formularzem
Komputer kliencki Komputer serwerowy
Numer | Rola |
Przeglądarka po raz pierwszy wysyła żądanie URL dotyczące (http://machine/url). Nie przekazano żadnych parametrów. | |
Serwer WWW wysyła mu stronę internetową o tym URL. Może to być strona statyczna lub wygenerowana dynamicznie przez skrypt serwera (SA), który mógł wykorzystać zawartość baz danych (SB, SC). W tym przypadku skrypt wykryje, że żądanie dotyczyło pliku URL bez przekazania parametrów, i wygeneruje początkową stronę WEB. Przeglądarka odbiera stronę i wyświetla ją (CA). Skrypty po stronie przeglądarki (CB) mogły zmodyfikować początkową stronę wysłaną przez serwer. Następnie, w wyniku interakcji między użytkownikiem (CD) a skryptami (CB), strona internetowa zostanie zmodyfikowana. W szczególności zostaną wypełnione formularze. | |
Użytkownik zatwierdza dane z formularza, które następnie muszą zostać wysłane do serwera internetowego. Przeglądarka ponownie żąda pierwotnego skryptu URL lub innego, w zależności od sytuacji, i jednocześnie przekazuje serwerowi wartości z formularza. W tym celu może wykorzystać dwie metody o nazwach GET i POST. Po otrzymaniu żądania od klienta serwer uruchamia skrypt (SA) powiązany z żądanym URL, który wykrywa parametry i przetwarza je. | |
Serwer dostarcza stronę WEB wygenerowaną programowo (SA, SB, SC). Ten etap jest identyczny z poprzednim etapem 2. Dalsza wymiana danych odbywa się teraz zgodnie z etapami 2 i 3. |
2.3. Notations
W dalszej części założymy, że zainstalowano pewną liczbę narzędzi i przyjmiemy następujące oznaczenia:
oznaczenie | znaczenie |
katalog główny drzewa katalogów serwera Apache | |
katalog główny stron internetowych dostarczanych przez serwer Apache. To właśnie w tym katalogu głównym muszą znajdować się strony internetowe. Tak więc adres http://localhost/page1.htm odpowiada plikowi <apache-DocumentRoot>\page1.htm. | |
katalog główny drzewa katalogów powiązanego z aliasem cgi-bin, w którym można umieścić skrypty CGI dla serwera Apache. W ten sposób URL http://localhost/cgi-bin/test1.pl odpowiada plikowi <apache-cgi-bin>\test1.pl. | |
katalog główny stron internetowych generowanych przez IIS, PWS lub Cassini. W tym katalogu głównym muszą znajdować się strony internetowe. Tak więc URL http://localhost/page1.htm odpowiada plikowi <IIS-DocumentRoot>\page1.htm. | |
katalog główny drzewa katalogów języka Perl. Plik wykonywalny perl.exe znajduje się zazwyczaj w katalogu <perl>\bin. | |
katalogu głównego drzewa języka PHP. Plik wykonywalny php.exe znajduje się zazwyczaj w <php>. | |
katalog główny drzewa katalogów języka Java. Pliki wykonywalne związane z językiem Java znajdują się w katalogu <java>\bin. | |
katalogu głównym serwera Tomcat. Przykłady serwletów znajdują się w katalogu <tomcat>\webapps\examples\servlets, a przykłady stron – w katalogu JSP w katalogu <tomcat>\webbapps\examples\jsp |
W przypadku każdego z tych narzędzi należy zapoznać się z załącznikiem, który zawiera instrukcje dotyczące ich instalacji.
2.4. Strony internetowe statyczne, strony internetowe dynamiczne
Strona statyczna jest reprezentowana przez plik HTML. Strona dynamiczna jest natomiast generowana „na bieżąco” przez serwer WWW. W niniejszym akapicie proponujemy różne testy z wykorzystaniem różnych serwerów internetowych i różnych języków programowania, aby pokazać uniwersalność koncepcji internetowej. Wykorzystamy dwa serwery internetowe o nazwach Apache i IIS. Chociaż IIS jest produktem komercyjnym, dostępny jest on również w dwóch bardziej ograniczonych, ale bezpłatnych wersjach:
- PWS dla komputerów z systemem Win9x
- Cassini dla komputerów z systemem Windows 200 oraz XP
Katalog <IIS-DocumentRoot> to zazwyczaj katalog [lecteur:\inetpub\wwwroot], gdzie [lecteur] oznacza dysk (C, D, ...), na którym zainstalowano IIS. To samo dotyczy programu PWS. W przypadku serwera Cassini lokalizacja katalogu <IIS-DocumentRoot> zależy od sposobu uruchomienia serwera. W załączniku pokazano, że serwer Cassini można uruchomić w oknie DOS (lub za pomocą skrótu) w następujący sposób:
Aplikacja [WebServer], zwana również serwerem internetowym Cassini, obsługuje trzy parametry:
- /port: numer portu usługi internetowej. Może to być dowolna wartość. Domyślnie jest to 80
- /path: fizyczna ścieżka do folderu na dysku
- /vpath: folder wirtualny powiązany z poprzednim folderem fizycznym. Należy zwrócić uwagę, że składnia nie brzmi /path=ścieżka, ale /vpath:ścieżka, w przeciwieństwie do tego, co podano w powyższym oknie pomocy.
Jeśli Cassini zostanie uruchomione w następujący sposób:
, wówczas folder P stanowi katalog główny drzewa katalogów serwera Cassini. Jest to zatem folder, na który wskazuje <IIS-DocumentRoot>. Tak więc w poniższym przykładzie:
serwer Cassini będzie działał na porcie 80, a katalogiem głównym jego drzewa <IIS-DocumentRoot> jest folder [d:\data\devel\webmatrix]. Testowane strony internetowe muszą znajdować się w tym katalogu głównym.
W dalszej części każda aplikacja internetowa będzie reprezentowana przez pojedynczy plik, który można utworzyć za pomocą dowolnego edytora tekstowego. Nie jest wymagany żaden plik o nazwie IDE.
2.4.1. Strona statyczna HTML (język znaczników HyperText)
Rozważmy następujący kod HTML:
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
co generuje następującą stronę internetową:
Testy
Test1
- uruchom serwer Apache
- umieścić skrypt essai1.html w <apache-DocumentRoot>
- wyświetlić stronę URL http://localhost/essai1.html w przeglądarce
- zatrzymaj serwer Apache
Test2
- uruchom serwer IIS/PWS/Cassini
- umieścić skrypt essai1.html w <IIS-DocumentRoot>
- wyświetlić stronę URL http://localhost/essai1.html w przeglądarce
2.4.2. Strona ASP (Active Server Pages)
Skrypt essai2.asp:
<html>
<head>
<title>essai 1 : une page asp</title>
</head>
<body>
<center>
<h1>Une page asp générée dynamiquement par le serveur PWS</h1>
<h2>Il est <% =time %></h2>
<br>
A chaque fois que vous rafraîchissez la page, l'heure change.
</body>
</html>
generuje następującą stronę internetową:
Test
- uruchom serwer IIS/PWS
- umieścić skrypt essai2.asp w <IIS-DocumentRoot>
- wywołaj adres URL http://localhost/essai2.asp w przeglądarce
2.4.3. Skrypt PERL (Practical Extracting and Reporting Language)
Skrypt essai3.pl:
#!d:\perl\bin\perl.exe
($secondes,$minutes,$heure)=localtime(time);
print <<HTML
Content-type: text/html
<html>
<head>
<title>essai 1 : un script Perl</title>
</head>
<body>
<center>
<h1>Une page générée dynamiquement par un script Perl</h1>
<h2>Il est $heure:$minutes:$secondes</h2>
<br>
A chaque fois que vous rafraîchissez la page, l'heure change.
</body>
</html>
HTML
;
Pierwszy wiersz to ścieżka do pliku wykonywalnego perl.exe. W razie potrzeby należy ją dostosować. Po uruchomieniu przez serwer WWW skrypt generuje następującą stronę:
Test
- serwera WWW: Apache
- dla informacji, należy przejrzeć plik konfiguracyjny srm.conf lub httpd.conf, w zależności od wersji Apache'a, znajdujący się w katalogu <apache>\confs i odszukaj wiersz dotyczący cgi-bin, aby poznać katalog <apache-cgi-bin>, w którym należy umieścić plik essai3.pl.
- Umieść skrypt essai3.pl w katalogu <apache-cgi-bin>
- wywołaj adres URL http://localhost/cgi-bin/essai3.pl
Należy zauważyć, że wyświetlenie strony perl zajmuje więcej czasu niż strony asp. Wynika to z faktu, że skrypt Perl jest wykonywany przez interpreter języka Perl, który musi zostać załadowany, zanim będzie mógł wykonać skrypt. Nie pozostaje on na stałe w pamięci.
2.4.4. Skrypt PHP (procesor HyperText)
Skrypt essai4.php
<html>
<head>
<title>essai 4 : une page php</title>
</head>
<body>
<center>
<h1>Une page PHP générée dynamiquement</h1>
<h2>
<?
$maintenant=time();
echo date("j/m/y, h:i:s",$maintenant);
?>
</h2>
<br>
A chaque fois que vous rafraîchissez la page, l'heure change.
</body>
</html>
Powyższy skrypt generuje następującą stronę internetową:
Testy
Test1
- zapoznaj się z plikiem konfiguracyjnym srm.conf lub httpd.conf serwera Apache w <Apache>\confs
- dla informacji sprawdź wiersze konfiguracyjne pliku php
- uruchom serwer Apache
- umieścić plik essai4.php w pliku <apache-DocumentRoot>
- wywołaj plik URL http://localhost/essai4.php
Test2
- uruchom serwer IIS/PWS
- dla informacji, sprawdź konfigurację PWS dotyczącą php
- umieścić essai4.php w <IIS-DocumentRoot>\php
- wywołać URL http://localhost/essai4.php
2.4.5. Skrypt JSP (Java Server Pages)
Skrypt heure.jsp
<% //– program w Javie wyświetlający godzinę %>
<%@ page import="java.util.*" %>
<%
// kod JAVA do obliczania godziny
Calendar calendrier=Calendar.getInstance();
int heures=calendrier.get(Calendar.HOUR_OF_DAY);
int minutes=calendrier.get(Calendar.MINUTE);
int secondes=calendrier.get(Calendar.SECOND);
// godziny, minuty i sekundy są zmiennymi globalnymi
//, które będą mogły być wykorzystane w kodzie HTML
%>
<% // kod HTML %>
<html>
<head>
<title>Page JSP affichant l'heure</title>
</head>
<body>
<center>
<h1>Une page JSP générée dynamiquement</h1>
<h2>Il est <%=heures%>:<%=minutes%>:<%=secondes%></h2>
<br>
<h3>A chaque fois que vous rechargez la page, l'heure change</h3>
</body>
</html>
Po uruchomieniu przez serwer WWW skrypt ten generuje następującą stronę:
Testy
- umieścić skrypt heure.jsp w katalogu <tomcat>\jakarta-tomcat\webapps\examples\jsp (Tomcat 3.x) lub w katalogu <tomcat>\webapps\examples\jsp (Tomcat 4.x)
- uruchomić serwer Tomcat
- wywołać stronę URL pod adresem http://localhost:8080/examples/jsp/heure.jsp
2.4.6. Strona ASP.NET
Skrypt heure1.aspx:
<html>
<head>
<title>Démo asp.net </title>
</head>
<body>
Il est <% =Date.Now.ToString("hh:mm:ss") %>
</body>
</html>
Po uruchomieniu przez serwer WWW skrypt ten generuje następującą stronę:
Do przeprowadzenia tego testu potrzebny jest komputer z systemem Windows, na którym zainstalowano platformę .NET (patrz załącznik).
- Umieścić skrypt heure1.aspx w <IIS-DocumentRoot>
- uruchomić serwer IIS/CASSINI
- wywołać URL http://localhost/heure1.aspx
2.4.7. Wnioski
Powyższe przykłady pokazały, że:
- strona HTML może być generowana dynamicznie przez program. Na tym właśnie polega programowanie internetowe.
- że wykorzystywane języki i serwery internetowe mogą być zróżnicowane. Obecnie obserwuje się następujące główne trendy:
- kombinacje Apache/PHP (Windows, Linux) oraz IIS/PHP (Windows)
- technologia ASP.NET na platformach Windows, łącząca serwer IIS z językiem .NET (C#, VB.NET, ...)
- technologia serwletów Java i stron JSP działająca z różnymi serwerami (Tomcat, Apache, IIS) oraz na różnych platformach (Windows, Linux).
2.5. Skrypty po stronie przeglądarki
Strona HTML może zawierać skrypty, które będą wykonywane przez przeglądarkę. Istnieje wiele języków skryptowych po stronie przeglądarki. Oto kilka z nich:
Język | Obsługiwane przeglądarki |
VBScript | IE |
JavaScript | IE, Netscape |
PerlScript | IE |
Java | IE, Netscape |
Rozważmy kilka przykładów.
2.5.1. Strona internetowa ze skryptem VBScript po stronie przeglądarki
Strona vbs1.html
<html>
<head>
<title>essai : une page web avec un script vb</title>
<script language="vbscript">
function reagir
alert "Vous avez cliqué sur le bouton OK"
end function
</script>
</head>
<body>
<center>
<h1>Une page Web avec un script VB</h1>
<table>
<tr>
<td>Cliquez sur le bouton</td>
<td><input type="button" value="OK" name="cmdOK" onclick="reagir"></td>
</tr>
</table>
</body>
</html>
Powyższa strona HTML zawiera nie tylko kod HTML, ale również program przeznaczony do wykonania przez przeglądarkę, która załaduje tę stronę. Kod wygląda następująco:
<script language="vbscript">
function reagir
alert "Vous avez cliqué sur le bouton OK"
end function
</script>
Tagi <script></script> służą do wyodrębniania skryptów na stronie HTML. Skrypty te mogą być napisane w różnych językach, a to opcja language w tagu <script> określa używany język. W tym przypadku jest to VBScript. Nie będziemy się tutaj zagłębiać w szczegóły tego języka. Powyższy skrypt definiuje funkcję o nazwie réagir, która wyświetla komunikat. Kiedy ta funkcja jest wywoływana? Wskazuje nam to następujący wiersz kodu HTML:
Atrybut onclick określa nazwę funkcji, która ma zostać wywołana, gdy użytkownik kliknie przycisk OK. Gdy przeglądarka załaduje tę stronę, a użytkownik kliknie przycisk OK, pojawi się następująca strona:
Testy
Tylko przeglądarka IE jest w stanie wykonywać skrypty VBScript. Przeglądarka Netscape wymaga do tego dodatkowych wtyczek. Można przeprowadzić następujące testy:
- serwer Apache
- skrypt vbs1.html w <apache-DocumentRoot>
-
wywołanie adresu URL http://localhost/vbs1.html za pomocą przeglądarki IE
-
serwer IIS/PWS
- skrypt vbs1.html w <pws-DocumentRoot>
- wywołanie adresu URL http://localhost/vbs1.html za pomocą przeglądarki IE
Strona internetowa ze skryptem JavaScript po stronie przeglądarki
La page : js1.html
<html>
<head>
<title>essai 4 : une page web avec un script Javascript</title>
<script language="javascript">
function reagir(){
alert ("Vous avez cliqué sur le bouton OK");
}
</script>
</head>
<body>
<center>
<h1>Une page Web avec un script Javascript</h1>
<table>
<tr>
<td>Cliquez sur le bouton</td>
<td><input type="button" value="OK" name="cmdOK" onclick="reagir()"></td>
</tr>
</table>
</body>
</html>
Mamy tu coś identycznego jak na poprzedniej stronie, z tą różnicą, że język VBScript został zastąpiony językiem JavaScript. Ma on tę zaletę, że jest obsługiwany zarówno przez przeglądarkę IE, jak i Netscape. Jego wykonanie daje te same wyniki:
Testy
- serwer Apache
- skrypt js1.html w <apache-DocumentRoot>
-
wywołaj adres URL http://localhost/js1.html za pomocą przeglądarki IE lub Netscape
-
serwer IIS/PWS
- skrypt js1.html w <pws-DocumentRoot>
- wywołaj adres URL http://localhost/js1.html za pomocą przeglądarki IE lub Netscape
2.6. Komunikacja klient-serwer
Wróćmy do naszego początkowego schematu, który ilustrował elementy składowe aplikacji internetowej:
Serwer
W tym miejscu skupiamy się na komunikacji między komputerem klienckim a serwerem. Odbywa się ona za pośrednictwem sieci i warto przypomnieć ogólną strukturę komunikacji między dwoma odległymi komputerami.
2.6.1. Model OSI
Model otwartej sieci o nazwie OSI (Open Systems Interconnection Reference Model), zdefiniowany przez ISO (Międzynarodową Organizację Normalizacyjną), opisuje idealną sieć, w której komunikację między komputerami można przedstawić za pomocą modelu siedmiowarstwowego:
Każda warstwa korzysta z usług warstwy niższej i udostępnia swoje usługi warstwie wyższej. Załóżmy, że dwie aplikacje znajdujące się na różnych maszynach A i B chcą się komunikować: robią to na poziomie warstwy Application. Nie muszą one znać wszystkich szczegółów działania sieci: każda aplikacja przekazuje informacje, które chce przesłać, do warstwy poniżej – warstwy Présentation. Aplikacja musi zatem znać jedynie zasady współpracy z warstwą Présentation. Gdy informacja znajdzie się w warstwie Présentation, jest przekazywana zgodnie z innymi regułami do warstwy Session i tak dalej, aż informacja dotrze do nośnika fizycznego i zostanie fizycznie przesłana do komputera docelowego. Tam zostanie poddana procesowi odwrotnemu do tego, który miała miejsce na komputerze nadawczym.
Na każdej warstwie proces nadawczy odpowiedzialny za wysyłanie informacji przekazuje ją do procesu odbiorczego na innym komputerze należącym do tej samej warstwy. Odbywa się to zgodnie z określonymi zasadami, zwanymi protokołem warstwy. Otrzymujemy zatem następujący ostateczny schemat komunikacji:
Rola poszczególnych warstw jest następująca:
Zapewnia transmisję bitów na nośniku fizycznym. W tej warstwie znajdują się urządzenia końcowe do przetwarzania danych (E.T.T.D.), takie jak terminal lub komputer, a także urządzenia końcowe obwodów danych (E.T.C.D.), takie jak modulator/demodulator, multiplekser, koncentrator. Istotne elementy na tym poziomie to: . wybór sposobu kodowania informacji (analogowego lub cyfrowego) . wybór trybu transmisji (synchroniczny lub asynchroniczny). | |
Ukrywa specyfikę warstwy fizycznej. Wykrywa i koryguje błędy transmisji. | |
Zarządza ścieżką, którą muszą podążać informacje wysyłane w sieci. Nazywa się to routage: określenie trasy, którą musi podążać informacja, aby dotarła do odbiorcy. | |
Umożliwia komunikację między dwiema aplikacjami, podczas gdy poprzednie warstwy pozwalały jedynie na komunikację między maszynami. Usługą świadczoną przez tę warstwę może być multipleksowanie: warstwa transportowa może wykorzystywać to samo połączenie sieciowe (między maszynami) do przesyłania informacji należących do kilku aplikacji. | |
W tej warstwie znajdują się usługi umożliwiające aplikacji otwarcie i utrzymanie sesji roboczej na zdalnym komputerze. | |
Ma ona na celu ujednolicenie sposobu przedstawiania danych na różnych komputerach. W ten sposób dane pochodzące z komputera A zostaną „opracowane” przez warstwę Présentation komputera A zgodnie ze standardowym formatem, zanim zostaną wysłane do sieci. Po dotarciu do warstwy Présentation komputera docelowego B, który rozpozna je dzięki standardowemu formatowi, zostaną one przetworzone w inny sposób, aby aplikacja komputera B mogła je rozpoznać. | |
Na tym poziomie znajdują się aplikacje zazwyczaj bliskie użytkownikowi, takie jak poczta elektroniczna czy przesyłanie plików. |
2.6.2. Model TCP/IP
Model OSI jest modelem idealnym. Zestaw protokołów TCP/IP zbliża się do niego w następującej postaci:
- interfejs sieciowy (karta sieciowa komputera) pełni funkcje warstw 1 i 2 modelu OSI
- warstwa IP (Internet Protocol) pełni funkcje warstwy 3 (sieć)
- warstwa TCP (Transfer Control Protocol) lub UDP (User Datagram Protocol) pełni funkcje warstwy 4 (transportowej). Protokół TCP zapewnia, że pakiety danych wymieniane między urządzeniami dotrą do miejsca przeznaczenia. Jeśli tak się nie stanie, odsyła zagubione pakiety. Protokół UDP nie wykonuje tej czynności, a zadanie to spoczywa na programiście aplikacji. Dlatego w Internecie, który nie jest siecią w 100% niezawodną, najczęściej stosowany jest protokół TCP. Mówimy wówczas o sieci TCP-IP.
- Warstwa aplikacji obejmuje funkcje poziomów od 5 do 7 modelu OSI.
Aplikacje internetowe znajdują się w warstwie Application i opierają się zatem na protokołach TCP-IP. Warstwy Application na komputerach klienckich i serwerze wymieniają między sobą komunikaty, które są przekazywane warstwom od 1 do 4 modelu w celu dostarczenia do miejsca przeznaczenia. Aby się porozumieć, warstwy aplikacji obu komputerów muszą „mówić” tym samym językiem lub protokołem. Protokół aplikacji internetowych nosi nazwę HTTP (HyperText Transfer Protocol). Jest to protokół tekstowy, c.a.d, dzięki któremu urządzenia wymieniają między sobą wiersze tekstu w sieci, aby się porozumieć. Wymiana ta jest znormalizowana, co oznacza, że klient dysponuje pewną liczbą komunikatów, aby dokładnie wskazać serwerowi, czego oczekuje, a serwer również dysponuje pewną liczbą komunikatów, aby udzielić klientowi odpowiedzi. Ta wymiana komunikatów ma następującą postać:
Klient --> Serwer
Gdy klient wysyła żądanie do serwera WWW, przesyła
- wiersze tekstu w formacie HTTP, aby wskazać, czego oczekuje
- pustą linię
- opcjonalnie dokument
Serwer --> Klient
Gdy serwer wysyła odpowiedź do klienta, przesyła
- wiersze tekstu w formacie HTTP, aby wskazać, co wysyła
- pusty wiersz
- opcjonalnie dokument
Wymiana danych ma zatem tę samą formę w obu kierunkach. W obu przypadkach może nastąpić wysłanie dokumentu, nawet jeśli rzadko zdarza się, by klient wysyłał dokument do serwera. Jednak protokół HTTP to przewiduje. To właśnie pozwala na przykład abonentom dostawcy usług internetowych na pobieranie różnych dokumentów na swoją stronę osobistą hostowaną u tego dostawcy. Wymieniane dokumenty mogą być dowolne. Weźmy na przykład przeglądarkę żądającą strony internetowej zawierającej obrazy:
- przeglądarka łączy się z serwerem internetowym i żąda żądanej strony. Żądane zasoby są jednoznacznie identyfikowane za pomocą URL (Uniform Resource Locator). Przeglądarka wysyła jedynie nagłówki HTTP, a nie sam dokument.
- Serwer odpowiada na to żądanie. Najpierw wysyła nagłówki HTTP, wskazujące, jaki typ odpowiedzi wysyła. Może to być komunikat o błędzie, jeśli żądana strona nie istnieje. Jeśli strona istnieje, serwer poinformuje w nagłówkach HTTP swojej odpowiedzi, że po nich wyśle dokument HTML (HyperText Markup Language). Dokument ten stanowi ciąg wierszy tekstu w formacie HTML. Tekst HTML zawiera znaczniki (tagi), które dostarczają przeglądarce wskazówek dotyczących sposobu wyświetlania tekstu.
- Klient na podstawie nagłówków HTTP serwera wie, że otrzyma dokument HTML. Przeanalizuje go i być może zauważy, że zawiera odniesienia do obrazów. Obrazy te nie znajdują się w dokumencie HTML. W związku z tym wysyła nowe żądanie do tego samego serwera WWW, prosząc o pierwszy potrzebny mu obraz. Żądanie to jest identyczne z tym wysłanym w punkcie 1, z tą różnicą, że żądany zasób jest inny. Serwer przetworzy to żądanie, wysyłając klientowi żądany obraz. Tym razem w odpowiedzi nagłówki HTTP będą wskazywać, że wysłany plik to obraz, a nie dokument HTML.
- Klient pobiera przesłany obraz. Etapy 3 i 4 będą powtarzane, dopóki klient (zazwyczaj przeglądarka) nie otrzyma wszystkich dokumentów umożliwiających wyświetlenie całej strony.
2.6.3. Protokół HTTP
Przyjrzyjmy się protokołowi HTTP na przykładach. Jakie dane wymieniają między sobą przeglądarka i serwer WWW?
2.6.3.1. Odpowiedź serwera HTTP
Zobaczymy tutaj, w jaki sposób serwer internetowy odpowiada na żądania swoich klientów. Serwis internetowy lub serwis HTTP to serwis TCP-IP, który zazwyczaj działa na porcie 80. Może jednak działać na innym porcie. W takim przypadku przeglądarka klienta musiałaby podać ten port w żądaniu URL. Żądanie URL ma ogólną postać:
z
protokołu | http dla serwisu internetowego. Przeglądarka może również pełnić rolę klienta usług ftp, news, telnet itp. |
komputer | nazwa komputera, na którym działa usługa internetowa |
port | port serwisu internetowego. Jeśli jest to 80, można pominąć numer portu. Jest to najczęstszy przypadek |
ścieżka | ścieżka wskazująca żądany zasób |
informacje | dodatkowe informacje przekazywane serwerowi w celu doprecyzowania żądania klienta |
Co robi przeglądarka, gdy użytkownik żąda załadowania pliku URL?
- Nawiązuje połączenie TCP-IP z komputerem i portem wskazanymi w sekcji machine[:port] pliku URL. Nawiązanie połączenia TCP-IP oznacza utworzenie „kanału” komunikacyjnego między dwoma maszynami. Po utworzeniu tego kanału wszystkie informacje wymieniane między tymi maszynami będą przez niego przepływać. Utworzenie tego kanału TCP-IP nie wiąże się jeszcze z wykorzystaniem protokołu internetowego HTTP.
- Po utworzeniu kanału TCP-IP klient wyśle żądanie do serwera internetowego, wysyłając mu wiersze tekstu (polecenia) w formacie HTTP. Wyśle on do serwera część ścieżki/informacji z URL
- serwer odpowie w ten sam sposób i w tym samym kanale
- jeden z partnerów podejmie decyzję o zamknięciu kanału. Zależy to od używanego protokołu HTTP. W przypadku protokołu HTTP 1.0 serwer zamyka połączenie po każdej swojej odpowiedzi. Zmusza to klienta, który musi wysłać kilka żądań w celu uzyskania różnych dokumentów tworzących stronę internetową, do nawiązywania nowego połączenia przy każdym żądaniu, co wiąże się z pewnymi kosztami. W przypadku protokołu HTTP/1.1 klient może poinstruować serwer, aby utrzymywał połączenie otwarte do momentu, aż klient poleci jego zamknięcie. Dzięki temu może pobrać wszystkie dokumenty strony internetowej za pomocą jednego połączenia i samodzielnie zamknąć je po otrzymaniu ostatniego dokumentu. Serwer wykryje to zamknięcie i również zamknie połączenie.
Aby zapoznać się z wymianą danych między klientem a serwerem internetowym, wykorzystamy narzędzie o nazwie curl. Curl to aplikacja DOS umożliwiająca korzystanie z usług internetowych obsługujących różne protokoły (HTTP, FTP, TELNET, GOPHER, ...). curl jest dostępny na stronie http://curl.haxx.se/. Najlepiej pobrać tutaj wersję dla systemu Windows win32-nossl, ponieważ wersja win32-ssl wymaga dodatkowych bibliotek DLL, które nie są zawarte w pakiecie curl. Pakiet ten zawiera zestaw plików, które wystarczy rozpakować do folderu, który od tej pory będziemy nazywać <curl>. Folder ten zawiera plik wykonywalny o nazwie [curl.exe]. Będzie to nasz klient do wysyłania zapytań do serwerów WWW. Otwórzmy okno wiersza poleceń i przejdźmy do folderu <curl>:
dos>dir curl.exe
22/03/2004 13:29 299 008 curl.exe
E:\curl2>curl
curl: try 'curl --help' for more information
dos>curl --help | more
Usage: curl [options...] <url>
Options: (H) means HTTP/HTTPS only, (F) means FTP only
-a/--append Append to target file when uploading (F)
-A/--user-agent <string> User-Agent to send to server (H)
--anyauth Tell curl to choose authentication method (H)
-b/--cookie <name=string/file> Cookie string or file to read cookies from (H)
--basic Enable HTTP Basic Authentication (H)
-B/--use-ascii Use ASCII/text transfer
-c/--cookie-jar <file> Write cookies to this file after operation (H)
....
Wykorzystajmy tę aplikację do wysłania zapytania do serwera WWW i prześledzenia wymiany danych między klientem a serwerem. Znajdziemy się w następującej sytuacji:
Serwer WWW może być dowolny. Chcemy tutaj prześledzić komunikację, która będzie miała miejsce między klientem WWW curl a serwerem WWW. Wcześniej utworzyliśmy następującą statyczną stronę HTML:
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
które wyświetlamy w przeglądarce:
Widać, że żądany adres URL to: http://localhost/aspnet/chap1/statique1.html. Serwer usługi internetowej to zatem localhost (=serwer lokalny), a port to 80. Jeśli poprosimy o wyświetlenie tekstu HTML tej strony internetowej (Widok/Źródło), znajdziemy tekst HTML utworzony początkowo:
Teraz użyjmy naszego klienta CURL, aby zażądać tego samego URL:
dos>curl http://localhost/aspnet/chap1/statique1.html
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
Widzimy, że serwer WWW wysłał mu zestaw wierszy tekstu, który stanowi kod HTML żądanej strony. Jak wspomnieliśmy wcześniej, odpowiedź serwera WWW ma postać:
Jednak w tym przypadku nie widzieliśmy nagłówków HTTP. Wynika to z faktu, że [curl] domyślnie ich nie wyświetla. Opcja --include pozwala je wyświetlić:
E:\curl2>curl --include http://localhost/aspnet/rozdz1/statique1.html
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Mon, 22 Mar 2004 16:51:00 GMT
X-AspNet-Version: 1.1.4322
Cache-Control: public
ETag: "1C4102CEE8C6400:1C4102CFBBE2250"
Content-Type: text/html
Content-Length: 161
Connection: Close
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
Serwer rzeczywiście wysłał serię nagłówków HTTP, po których następował pusty wiersz:
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Mon, 22 Mar 2004 16:51:00 GMT
X-AspNet-Version: 1.1.4322
Cache-Control: public
ETag: "1C4102CEE8C6400:1C4102CFBBE2250"
Content-Type: text/html
Content-Length: 161
Connection: Close
serwer informuje,
| |
serwer podaje swoje dane identyfikacyjne. W tym przypadku jest to serwer Cassini | |
data i godzina odpowiedzi | |
nagłówek charakterystyczny dla serwera Cassini | |
informuje klienta o możliwości buforowania wysłanej do niego odpowiedzi. Atrybut [public] wskazuje klientowi, że może buforować stronę. Atrybut [no-cache] wskazywałby klientowi, że nie powinien buforować strony. | |
... | |
serwer informuje, że wyśle tekst (text) w formacie HTML (html). | |
liczba bajtów dokumentu, który zostanie wysłany po nagłówkach HTTP. Liczba ta odpowiada w rzeczywistości rozmiarowi w bajtach pliku essai1.html: | |
serwer informuje, że zamknie połączenie po wysłaniu dokumentu |
Klient odbiera nagłówki HTTP i wie już, że otrzyma 161 bajtów reprezentujących dokument HTML. Serwer wysyła te 161 bajtów bezpośrednio po pustej linii, która sygnalizowała koniec nagłówków HTTP:
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
Rozpoznajemy tu plik HTML utworzony na początku. Gdyby naszym klientem była przeglądarka, po odebraniu tych wierszy tekstu zinterpretowałaby je, aby wyświetlić użytkownikowi korzystającemu z klawiatury następującą stronę:
Wykorzystajmy ponownie naszego klienta [curl], aby zażądać tego samego zasobu, ale tym razem prosząc wyłącznie o nagłówki odpowiedzi:
dos>curl --head http://localhost/aspnet/chap1/statique1.html
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Tue, 23 Mar 2004 07:11:54 GMT
Cache-Control: public
ETag: "1C410A504D60680:1C410A58621AD3E"
Content-Type: text/html
Content-Length: 161
Connection: Close
Otrzymujemy ten sam wynik co poprzednio, bez dokumentu HTML. Teraz wywołajmy obraz zarówno za pomocą przeglądarki, jak i generycznego klienta TCP. Najpierw za pomocą przeglądarki:
Plik univ01.gif ma 4052 bajtów:
Teraz skorzystajmy z klienta [curl]:
dos>curl --head http://localhost/aspnet/chap1/univ01.gif
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Tue, 23 Mar 2004 07:18:44 GMT
Cache-Control: public
ETag: "1C410A6795D7500:1C410A6868B1476"
Content-Type: image/gif
Content-Length: 4052
Connection: Close
W powyższym cyklu zapytanie–odpowiedź należy zwrócić uwagę na następujące kwestie:
| |
| |
|
2.6.3.2. Żądanie klienta HTTP
Zadajmy sobie teraz następujące pytanie: jeśli chcemy napisać program, który „komunikuje się” z serwerem WWW, jakie polecenia musi on wysłać do serwera, aby uzyskać określony zasób? W poprzednich przykładach widzieliśmy, co otrzymywał klient, ale nie to, co wysyłał. Wykorzystamy opcję [--verbose] programu curl, aby sprawdzić również, co klient wysyła do serwera. Zacznijmy od wywołania strony statycznej:
dos>curl --verbose http://localhost/aspnet/chap1/statique1.html
* About to connect() to localhost:80
* Connected to portable1_tahe (127.0.0.1) port 80
> GET /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
< HTTP/1.1 200 OK
< Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
< Date: Tue, 23 Mar 2004 07:37:06 GMT
< Cache-Control: public
< ETag: "1C410A504D60680:1C410A58621AD3E"
< Content-Type: text/html
< Content-Length: 161
< Connection: Close
<html>
<head>
<title>essai 1 : une page statique</title>
</head>
<body>
<center>
<h1>Une page statique...</h1>
</body>
</html>
* Closing connection #0
Najpierw klient [curl] nawiązuje połączenie TCP/IP z portem 80 na komputerze localhost (=127.0.0.1)
Po nawiązaniu połączenia wysyła swoje żądanie HTTP. Jest to ciąg wierszy tekstu zakończony pustym wierszem:
GET /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Żądanie HTTP wysłane przez klienta internetowego pełni dwie funkcje:
- wskazanie żądanego zasobu. Tę rolę pełni tutaj pierwszy wiersz GET
- przekazanie informacji o kliencie wysyłającym żądanie, aby serwer mógł ewentualnie dostosować swoją odpowiedź do tego konkretnego typu klienta.
Znaczenie wierszy wysłanych powyżej przez klienta [curl] jest następujące:
w celu zażądania określonego zasobu zgodnie z określoną wersją protokołu HTTP. Serwer wysyła odpowiedź w formacie HTTP, po której następuje pusty wiersz, a następnie żądany zasób | |
w celu wskazania, kim jest klient | |
w celu określenia (protokół HTTP 1.1) komputera i portu zapytanego serwera WWW | |
tutaj w celu określenia, że klient nie obsługuje pamięci podręcznej. | |
typy MIME określające typy plików, które klient potrafi obsłużyć |
Powtórzmy operację z opcją --head programu [curl]:
dos>curl --verbose --head --output reponse.txt http://localhost/aspnet/chap1/statique1.html
* About to connect() to localhost:80
* Connected to portable1_tahe (127.0.0.1) port 80
> HEAD /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
< HTTP/1.1 200 OK
< Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
< Date: Tue, 23 Mar 2004 07:54:22 GMT
< Cache-Control: public
< ETag: "1C410A504D60680:1C410A58621AD3E"
< Content-Type: text/html
< Content-Length: 161
< Connection: Close
Skupiamy się wyłącznie na nagłówkach HTTP przesłanych przez klienta:
HEAD /aspnet/chap1/statique1.html HTTP/1.1
User-Agent: curl/7.10.8 (win32) libcurl/7.10.8 OpenSSL/0.9.7a zlib/1.1.4
Host: localhost
Pragma: no-cache
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Zmieniło się jedynie polecenie żądające zasobu. Zamiast polecenia GET mamy teraz polecenie HEAD. Polecenie to nakazuje, aby odpowiedź serwera ograniczała się do nagłówków HTTP i aby serwer nie wysyłał żądanego zasobu. Powyższy zrzut ekranu nie pokazuje otrzymanych nagłówków HTTP. Zostały one zapisane w pliku dzięki opcji [--output reponse.txt] zawartej w poleceniu [curl]:
dos>more reponse.txt
HTTP/1.1 200 OK
Server: Microsoft ASP.NET Web Matrix Server/0.6.0.0
Date: Tue, 23 Mar 2004 07:54:22 GMT
Cache-Control: public
ETag: "1C410A504D60680:1C410A58621AD3E"
Content-Type: text/html
Content-Length: 161
Connection: Close
2.6.4. Wnioski
Na podstawie kilku przykładów zapoznaliśmy się ze strukturą żądania wysyłanego przez klienta sieciowego oraz odpowiedzi udzielanej mu przez serwer sieciowy. Komunikacja odbywa się za pomocą protokołu HTTP, czyli zestawu poleceń w formacie tekstowym wymienianych między obiema stronami. Żądanie klienta i odpowiedź serwera mają tę samą strukturę:
W przypadku żądania (często nazywanego zapytaniem) wysyłanego przez klienta część [Document] zazwyczaj nie występuje. Niemniej jednak klient może wysłać dokument do serwera. Czyni to za pomocą polecenia o nazwie PUT. Dwa typowe polecenia służące do żądania zasobu to GET i POST. To ostatnie zostanie omówione nieco później. Polecenie HEAD pozwala na żądanie wyłącznie nagłówków HTTP. Polecenia GET i POST są najczęściej używane przez przeglądarkowe klienty internetowe.
Na żądanie klienta serwer wysyła odpowiedź o tej samej strukturze. Żądany zasób jest przekazywany w części [Document], chyba że polecenie klienta brzmiało HEAD – w takim przypadku wysyłane są wyłącznie nagłówki HTTP.
2.7. Język HTML
Przeglądarka internetowa może wyświetlać różne dokumenty, z których najpopularniejszym jest dokument HTML (HyperText Markup Language). Jest to tekst sformatowany za pomocą znaczników o postaci <balise>texte</balise>. Na przykład tekst <B>important</B> wyświetli ważny tekst pogrubioną czcionką. Istnieją również pojedyncze znaczniki, takie jak znacznik <hr>, który wyświetla poziomą linię. Nie będziemy omawiać znaczników, które można znaleźć w tekście HTML. Istnieje wiele programów WYSIWYG, które pozwalają na stworzenie strony internetowej bez pisania ani jednej linii kodu HTML. Narzędzia te automatycznie generują kod HTML na podstawie układu strony utworzonego za pomocą myszki i gotowych elementów sterujących. Można więc wstawić (za pomocą myszki) do strony tabelę, a następnie przejrzeć kod HTML wygenerowany przez oprogramowanie, aby dowiedzieć się, jakich tagów należy użyć do zdefiniowania tabeli na stronie internetowej. To naprawdę nie jest skomplikowane. Ponadto znajomość języka HTML jest niezbędna, ponieważ dynamiczne aplikacje internetowe muszą samodzielnie generować kod HTML, który ma zostać wysłany do klientów internetowych. Kod ten jest generowany programowo i oczywiście trzeba wiedzieć, co należy wygenerować, aby klient otrzymał stronę internetową, której oczekuje.
Podsumowując, nie ma potrzeby znajomości całego języka HTML, aby rozpocząć programowanie internetowe. Jednak znajomość ta jest niezbędna i można ją zdobyć poprzez korzystanie z oprogramowania do tworzenia stron internetowych, takiego jak Word, FrontPage, DreamWeaver i dziesiątek innych. Innym sposobem na poznanie subtelności języka HTML jest przeglądanie sieci i wyświetlanie kodu źródłowego stron, które zawierają interesujące i jeszcze nieznane Ci funkcje.
2.7.1. Przykład
Rozważmy następujący przykład, utworzony za pomocą FrontPage Express, bezpłatnego narzędzia dołączonego do przeglądarki Internet Explorer. Kod wygenerowany przez FrontPage został tutaj uproszczony. Przykład ten przedstawia kilka elementów, które można znaleźć w dokumencie internetowym, takich jak:
- tabela
- obraz
- link
Dokument HTML ma ogólną postać:
Cały dokument jest ujęty w tagi <html>...</html>. Składa się on z dwóch części:
- <head>...</head>: jest to niewidoczna część dokumentu. Zawiera informacje dla przeglądarki, która wyświetli dokument. Często znajduje się tam tag <title>...</title>, który określa tekst wyświetlany w pasku tytułu przeglądarki. Można tam również znaleźć inne tagi, w szczególności te definiujące słowa kluczowe dokumentu, wykorzystywane następnie przez wyszukiwarki. W tej części można również znaleźć skrypty, najczęściej napisane w języku JavaScript lub VBScript, które zostaną wykonane przez przeglądarkę.
- <body atrybuty>...</body>: jest to część, która zostanie wyświetlona przez przeglądarkę. Tagi zawarte w tej części wskazują przeglądarce „pożądany” wygląd dokumentu. Każda przeglądarka interpretuje te tagi na swój sposób. W związku z tym dwie przeglądarki mogą wyświetlać ten sam dokument internetowy w różny sposób. Jest to zazwyczaj jeden z problemów, z którymi borykają się projektanci stron internetowych.
Kod HTML naszego przykładowego dokumentu wygląda następująco:
<html>
<head>
<title>balises</title>
</head>
<body background="/images/standard.jpg">
<center>
<h1>Les balises HTML</h1>
<hr>
</center>
<table border="1">
<tr>
<td>cellule(1,1)</td>
<td valign="middle" align="center" width="150">cellule(1,2)</td>
<td>cellule(1,3)</td>
</tr>
<tr>
<td>cellule(2,1)</td>
<td>cellule(2,2)</td>
<td>cellule(2,3</td>
</tr>
</table>
<table border="0">
<tr>
<td>Une image</td>
<td><img border="0" src="/images/univ01.gif" width="80" height="95"></td>
</tr>
<tr>
<td>le site de l'ISTIA</td>
<td><a href="http://istia.univ-angers.fr">ici</a></td>
</tr>
</table>
</body>
</html>
W kodzie zaznaczono wyłącznie te elementy, które nas interesują:
Element | tagi i przykłady HTML |
<title>balises</title> balises pojawi się w pasku tytułu przeglądarki wyświetlającej dokument | |
<hr>: wyświetla poziomą kreskę | |
<atrybuty tabeli>....</table>: w celu zdefiniowania tabeli <tr atrybuty>...</tr>: do zdefiniowania wiersza <td atrybuty>...</td>: do zdefiniowania komórki przykłady: <table border="1">...</table>: atrybut border określa grubość obramowania tabeli <td valign="middle" align="center" width="150">komórka(1,2)</td>: definiuje komórkę, której zawartością będzie komórka(1,2). Zawartość ta zostanie wyśrodkowana pionowo (valign="middle") i poziomo (align="center"). Komórka będzie miała szerokość 150 pikseli (width="150") | |
<img border="0" src="/images/univ01.gif" width="80" height="95">: definiuje obraz bez obramowania (border="0"), o wysokości 95 pikseli (height="95"), o szerokości 80 pikseli (width="80"), którego plik źródłowy znajduje się pod adresem /images/univ01.gif na serwerze internetowym (src="/images/univ01.gif"). Link ten znajduje się w dokumencie internetowym, który został wygenerowany za pomocą narzędzia URL http://localhost:81/html/balises.htm. W związku z tym przeglądarka zażąda pliku URL http://localhost:81/images/univ01.gif, aby pobrać obraz, do którego odwołuje się ten link. | |
<a href="http://istia.univ-angers.fr">tutaj</a>: sprawia, że tekst ici służy jako link do strony URL http://istia.univ-angers.fr. | |
<body background="/images/standard.jpg">: wskazuje, że obraz, który ma służyć jako tło strony, znajduje się pod adresem URL /images/standard.jpg na serwerze internetowym. W kontekście naszego przykładu przeglądarka wyśle żądanie do adresu URL http://localhost:81/images/standard.jpg, aby pobrać ten obraz tła. |
Na tym prostym przykładzie widać, że aby zbudować cały dokument, przeglądarka musi wysłać trzy żądania do serwera:
- http://localhost:81/html/balises.htm, aby pobrać kod źródłowy HTML dokumentu
- http://localhost:81/images/univ01.gif, aby pobrać obraz univ01.gif
- http://localhost:81/images/standard.jpg, aby uzyskać obraz tła o numerze standard.jpg
Poniższy przykład przedstawia formularz internetowy, który również został utworzony przy użyciu FrontPage.
Kod HTML wygenerowany przez FrontPage i nieco uproszczony wygląda następująco:
<html>
<head>
<title>balises</title>
<script language="JavaScript">
function effacer(){
alert("Vous avez cliqué sur le bouton Effacer");
}//usuń
</script>
</head>
<body background="/images/standard.jpg">
<form method="POST" >
<table border="0">
<tr>
<td>Etes-vous marié(e)</td>
<td>
<input type="radio" value="Oui" name="R1">Oui
<input type="radio" name="R1" value="non" checked>Non
</td>
</tr>
<tr>
<td>Cases à cocher</td>
<td>
<input type="checkbox" name="C1" value="un">1
<input type="checkbox" name="C2" value="deux" checked>2
<input type="checkbox" name="C3" value="trois">3
</td>
</tr>
<tr>
<td>Champ de saisie</td>
<td>
<input type="text" name="txtSaisie" size="20" value="qqs mots">
</td>
</tr>
<tr>
<td>Mot de passe</td>
<td>
<input type="password" name="txtMdp" size="20" value="unMotDePasse">
</td>
</tr>
<tr>
<td>Boîte de saisie</td>
<td>
<textarea rows="2" name="areaSaisie" cols="20">
ligne1
ligne2
ligne3
</textarea>
</td>
</tr>
<tr>
<td>combo</td>
<td>
<select size="1" name="cmbValeurs">
<option>choix1</option>
<option selected>choix2</option>
<option>choix3</option>
</select>
</td>
</tr>
<tr>
<td>liste à choix simple</td>
<td>
<select size="3" name="lst1">
<option selected>liste1</option>
<option>liste2</option>
<option>liste3</option>
<option>liste4</option>
<option>liste5</option>
</select>
</td>
</tr>
<tr>
<td>liste à choix multiple</td>
<td>
<select size="3" name="lst2" multiple>
<option>liste1</option>
<option>liste2</option>
<option selected>liste3</option>
<option>liste4</option>
<option>liste5</option>
</select>
</td>
</tr>
<tr>
<td>bouton</td>
<td>
<input type="button" value="Effacer" name="cmdEffacer" onclick="effacer()">
</td>
</tr>
<tr>
<td>envoyer</td>
<td>
<input type="submit" value="Envoyer" name="cmdRenvoyer">
</td>
</tr>
<tr>
<td>rétablir</td>
<td>
<input type="reset" value="Rétablir" name="cmdRétablir">
</td>
</tr>
</table>
<input type="hidden" name="secret" value="uneValeur">
</form>
</body>
</html>
Związek między kontrolą wizualną <--> znacznikiem HTML jest następujący:
Kontrola | tag HTML |
<form method="POST" > | |
<input type="text" name="txtSaisie" size="20" value="kilka słów"> | |
<input type="password" name="txtMdp" size="20" value="unMotDePasse"> | |
<textarea rows="2" name="areaSaisie" cols="20"> wiersz1 wiersz 2 wiersz 3 </textarea> | |
<input type="radio" value="Tak" name="R1">Tak <input type="radio" name="R1" value="nie" checked>Nie | |
<input type="checkbox" name="C1" value="jeden">1 <input type="checkbox" name="C2" value="dwa" checked>2 <input type="checkbox" name="C3" value="trzy">3 | |
<select size="1" name="cmbValeurs"> <option>opcja1</option> <option selected>opcja 2</option> <option>opcja 3</option> </select> | |
<select size="3" name="lst1"> <option selected>lista1</option> <option>lista2</option> <option>lista3</option> <option>lista4</option> <option>lista5</option> </select> | |
<select size="3" name="lst2" multiple> <option>lista1</option> <option>lista2</option> <option selected>lista3</option> <option>lista4</option> <option>lista5</option> </select> | |
<input type="submit" value="Wyślij" name="cmdRenvoyer"> | |
<input type="reset" value="Przywróć" name="cmdRétablir"> | |
<input type="button" value="Usuń" name="cmdEffacer" onclick="effacer()"> |
Przyjrzyjmy się tym różnym elementom formularza.
2.7.1.1. Formularz
<form method="POST" > |
<form name="..." method="..." action="...">...</form> | |
name="frmexemple": nazwa formularza method="..." : metoda używana przez przeglądarkę do wysyłania do serwera WWW wartości zebranych w formularzu action="..." : adres, na który zostaną wysłane wartości zebrane w formularzu. Formularz internetowy jest otoczony tagami <form>...</form>. Formularz może mieć nazwę (name="xx"). Dotyczy to wszystkich elementów kontrolnych, które można znaleźć w formularzu. Nazwa ta jest przydatna, jeśli dokument internetowy zawiera skrypty, które muszą odwoływać się do elementów formularza. Celem formularza jest zebranie informacji podanych przez użytkownika za pomocą klawiatury lub myszy oraz przesłanie ich do serwera internetowego o adresie URL. Którego? Tego, do którego odwołuje się atrybut action="URL". Jeśli ten atrybut nie występuje, informacje zostaną wysłane na serwer URL dokumentu, w którym znajduje się formularz. Tak byłoby w przypadku powyższego przykładu. Do tej pory zawsze postrzegaliśmy klienta internetowego jako „żądającego” informacji od serwera internetowego, a nigdy jako „przekazującego” mu informacje. W jaki sposób klient sieciowy przekazuje informacje (zawarte w formularzu) do serwera sieciowego? Omówimy to szczegółowo nieco później. Może on skorzystać z dwóch różnych metod o nazwach POST i GET. Atrybut method="méthode", z metodą równą GET lub POST, w tagu <form> wskazuje przeglądarce metodę, jaką należy zastosować do wysłania informacji zebranych w formularzu do URL określonego przez atrybut action="URL". Gdy atrybut method nie jest określony, domyślnie stosowana jest metoda GET. |
2.7.1.2. Pole wprowadzania danych
<input type="text" name="txtSaisie" size="20" value="kilka słów"> <input type="password" name="txtMdp" size="20" value="unMotDePasse"> |
<input type="..." name="..." size=".." value=".."> Tag `input` występuje w różnych typach elementów sterujących. To właśnie atrybut type pozwala odróżnić te różne elementy sterujące od siebie. | |
type="text": określa, że jest to pole wprowadzania danych type="password": znaki w polu wprowadzania danych są zastępowane znakami *. Jest to jedyna różnica w stosunku do zwykłego pola wprowadzania danych. Ten typ elementu kontrolnego nadaje się do wprowadzania haseł. size="20": liczba znaków widocznych w polu – nie uniemożliwia wprowadzenia większej liczby znaków name="txtSaisie": nazwa elementu sterującego value="kilka słów": tekst, który będzie wyświetlany w polu wprowadzania danych. |
2.7.1.3. Pole wprowadzania wielowierszowe
<textarea rows="2" name="areaSaisie" cols="20"> ligne1 ligne2 ligne3 </textarea> |
<textarea ...>tekst</textarea> wyświetla wielowierszowe pole wprowadzania tekstu, w którym początkowo znajduje się tekst | |
rows="2": liczba wierszy cols="'20" : liczba kolumn name="areaSaisie": nazwa kontrolki |
2.7.1.4. Przyciski opcji
<input type="radio" value="Tak" name="R1">Tak <input type="radio" name="R1" value="nie" checked>Nie |
<input type="radio" attribut2="valeur2" ....>tekst wyświetla przycisk opcji z tekstem obok. | |
name="radio": nazwa elementu sterującego. Przyciski opcji o tej samej nazwie tworzą grupę przycisków, które wykluczają się wzajemnie: można zaznaczyć tylko jeden z nich. value="wartość": wartość przypisana do przycisku opcji. Nie należy mylić tej wartości z tekstem wyświetlanym obok przycisku opcji. Ten ostatni służy wyłącznie do wyświetlania. checked: jeśli to słowo kluczowe jest obecne, przycisk opcji jest zaznaczony, w przeciwnym razie nie jest. |
2.7.1.5. Pola wyboru
<input type="checkbox" name="C1" value="jeden">1 <input type="checkbox" name="C2" value="dwa" checked>2 <input type="checkbox" name="C3" value="trzy">3 |
<input type="checkbox" attribut2="valeur2" ....>tekst wyświetla pole wyboru z tekstem obok. | |
name="C1": nazwa elementu sterującego. Pola wyboru mogą, ale nie muszą mieć tę samą nazwę. Pola o tej samej nazwie tworzą grupę powiązanych pól. value="wartość": wartość przypisana do pola wyboru. Nie należy mylić tej wartości z tekstem wyświetlanym obok przycisku opcji. Ten ostatni służy wyłącznie do wyświetlania. checked: jeśli to słowo kluczowe występuje, przycisk opcji jest zaznaczony, w przeciwnym razie nie jest. |
2.7.1.6. Lista rozwijana (combo)
<select size="1" name="cmbValeurs"> <option>choix1</option> <option selected>wybór2</option> <option>choix3</option> </select> |
<select size=".." name=".."> <option [selected]>...</option> ... </select> wyświetla na liście teksty zawarte między tagami <option>...</option> | |
name="cmbValeurs": nazwa kontrolki. size="1": liczba widocznych elementów listy. size="1" sprawia, że lista działa jak pole kombi. selected: jeśli to słowo kluczowe występuje dla elementu listy, element ten pojawia się jako zaznaczony na liście. W naszym przykładzie powyżej element listy choix2 pojawia się jako zaznaczony element pola kombi, gdy jest ono wyświetlane po raz pierwszy. |
2.7.1.7. Lista z jednym elementem do wyboru
<select size="3" name="lst1"> <option selected>lista1</option> <option>liste2</option> <option>liste3</option> <option>liste4</option> <option>liste5</option> </select> |
<select size=".." name=".."> <option [selected]>...</option> ... </select> wyświetla na liście teksty zawarte między tagami <option>...</option> | |
takie same jak w przypadku listy rozwijanej wyświetlającej tylko jeden element. Ten element sterujący różni się od poprzedniej listy rozwijanej jedynie atrybutem size>1. |
2.7.1.8. Lista z możliwością wielokrotnego wyboru
<select size="3" name="lst2" multiple> <option selected>lista1</option> <option>liste2</option> <option selected>lista3</option> <option>liste4</option> <option>liste5</option> </select> |
<select size=".." name=".." multiple> <option [selected]>...</option> ... </select> wyświetla na liście teksty zawarte między tagami <option>...</option> | |
multiple: umożliwia zaznaczenie wielu elementów z listy. W powyższym przykładzie zaznaczone są zarówno elementy liste1, jak i liste3. |
2.7.1.9. Przycisk typu button
<input type="button" value="Usuń" name="cmdEffacer" onclick="effacer()"> |
<input type="button" value="..." name="..." onclick="effacer()" ....> | |
type="button": definiuje kontrolkę przycisku. Istnieją dwa inne typy przycisków: submit i reset. value="Usuń": tekst wyświetlany na przycisku onclick="funkcja()": pozwala zdefiniować funkcję, która ma zostać wykonana, gdy użytkownik kliknie przycisk. Funkcja ta jest częścią skryptów zdefiniowanych w wyświetlanym dokumencie internetowym. Powyższa składnia jest zgodna ze standardem javascript. Jeśli skrypty są napisane w języku VBScript, należy wpisać onclick="funkcja" bez nawiasów. Składnia pozostaje taka sama, jeśli do funkcji trzeba przekazać parametry: onclick="funkcja(val1, val2,...)" W naszym przykładzie kliknięcie przycisku Effacer wywołuje następującą funkcję JavaScript effacer: Funkcja effacer wyświetla komunikat:  |
2.7.1.10. Przycisk typu „submit”
<input type="submit" value="Wyślij" name="cmdRenvoyer"> |
<input type="submit" value="Wyślij" name="cmdRenvoyer"> | |
type="submit": definiuje przycisk jako przycisk wysyłający dane formularza do serwera internetowego. Gdy użytkownik kliknie ten przycisk, przeglądarka wyśle dane formularza do adresu URL określonego w atrybucie action tagu <form> zgodnie z metodą określoną przez atrybut method tego samego tagu. value="Wyślij": tekst wyświetlany na przycisku |
2.7.1.11. Przycisk typu reset
<input type="reset" value="Przywróć" name="cmdRétablir"> |
<input type="reset" value="Przywróć" name="cmdRétablir"> | |
type="reset": określa przycisk jako przycisk resetowania formularza. Gdy użytkownik kliknie ten przycisk, przeglądarka przywróci formularz do stanu, w jakim go otrzymała. value="Przywróć" : tekst wyświetlany na przycisku |
2.7.1.12. Ukryte pole
<input type="hidden" name="secret" value="uneValeur"> |
<input type="hidden" name="..." value="..."> | |
type="hidden": określa, że jest to pole ukryte. Pole ukryte stanowi część formularza, ale nie jest widoczne dla użytkownika. Jeśli jednak użytkownik poprosiłby przeglądarkę o wyświetlenie kodu źródłowego, zobaczyłby tag <input type="hidden" value="..."> i tym samym wartość pola ukrytego. value="uneValeur": wartość pola ukrytego. Jaka jest zaleta pola ukrytego? Pozwala to serwerowi internetowemu na przechowywanie informacji w trakcie kolejnych żądań wysyłanych przez klienta. Rozważmy przykład aplikacji do zakupów internetowych. Klient kupuje pierwszy produkt o numerze art1 w ilości q1 na pierwszej stronie katalogu, a następnie przechodzi do kolejnej strony katalogu. Aby zapamiętać, że klient kupił q1 sztuk art1, serwer może umieścić te dwie informacje w ukrytym polu formularza internetowego na nowej stronie. Na tej nowej stronie klient kupuje produkty o numerach q2 i art2. Gdy dane z tego drugiego formularza zostaną wysłane na serwer (submit), serwer otrzyma nie tylko informację (q2,art2), ale także (q1,art1), które również stanowią część formularza jako ukryte pola, których użytkownik nie może modyfikować. Serwer WWW umieści wówczas w nowym ukrytym polu informacje (q1,art1) oraz (q2,art2) i wyśle nową stronę katalogu. I tak dalej. |
2.7.2. Wysyłanie wartości formularza do serwera WWW przez klienta WWW
W poprzednim opracowaniu wspomnieliśmy, że klient internetowy dysponuje dwiema metodami wysyłania do serwera internetowego wartości formularza, który wyświetlił: metodami GET i POST. Przyjrzyjmy się na przykładzie różnicy między tymi dwiema metodami. Strona omawiana wcześniej jest stroną statyczną. Aby uzyskać dostęp do nagłówków HTTP wysyłanych przez przeglądarkę, która zażąda tego dokumentu, przekształcamy ją w stronę dynamiczną dla serwera internetowego .NET (IIS lub Cassini). Nie chodzi tu o technologię .NET, która zostanie omówiona w następnym rozdziale, ale o komunikację między klientem a serwerem. Kod strony ASP.NET jest następujący:
<%@ Page Language="vb" CodeBehind="params.aspx.vb" AutoEventWireup="false" Inherits="ConsoleApplication1.params" %>
<script runat="server">
Private Sub Page_Init(Byval Sender as Object, Byval e as System.EventArgs)
' zapisujemy zapytanie
saveRequest
end sub
Private Sub saveRequest
' zapisuje bieżące zapytanie w pliku request.txt w folderze strony
dim requestFileName as String=Me.MapPath(Me.TemplateSourceDirectory)+"\request.txt"
Me.Request.SaveAs(requestFileName,true)
end sub
</script>
<html>
<head>
<title>balises</title>
<script language="JavaScript">
function effacer(){
alert("Vous avez cliqué sur le bouton Effacer");
}//usuń
</script>
</head>
<body background="/images/standard.jpg">
....
</body>
</html>
Do treści HTML analizowanej strony dodajemy fragment kodu w formacie VB.NET. Nie będziemy komentować tego kodu, poza tym, że przy każdym wywołaniu powyższego dokumentu serwer WWW zapisze żądanie klienta WWW w pliku [request.txt] w folderze wywoływanego dokumentu.
2.7.2.1. Metoda GET
Przeprowadźmy pierwszy test, w którym w kodzie HTML dokumentu tag FORM jest zdefiniowany w następujący sposób:
<form method="get">
Poprzedni dokument (HTML + kod VB) nosi nazwę [params.aspx]. Znajduje się on w strukturze katalogów serwera WWW .NET (IIS/Cassini) i jest wywoływany za pomocą adresu URL http://localhost/aspnet/chap1/params.aspx:
Przeglądarka właśnie wysłała żądanie i wiemy, że zostało ono zapisane w pliku [request.txt]. Przyjrzyjmy się jego zawartości:
GET /aspnet/chap1/params.aspx HTTP/1.1
Connection: keep-alive
Keep-Alive: 300
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: en-us,en;q=0.5
Host: localhost
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Wykryto elementy, które pojawiły się już wcześniej u klienta [curl]. Inne pojawiają się po raz pierwszy:
klient prosi serwer, aby nie zamykał połączenia po wysłaniu odpowiedzi. Dzięki temu będzie mógł wykorzystać to samo połączenie do kolejnego żądania. Połączenie nie pozostaje otwarte w nieskończoność. Serwer zamknie je po zbyt długim okresie bezczynności. | |
czas w sekundach, przez który połączenie [Keep-Alive] pozostanie otwarte | |
Kategoria znaków, które klient potrafi obsłużyć | |
Lista języków preferowanych przez klienta. |
Formularz wypełniamy w następujący sposób:
Korzystamy z powyższego przycisku [Envoyer]. Jego kod HTML jest następujący:
Po kliknięciu przycisku typu [Submit] przeglądarka wysyła parametry formularza (tag <form>) do adresu URL wskazanego w atrybucie [action] tagu <form action="URL">, o ile taki istnieje. Jeśli ten atrybut nie istnieje, parametry formularza są wysyłane do adresu URL, z którego pochodzi formularz. Tak jest w tym przypadku. Przycisk [Envoyer] powinien zatem spowodować wysłanie przez przeglądarkę żądania do serwera URL [http://localhost/aspnet/chap1/params.aspx] wraz z przekazaniem parametrów formularza. Ponieważ strona [params.aspx] zapamiętuje otrzymane żądanie, powinniśmy wiedzieć, w jaki sposób klient przesłał te parametry. Spróbujmy. Klikamy przycisk [Envoyer]. Otrzymujemy następującą odpowiedź z przeglądarki:
Jest to strona początkowa, ale można zauważyć, że wartość URL w polu [Adresse] przeglądarki uległa zmianie. Przybrała następującą postać:
http://localhost/aspnet/chap1/params.aspx?R1=Tak&C1=jeden&C2=dwa&txtSaisie=programowanie+stron+internetowych&txtMdp=tojesttajemnica&areaSaisie=podstawy+programowania+webowego%0D%0Aprogramowanie+stron+internetowych&cmbValeurs=wybór3&lst1=lista3&lst2=lista1&lst2=lista3&cmdRenvoyer=Wyślij&secret=uneValeur
Widać, że wybory dokonane w formularzu znalazły się w polu URL. Przyjrzyjmy się zawartości pliku [request.txt], który zapisał żądanie klienta:
GET /aspnet/chap1/params.aspx?R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&areaSaisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
Connection: keep-alive
Keep-Alive: 300
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: en-us,en;q=0.5
Host: localhost
Referer: http://localhost/aspnet/chap1/params.aspx
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
Widzimy zapytanie HTTP, dość podobne do tego, które pierwotnie wysłała przeglądarka, gdy żądała dokumentu bez przekazywania parametrów. Istnieją dwie różnice:
Parametry formularza zostały dodane po adresie URL dokumentu w postaci ?param1=val1¶m2=val2&... | |
klient wskazuje za pomocą tego nagłówka HTTP numer URL dokumentu, który wyświetlał w momencie wysłania żądania |
Przyjrzyjmy się bliżej, w jaki sposób parametry zostały przekazane w poleceniu GET URL?param1=wartość1¶m2=wartość2&... HTTP/1.1, gdzie parami to nazwy elementów sterujących formularza internetowego, a „wartości” to przypisane do nich wartości. Poniżej przedstawiamy tabelę z trzema kolumnami:
- kolumna 1: zawiera definicję elementu sterującego HTML z przykładu
- kolumna 2: przedstawia wygląd tego elementu w przeglądarce
- kolumna 3: przedstawia wartość wysyłaną do serwera przez przeglądarkę dla elementu z kolumny 1 w postaci, jaką ma ona w zapytaniu GET z przykładu
element sterujący HTML | wygląd | zwracana(-e) wartość(-i) |
<input type="radio" value="Tak" name="R1">Tak <input type="radio" name="R1" value="nie" checked>Nie |  | R1=Tak – wartość atrybutu value przycisku opcji zaznaczonego przez użytkownika. |
<input type="checkbox" name="C1" value="jeden">1 <input type="checkbox" name="C2" value="dwa" checked>2 <input type="checkbox" name="C3" value="trzy">3 |  | C1=jeden C2=dwa – wartości atrybutów value pól zaznaczonych przez użytkownika |
<input type="text" name="txtSaisie" size="20" value="kilka słów"> |  | txtSaisie=programowanie+web - tekst wpisany przez użytkownika w polu wprowadzania danych. Spacje zostały zastąpione znakiem + |
<input type="password" name="txtMdp" size="20" value="unMotDePasse"> |  | txtMdp=tojesttajemnica - tekst wpisany przez użytkownika w polu wprowadzania danych |
<textarea rows="2" name="areaSaisie" cols="20"> wiersz1 wiersz 2 wiersz 3 </textarea> |  | areaSaisie=podstawy+programowania+%0D%0A programowania+stron+internetowych - tekst wpisany przez użytkownika w polu wprowadzania danych. %OD%OA to znacznik końca linii. Spacje zostały zastąpione znakiem + |
<select size="1" name="cmbValeurs"> <option>opcja1</option> <option selected>opcja2</option> <option>opcja3</option> </select> |  | cmbValeurs=opcja3 – wartość wybrana przez użytkownika z listy z jednym wyborem |
<select size="3" name="lst1"> <option selected>lista1</option> <option>lista2</option> <option>lista3</option> <option>lista4</option> <option>lista5</option> </select> |  | lst1=lista3 - wartość wybrana przez użytkownika z listy z jednym wyborem |
<select size="3" name="lst2" multiple> <option selected>lista1</option> <option>lista2</option> <option selected>lista3</option> <option>lista4</option> <option>lista5</option> </select> |  | lst2=lista1 lst2=lista3 - wartości wybrane przez użytkownika z listy wielokrotnego wyboru |
<input type="submit" value="Wyślij" name="cmdRenvoyer"> | cmdRenvoyer=Wyślij - nazwa i atrybut value przycisku, który posłużył do wysłania danych formularza na serwer | |
<input type="hidden" name="secret" value="uneValeur"> | secret=jakaswartość - atrybut value pola ukrytego |
Można się zastanawiać, co serwer zrobił z przekazanymi mu parametrami. W rzeczywistości nic. Po otrzymaniu polecenia
GET /aspnet/chap1/params.aspx?R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecret&areaSaisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&cmdRenvoyer=Envoyer&secret=uneValeur HTTP/1.1
serwer WWW przekazał parametry URL do dokumentu http://localhost/aspnet/chap1/params.aspx, a c.a.d do dokumentu, który stworzyliśmy na początku. Nie napisaliśmy żadnego kodu do pobierania i przetwarzania parametrów przesyłanych przez klienta. Dlatego wszystko przebiega tak, jakby żądanie klienta brzmiało po prostu:
Z tego powodu w odpowiedzi na nasz przycisk [Envoyer] otrzymaliśmy tę samą stronę, co początkowo przy wywołaniu URL i [http://localhost/aspnet/chap1/params.aspx] bez parametrów.
2.7.2.2. Metoda POST
Dokument HTML został teraz skonfigurowany tak, aby przeglądarka korzystała z metody POST do wysyłania wartości formularza na serwer WWW:
Żądamy nowego dokumentu za pomocą URL [http://localhost/aspnet/chap1/params.aspx], wypełniamy formularz tak samo jak w przypadku metody GET i przesyłamy parametry do serwera za pomocą przycisku [Envoyer]. Otrzymujemy z serwera następującą stronę odpowiedzi:
Otrzymujemy zatem ten sam wynik, co w przypadku metod GET i c.a.d – stronę początkową. Warto zwrócić uwagę na jedną różnicę: w polu [Adresse] przeglądarki nie pojawiają się przesłane parametry. Przyjrzyjmy się teraz żądaniu wysłanemu przez klienta, które zostało zapisane w pliku [request.txt]:
POST /aspnet/chap1/params.aspx HTTP/1.1
Connection: keep-alive
Keep-Alive: 300
Content-Length: 210
Content-Type: application/x-www-form-urlencoded
Accept: application/x-shockwave-flash,text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,image/jpeg,image/gif;q=0.2,*/*;q=0.1
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Accept-Encoding: gzip,deflate
Accept-Language: en-us,en;q=0.5
Host: localhost
Referer: http://localhost/aspnet/chap1/params.aspx
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
R1=Oui&C1=un&C2=deux&txtSaisie=programmation+web&txtMdp=ceciestsecrey&areaSaisie=les+bases+de+la%0D%0Aprogrammation+web&cmbValeurs=choix3&lst1=liste3&lst2=liste1&lst2=liste3&cmdRenvoyer=Envoyer&secret=uneValeur
W zapytaniu klienta HTTP pojawiają się nowe elementy:
Zapytanie GET zostało zastąpione zapytaniem POST. Parametry nie występują już w pierwszym wierszu zapytania. Można zauważyć, że znajdują się one teraz za zapytaniem HTTP, po pustym wierszu. Ich kodowanie jest identyczne jak w zapytaniu GET. | |
liczba „wysłanych” znaków, c.a.d. Liczba znaków, które serwer WWW będzie musiał odczytać po otrzymaniu nagłówków HTTP, aby pobrać dokument wysłany przez klienta. Dokumentem tym jest w tym przypadku lista wartości z formularza. | |
określa typ dokumentu, który klient wyśle po nagłówkach HTTP. Typ [application/x-www-form-urlencoded] wskazuje, że jest to dokument zawierający wartości z formularza. |
Istnieją dwie metody przesyłania danych do serwera WWW: GET i POST. Czy jedna z tych metod jest lepsza od drugiej? Widzieliśmy, że jeśli wartości formularza były wysyłane przez przeglądarkę metodą GET, przeglądarka wyświetlała w polu Adresse żądaną wartość URL w postaci URL?param1=val1¶m2=val2&.... Można to postrzegać jako zaletę lub wadę:
- zaletą, jeśli chcemy umożliwić użytkownikowi dodanie tego skonfigurowanego adresu URL do ulubionych
- wadą, jeśli nie chcemy, aby użytkownik miał dostęp do niektórych informacji zawartych w formularzu, takich jak na przykład pola ukryte
W dalszej części będziemy stosować w naszych formularzach niemal wyłącznie metodę POST.
2.8. Conclusion
W niniejszym rozdziale przedstawiono różne podstawowe pojęcia związane z tworzeniem stron internetowych:
- różne dostępne narzędzia i technologie (Java, ASP, asp.net, PHP, Perl, VBScript, JavaScript)
- komunikację klient-serwer za pośrednictwem protokołu HTTP
- projektowanie dokumentu przy użyciu języka HTML
- tworzenie formularzy do wprowadzania danych
Na przykładzie mogliśmy zobaczyć, w jaki sposób klient może wysyłać informacje do serwera WWW. Nie omówiliśmy jednak, w jaki sposób serwer może
- pobierać te informacje
- przetworzyć je
- wysłać do klienta dynamiczną odpowiedź zależną od wyniku przetwarzania
Jest to dziedzina programowania internetowego, którą omówimy w następnym rozdziale wraz z prezentacją technologii ASP.NET.