🚀 go-pugleaf

Mariusz Jasinski wrote:
> 
> W ramach zajec na uczelni splodzilem male opracowanie
> o CGI. Chetnych zapraszam do skorzystania.
> A doswiadczonych o ocene i porawienie bledow.
[...]

  Nie jestem zbyt doświadczony, ale...

Na stronie o wadach CGI piszesz o API. Wspominasz o "najbardziej
znanych" API popularnych serwerów - NSAPI i ISAPI.
Zapomniałeś o trochę popularnieszym serwerze Apache, który też ma API.

  Piszesz tez o DLLach, zapominając o tym, że jest specyfika Windows
(a może się mylę?).

Wspomniałeś też, że plik do którego pisze program CGI musi mieć prawa
zapisu dla wszystkich. Nie jest to prawdą. Może zostać stworzona
specjalna grupa (w UNIXie na pewno), która będzie miała prawo zapisu, a
do której należał będzie tylko użytkownik, jako który jest uruchamiany
serwer.

Chomik
-- 
IRC__  __ Marcin Nowak_   __  mailto:mnowak@asic.ict.pwr.wroc.pl *****
 /  _)/  )_ ___  _ __(_) /  ) mailto:chomik@piast.t19.ds.pwr.wroc.pl *
(  (_/'_   ) . /' V  / )/' ~) http://www.t19.ds.pwr.wroc.pl/~chomik/ *
 \ _(_/ (_/\__(_/2_/(_/(_/\_) *** Technical University of Wroclaw ****

In pl.comp.lang.perl Mariusz Jasinski <jasinski@ci-1.ci.pwr.wroc.pl> wrote:
: W ramach zajec na uczelni splodzilem male opracowanie
: o CGI. Chetnych zapraszam do skorzystania.
: A doswiadczonych o ocene i porawienie bledow.

: Adres opracowania o CGI:
: http://www.ci.pwr.wroc.pl/~jasinski/cgi/

Aktualna wersja perla to 5.004 (ale to drobiazg - sam jeszcze mam 
5.003 :-) ).

Natomiast jeżeli chodzi o API dla serwerów, to mam już znacznie 
więcej uwag:

> Wymagane jest umieszczanie funkcji w bibliotekach DLL, korzystanie 
> z wielowątkowości, synchronizacja procesów, bezpośrednie 
> programowanie protokołu TCP/IP, złożona obsługa błędów.

Żadne z powyższych stwierdzeń nie jest prawdziwe. Właśnie niedawno 
napisałem moduł do Apache'a korzystając z jego API, i wszystkie 
wymienione powyżej problemy są rozwiązane przez twórców serwera - nie
ma potrzeby robić tego samodzielnie (chociaż oczywiście można, jak 
ktoś chce to zrobić lepiej - powodzenia :-) ).

Poza tym co prawda pojawiło się zdanie "serwer apache ma również 
własne API", ale moim zdaniem to trochę za mało - nie widziałem 
innych API i trudno mi porównywać, ale wydaje mi się że API z serwera
Apache nie jest gorsze, a przypuszczam że lepsze, niż API w 
pozostałych serwerach (szczególnie jeżeli faktycznie tamte API mają 
takie ograniczenia o których pisze autor).

Dalej:

>  #!/usr/bin/perl
>  print "HTTP/1.0 200 OK\n";

Tego akurat nie rozumiem... Bo to jest tak - z jednej strony 
specyfikacja CGI mówi że "The output of scripts begins with a small 
header. This header consists of text lines, in the same format as an 
HTTP header, terminated by a blank line (a line with only a linefeed 
or CR/LF)." - czyli można by przypuszczać że skrypt nie powinien 
generować status-line, z drugiej strony nieco dalej są przykłady, 
gdzie faktycznie taka linijka jest wypisywana. Więc ja już głupi 
jestem i nie wiem jak ma być :-)  W każdym razie apache (przynajmniej
w wersji 1.0.5) takiego CGI nie przyjmuje do wiadomości.

...

> print "<meta http-equiv=\"content-type ....

A to już moim zdaniem totalny bezsens. Kilka wierszy wyżej 
umieszczone jest:

> print "Content-type: text/html\n\n";

a potem jest to powtórzone w samym html. Dlaczego nie umieścić 
informacji o charset'cie właśnie w nagłówku, tam gdzie od wieków jest
jej miejsce? :-)

> print "Content-type: text/html; charset=ISO-8859-2\n\n";

...

> PATH_INFO  - Pełna ścieżka dostępu do programu CGI w systemie 
>     plików serwera WWW ...

Nie! PATH_INFO to zupełnie co innego - to jest to co użytkownik poda 
po nazwie skryptu jako dodatkową ścieżkę, np:

http://www.agh.edu.pl/ogonki/test.cgi/pl-iso

powoduje uruchomienie test.cgi z ustawieniem PATH_INFO na "/pl-iso"

Podobnie - PATH_TRANSLATED to to samo PATH_INFO po przetworzeniu 
przez serwer.


Teraz tak ogólnie... Może będę bezlitosny, ale odniosłem wrażenie że 
tekst był (dla mnie!) raczej mało zrozumiały, więc boję się że skoro 
ja miałem problemy z jego zrozumieniem, to człowiek który nie ma 
pojęcia o CGI niewiele z tego tekstu wyniesie korzyści... Na początku
brakuje przykładów, a te które się potem pojawiają są zbyt złożone.
Chyba znacznie lepsze byłoby proste przetłumaczenie tego co jest pod
http://hoohoo.ncsa.uiuc.edu/cgi/

-- 
Piotr Piątkowski, Uczelniane Centrum Informatyki, AGH Krakow, POLAND