Web, CGI

Clipper, CCC

Tudom, hogy abszolúte semmi értelme, és ezután csak magamra vethetek, de CGI/PHP támogatást raktam a CCC3-WebServer-be. Még így is alig több, mint 800 sor.

  • 6159 megtekintés

( Wintermute | 2007. 02. 23., p – 19:28 )

Van értelme, mert enélkül halotthalavány esélyünk se lett volna soha átállni rá. Pedig szívesen tenném, ha appszerverként ki tudnám használni a perzisztenciáját. Úgyhogy részemről örülés :D

w

( mrev | 2007. 02. 27., k – 11:01 )

Írok pár sort a CCC3-WebServerről:

Kevesebb, mint 20 CCC/Clipper sorban lehet olyan webszervert írni, ami statikus oldalakat adogat. Ezt nem úgy kell érteni, hogy volna valahol egy HTTP szerver objektum, amit csak példányosítani kell. A 20 sor socket műveletekből és read/write-ból építi fel a szervert. Ezzel persze a CCC nem áll egyedül: Pythonban és Pikeban is láttam hasonló demó programokat.

Kevesebb, mint 250 sorban lehet olyan CCC webszervert írni, ami még nindig csak statikus oldalakat (plusz directory listákat) adogat, de többszálú. Minden új klienst új szál szolgál ki. Egy szál akkor fejezódik be, ha a kliens megszakítja a TCP kapcsolatot, vagy 10 secnél hosszabb ideig inaktív. A tesztek során egy ilyen szerver 1-2 óra alatt 10 millió requestet teljesített, miközben a párhuzamosan működő szálak száma 5-10 között mozgott.

A jelenlegi CCC3-WebServer 850 soros. Többszálú. Van benne SSI, CGI, PHP támogatás. A PHP CGI átirányítással műkódik, elmegy vele a PunBB és a Drupal. Van hozzá HTTPS támogatás. Persze így sem akar több lenni, mint demó/tesztprogram.
--
CCC3

Bevallom ferfiasan, nem vagyok nagy mestere a webservereknek, ezert azt szeretnem tudni, mire gondolsz, amikor azt irod hogy ez persze tovabbra is csak egy demo/teszt program. Effektivitas, vedelem, funkcionalitás ?
( nagyon specialis celra szeretnek, hasznalni egy sajat web szervert..)
köszi, VZ

Arra gondolok, hogy nem cél utólérni az Apacheot. Nem is volna könnyű, és nincs is értelme. Ha ISP volnék és ezer kuncsaft weboldalát kellene működtetnem, akkor biztosan Apacheot használnék, mert az mindent tud, amit az ezer kuncsaft ki tud találni. Viszont akinek "nagyon speciális" célra kell egy webszerver, az gondolkodhat másban is.

A CCC3-WebServert demó célból használom: A CCC-s oldalakat CCC-s webszerver adogatja.

Statikus weblapokat adogatni nem egy bonyolult dolog. Nem kell hozzá nagy teljesítmény, támadni sem lehet, mert nincs rajta fogás.

Kézenfekvő, hogy egy webszerver szálakkal dolgozzon. A CCC3-WebServer demonstratívan többszálú. A tesztelés sem haszontalan, ui. a többszálú programok megbízhatósága mindig kétes. (A CCC3 WebServer az én praxisomban még nem szállt el.)

A CCC-ben elég jól megvannak azok dolgok, amik más processzek futtatásához kellenek. Ezt demonstrálja a CGI támogatás. A CGI-s webhelyek sokkal támadhatóbbak, mint a statikusak, a teljesítmény pedig attól függ, hogy mit csinálnak a CGI programok, de az a tipikus, hogy ilyenkor a szűk keresztmetszetet az adatbázisműveletek jelentik.

Ha már CGI, akkor legyen PHP is. Nekem konkrétan a PunBB kellett, Apachera átállni mégsem akartam, hát beletettem a PHP támogatást a szerverbe. A CGI-ként indítgatott PHP nyilván kevésbé hatékony, mint a mod_php, csak hát mégsem ez a szűk keresztmetszet, hanem az adatbázis. Nálam egyébként nincs nagy forgalom, úgyhogy mindegy.

Kb. itt kezdődnek a minimális tudású webszerverek.

--
CCC3

( Wintermute | 2007. 09. 06., cs – 19:51 )

Olyan bánatom van, hogy a cgi-binben lévő programok is mind a htdocs-ban futnak, ezáltal a bt-jeiket is ott hozzák létre. A probléma könnyen orvosolható, a kérdés, hogy érdekel-e mást is a javítás.

w

Az Apache úgy csinálja, hogy mindig belép a könyvtárba, amiben maga a CGI file van. Ebből kifolyólag a CGI program helyben hozza létre a file-jait.
A websrv-ben ez úgy vihető végbe, hogy a 908-adik sorában a spawn elé beteszünk egy dirchange-t. Azt viszont nem tudom, hogy ez mit fog csinálni a szálakkal, de elvileg semmit.

w

Sajnos ilyen egyszerűen nem megy. A directory váltás a szálakra globális. Ha tehát az egyik szál directoryt vált, akkor a másik szál nem találja a filéket a relatív path-ban.

Ha csak UNIX-on kéne működni, akkor a directory váltást a fork és exec közé lehetne tenni. Windowson azonban csak spawn van, aminek nincs workingdirectory paramétere.

Megoldás lehetne az url kereséseknél (360-440) áttérni abszolút pathra, akkor a spawn előtt (908) tényleg lehetne a mutspw védelmen belül szabadon cd-zgetni. Ez azért több órás munka.

--
CCC3

( Wintermute | 2007. 10. 25., cs – 16:03 )

Ja igen. A websrv-ben van egy olyan bug szintén Windowson, hogy a futtathatóság Windowson nem jó. Asszem a fileisexecutable() függvény nem viselkedik helyesen. Bele kéne tenni, hogy ha Windowson vagyunk, akkor a com/exe/bat kiterjesztések legyenek futtathatóak.

w

( meza | 2008. 01. 21., h – 11:21 )

Van valakinek ötlete, hogy egy CGI kimenetében miképpen lehet http_setheader() -t érvényesíteni? :)
Ajax servernek kellene a cgi, aminek rendes XML contentet kénekiírnia.

Nem nagyon értem a kérdést, az Ajaxhoz meg végképp nem értek.

Amikor a CGI program a választ kiírja az stdout-ra, akkor közben kiírhatja a headereket is, és nincs szükség a http_setheader-re, mint ebben a primitív példában: 


function cgi.response(ctype,content)
    ?? a"Content-Type: "+str2bin(ctype)+CRLF
    if( content!=NIL )
        ?? a"Content-Length: " + str2bin(alltrim(str(len(content))))+CRLF 
        ?? CRLF
        //eddig voltak a headerek
        //most jön a body
        ?? content
    end

A másik lehetőség, hogy a CGI program összegyűjti az összes kimenetét egy stringben (a headereket is), és utólag manipulálja a headereket a http_setheader-rel. Ez tisztán string műveleteket tartalmaz csak, nézd meg a forrását.

--
CCC3

( scorpio-grass | 2008. 01. 23., sze – 11:06 )

A websrv - windows, mingw - a kovetkezo hibat kapom az s.bat inditasakor:

---------------------------------

ALERT
Operation: socket.bind
Description: bind failed

default error block evaluated
errorclass: socketerror
operation: socket.bind
description: bind failed
args:{NUMBER 816, NIL, NUMBER 8080}
oscode: 10038
called from deferror(215)
called from _blk__2(0)
called from socket.bind(130)
called from listener.bind(70)
called from main(316)

------------------------------------------

A 10038 - hiba:
Socket Error 10038 - The Descriptor is not a socket.

Miert nem akar a 8080 porthoz kotodni. Mi lehet a hiba?

Összeszereltem a régi Windows 2K-s gépemet, mindent frissítettem és újrafordítottam: csont nélkül működik. A hibaüzenet jónak látszik, mármint, hogy a 816-os fd nem socket, de nem tudom, hogy mi az oka. Kicsit kapálódznod kellene, kipróbálni egyszerűbb socketes programokat.

Szerk. Pl. ez egy egyszerűbb program: 


function main()
    ? bind(socket(),8080)

Ha ez 0-t ír ki, akkor a websrv-nek is működnie kellene.
--
CCC3

Koszonom a faradsagodat, kepeckedek, kepeckedek, de nem jutottam elobbre. Ha az a ha ott nem volna. Az altalad adott kodot leprobaltam, es 0 kapok a 8080 portra:

bind(socket(),8080) -> 0 Ok.

Valojaban ket gepen probaltam leforditani kulon kulon. Csak a masik gepen a sfd 1104 , a hibakod ugyanaz.

args:{NUMBER 1104, NIL, NUMBER 8080}
oscode: 10038

Tavaly aprilisban /070404/ forditottam le elotte, az ma is problema nelkul mukodik.

Szomorú:(

A hdup(s,.f.,.t.) értelme:

Duplikálja a socket handlert úgy,
hogy az új handle nem öröklődik,
az eredeti (régi) pedig lezáródik.

A művelet a Te Windowsodon olyan új handle-t eredményez, aminek elvész az a tulajdonsága, hogy ő egy socket handle. Nem tudom megjavítani, mert nincs olyan Windowsom, amin ez a jelenség fellépne. Egy windowsos ember segítségére volna szükség, aki tudja, hogy a modernebb Windowsokon mit kell használni a DuplicateHandle API helyett.

Ha a websrv-t használni akarod, akkor ideiglenes megoldásként kihagyhatod az öröklődés letiltását. Ehhez a CCCDIR/tools/socket/socket_class.prg-ben kommentezd ki a socket.inherit függvényben a hdup-os sort. Persze ez nem az igazi. Az öröklődést azért kell letiltani, hogy a websrv-ből induló CGI programok ne örököljék a websrv-ben nyitva levő socketeket.

Érdekelne, hogy milyen Windowst,
és milyen MinGW-t használsz.

--
CCC3

Kivettem, alabbi eredmeny kaptam a socket es websrv teljes ujraforditasa utan:

ALERT
Operation: socket.bind
Description: bind failed

default error block evaluated
errorclass: socketerror
operation: socket.bind
description: bind failed
args:{NUMBER 1112, NIL, NUMBER 8080}
oscode: 10038
called from deferror(215)
called from _blk__2(0)
called from socket.bind(130)
called from listener.bind(70)
called from main(316)

Az alabbi osszeallitast hasznalom.

MS XP
home edition Version 2002 SP2 - Version 5.1 ( Build 2600.xpsp_sp2_gdr.070227-2254: SP2)

mingw
Build=6
URL=http://www.mingw.org
Filename=MinGW-5.0.3.exe

runtime=mingw-runtime-3.10.tar.gz|5156
w32api=w32api-3.7.tar.gz|13709
binutils=binutils-2.15.91-20040904-1.tar.gz|13985
core=gcc-core-3.4.2-20040916-1.tar.gz|8627
gpp=gcc-g++-3.4.2-20040916-1.tar.gz|16542
g77=gcc-g77-3.4.2-20040916-1.tar.gz|5158
ada=gcc-ada-3.4.2-20040916-1.tar.gz|33333
java=gcc-java-3.4.2-20040916-1.tar.gz|45547
objc=gcc-objc-3.4.2-20040916-1.tar.gz|4555
make=mingw32-make-3.80.0-3.tar.gz|1925

Valami nem koser, de mi?

Nálam Windows 2000 SP4 van, a MinGW és gcc ugyanaz.

Az a gyanúm, nem azt fordítottad újra, amit kellett volna. A ccc3_socket könyvtárat kell újrafordítani a socket.inherit metódusban hdup nélkül, a websrv programot pedig újralinkelni az új könyvtárral. Próbáld újra.

Közben itt találtam:

You should not use DuplicateHandle to duplicate handles to the following objects ... Sockets. No error is returned, but the duplicate handle may not be recognized by Winsock at the target process... To duplicate a socket handle, use the WSADuplicateSocket function.

Ez megegyezik a megfigyelésemmel. Viszont az ajánlott WSADuplicateSocket-ben nincs lehetőség az öröklődés szabályozására. Úgyhogy passz. Azt még megemlítem, hogy miközben most bogarásztam az interneten, láttam olyan programpéldát, ami a DuplicateHandle-lel dupolt socketet.

--
CCC3

Egen. Stimmel. Hiba az én felemen, jot probaltam javitani es forditani. Mi volt problemám:

/*
#ifdef _UNIX_
this:fd:=fdup(this:fd,inheritflag,.t.)
#else
this:fd:=hdup(this:fd,inheritflag,.t.)
#endif
*/

Igy kommenteztem ki, s nem figyeltem hogy a fordito hibat jelentett a kommentre. Kijavitottam erre:
/*
* #ifdef _UNIX_
* this:fd:=fdup(this:fd,inheritflag,.t.)
* #else
* this:fd:=hdup(this:fd,inheritflag,.t.)
* #endif
*/
Igy problema nelkul forditotta. Erdekes, hogy egy masik gepen az elso verziot is jol forditotta. Szamomra ??? .

A websrv ujra forditasa utan most ilyen hibat kapok:

ALERT
Operation: select
Description: argument error

default error block evaluated
errorclass: error
operation: select
description: argument error
args:{ARRAY length=2 oref=5943b0, NIL, NIL, NUMBER 10000}
called from deferror(215)
called from _blk__2(0)
called from select(0)
called from main(337)

Stack
....................................
***** function _blk__2
20: BLOCK oref=NULL
21: OBJECT subtype=4 oref=594ab0
***** function deferror
22: OBJECT subtype=4 oref=594ab0
23: FLAG .T.
24: NUMBER 5
25: STRING length=45 oref=594d50 "Operation: select;Description: a ... "
26: ARRAY length=1 oref=594c60
27: NUMBER 1
-----------------------------------------------------------

Kiakad socketra várakoztásnál, hibás argumentum miatt. ???

Összezagyváltad a dolgokat. A kikommentezés az első módon is jó, de a legjobb így: 


//this:fd:=hdup(this:fd,inheritflag,.t.)

Nem összetartozó könyvtárakat linkelsz. Ez látszik a hibaüzenet 


called from select(0)

sorából, ahol a 0 azt mutatja, hogy a select egy C primitív, holott egy ideje a select is CCC-ben van éppen azért, hogy ne csak socket descriptorokra, hanem socket objektumokra is működjön. Ha összekeveredtek a dolgok, legjobb, ha az egészet letörlöd, és újrainstallálod a semmiből.

--
CCC3

Hat valami akkor sem klappol. Van ket CCC3-os.
Az egyik ugy 2007.aprilis + svn checkout 2008.januar 26. A clean-all.bat utan install.bat-tal ujraforditva.
A masodik 2008. januar 28.-i svn checkout teljesen uj /ures/ CCC3 lehuzva. Az install.bat-tal leforditva.
A keletkezo binarisok hosszaban kisebb nagyobb kulonbsegek vannak. A mingw fordito es az op.rendszer viszont mindket esetben azonos.

Vissza a websrv-hez. A hdup kivettem a megadott metodusbol, leforditottam a masodik CCC3-sal. A websrv hiba jelentes nelkul elindul. A halozatra 0.0.0.0 forras IP-vel (?) es 8080-as porton lep ki. A bongeszoben nem jelenik meg semmi.

Az s.bat hasznaltam inditasra. A C:\temp\websrv ala a htdocs,script,webcon konyvtarakat masoltam. A cgi-bin konyvtarba az cgi-bin alatt leforditott cgi.exe allomant masoltam. A /usr/bin/php-cgi konyvtar nalam nem jott letre. S pillanatnyilag nem is latom hogyan tudnam letrehozni.

A segitsegedet tovabbra is koszonom

scg