Jak wszystkim wiadomo, JavaScript jest językiem dla skryptów po stronie klienta. Świetnie zatem spisuje się przy urozmaicaniu stron internetowych, pomaga walidować pola w wysyłanych formularzach itp. Radzę sobie zresztą z tym (jak mi się wydaje) całkiem nieźle ;-).
Jednak problem jest inny. Głowię się już nad tym sporo czasu, a mój przyjaciel Google ;-) coś nie bardzo chce mi pomóc...
Owszem, na zapytanie typu "(JavaScript OR JS) Apache" wyrzuca coś o jakiejś tam implementacji ASP na Apache, ale mi nie o to chodzi. Chciałbym bowiem zrobić to jakoś tak podobnie, jak można zaimplementować PHP na tym serwerze - poprzez najzwyklejsze CGI - mówiąc krótko: zaimplementować JavaScript jako CGI po stronie serwera.
Bardzo mi się podoba język PHP (sam używam go na swoim serwerze i jest świetny). Z dokumentacji do tego języka dowiedziałem się, że oprócz instalowania go jako moduł Apache (php4apache2.dll), można go też zainstalować jako CGI (php.exe). Robi się to tak:
- Kod: Zaznacz wszystko
ScriptAlias /php/ "c:/php/"
AddType application/x-httpd-php .php
Action application/x-httpd-php "/php/php.exe"
Jak to działa?
Otóż, dzięki komendzie AddType, serwer dostając żądanie o plik typu *.php "wie", że jest to skrypt PHP, a dzięki Action "wie", co trzeba uruchomić, żeby ten skrypt wykonać. Wysyła więc do programu php.exe na strumień wejściowy (stdin) zawartość pliku *.php, a php.exe to wykonuje, zwracając na strumień wyjściowy (stdout) generowaną przez skrypt stronę, która wysyłana jest do klienta.
Echhh... rozpisałem się o tym PHP, a przecież temat jest o JavaScript...
No właśnie, bo wpadłem na podobny pomysł z tym drugim językiem. Wszak wiadomo, że do wykonywania skryptów w Windows jest takie narzędzie jak WSH (Wndows Script Host). Jeśli skorzystamy z programu cscript.exe, to możemy w nim wysyłać na stdout zawartość dynamicznie generowanej strony w... JavaScript'cie! Albo w VBScript'cie, jak kto woli. Właśnie to, że WSH udostępnia pełen model obiektów potrzebnych do obsługi np. plików na dysku, katalogów, zmiennych środowiskowych itp. dawałoby też mu świetne możliwości jako narzędziu do stworzenia CGI na serwerze Apache (i pewnie nie tylko na nim).
Jak zaś taki skrypt miałby obsługiwać żądanie klienta? Bardzo prosto: poprzez zmienne środowiskowe (tzw. zmienne CGI) zawierające wszelkie szczegóły żądania, a nawet nagłówki (headers) z protokołu HTTP, a co za tym idzie, nawet ciasteczka lub autoryzację (login/hasło do zasobu URL). Zmienne takie tworzyłby mu (jak każdemu innemu skryptowi CGI) sam Apache.
Na przykład (skrypt pokazujący adres IP klienta):
- Kod: Zaznacz wszystko
var sh = WScript.CreateObject("WScript.Shell");
var env = sh.Environment("PROCESS");
WScript.StdOut.Write("Content-type: text/html\n\n");
WScript.StdOut.Write("Twój adres <b>IP</b>: " + env["REMOTE_ADDR"] + "\n");
Jest tylko jeden problem. Program cscript.exe nie przyjmuje kodu skryptu przez stdin, tylko trzeba mu podać nazwę pliku ze skryptem JS jako parametr wywołania. I to właśnie jest problem, którego nie potrafię przeskoczyć :-/.
Może ktoś już o tym myślał kiedyś (choć raczej jeszcze się z tym nigdzie nie spotkałem)? A może nawet, gdzieś tam pokątnie, na swoim serwerze, próbował to zrobić? Kurczę, już mi brakuje pomysłów.
Mianowicie miałem na początku taki pomysł: zaimplementować cscript.exe jako filtr w Apache (komendy AddInputFilter, AddOutputFilter, RemoveInputFilter, RemoveOutputFilter, ExtFilterDefine, ExtFilterOptions, SetInputFilter, SetOutputFilter). No, ale wtedy musiałbym dla każdego pliku JavaScript (CGI) w httpd.conf definiować osobny filtr - dość kiepskie rozwiązanie :-/.
Kombinowałem już z tymi dyrektywami AddType, Action itp. ale też bez skutku :-/.
Zaczytuję się w manuala od Apache, ale niewiele mi przychodzi do głowy :-/.
Może ktoś ma jeszcze jakiś pomysł, ale nie wymagający ściągania, ani instalowania niczego? Wszak WSH jest w Windows dostępne "na dzień dobry" - właśnie bez ściągania i instalowania czegokolwiek...
Mój Apache jest w wersji 2.0.
Z góry dziękuję za pomysły i wszyskich serdecznie pozdrawiam, a szczególnie Tomcia (@ MUTOPOMPKA), choć on raczej nie będzie znał odpowiedzi na to pytanie ;-).
.
