Nahlédněte i do Diskuse pod čarou!

Čeština do serveru ICS

Server, ktery pouzivame je ICS od IBM. Na cestinu integrovanou do jeho vlaken jsme pouzivali jiz versi 4.1, ted prave pouzivame versi 4.2. Tento WWW demon byl zvolen pro jeho velkou propustnost, spoustu zajimavych konfigurovatelnych vlastnosti, multiplatformovou dosazitelnost (pres Un*xy, OS/2 az Win'95 a WinNT) a zejmena pro moznost prepisovat prubeh zpracovani dotazu. Tato schopnost je vyuzita i pri zpracovani pozadavku s patricnou cestinou.

Hlavni prednosti?

• Dokumenty s diakritikou jsou na strane serveru pouze v jedne zvolene kodove sade, server provadi jejich automaticky preklad.
• Vysoka mira konfigurovatelnosti serveru neni nijak omezena
• Jednoducha administrace-web masteru ani nepripadne ze nabizi sve stranky hned v nekolika kodovych sadach
• Cachovani jiz jednou dynamicky prelozenych stranek, neprovadi se neustale porad dokola preklad casto pouzivanych dokumentu/stranek. (volitelne)
• Zjednoduseni psani CGI skriptu podporujicich vsechny kodove sady cestiny
• Mimoradny vykon a propustnost
• Vse integrovano do serveru a overeno, ze hacker nemuze teto implementace cestiny nebo chyb v ni vyuzit k pruniku do serveru !

Jak to funguje?

• Predne je treba rict, ze preklad se provadi dynamicky. Zpracovani dotazu na strane serveru se deli na nekolik fazi. Vsechny tyto faze dovoli ICS libovolne nahradit nebo doplnit. Zjednoduseny prubeh zpracovani je: Zjisteni patricneho objektu prislusejiciho dotazu (dokumentu/CGI skriptu/vlaknove obsluhy) - povoleni pristupu k tomuto objektu (autorizace) - jeho vraceni uzivateli do socketu. Nas zpusob integrovani cestiny doplni prvni krok (mapovani) o zjisteni jakou cestinu uzivatel pozaduje (tj. URL ma za nazvem serveru pozadovanou kod. sadu /us/, /unix/ nebo tam tato informace neni-pak preklad probehne do ascii) a nastaveni patricnych vstupne vystupnich kodovych tabulek k uzivatelove socketu. Pri poslednim kroku nastavene vystupni tabulky filtruji odpoved do patricneho kodu cestiny. Nastavene vstupni tabulky jsou pouzivany pro CGI skripty, ktere filtrem pres ne ziskavaji jednotnou cestinu (na OS/2 napr. cp852, ale neni problem rici, ze CGI scripty by radi radsi cp1250-to je ciste vec konfigurace) se kterou se pak jiz velmi dobre pracuje, nebot neni treba zjistovat v jake cestine byly data zaslana. Samozrejme ze CGI script ani netusi ze je nekde nejaky filtr, nebot ten je schovan primo do serveru. CGI si tedy mysli, ze vsichni mu posilaji data v te jeho cestine na kterou byl naprogramovan.

Jak se to pouziva?

• Velmi jednoduse. Do konfiguracniho souboru ICS se doplni 5 radku a neni jiz treba nic vice. Neni treba psat mapovaci pravidla po kazdou kodovou stranku. Pokud totiz nase mapovani (viz vyse) objevi, ze v URL je skryt pozadavek na kodovou stranku cestiny, tuto informaci z URL odstrani, a necha server najit patricny dokument podle pravidel v konfiguracnim souboru serveru (Exec/Pass pravidla), ktere by server k namapovani na patricny objekt normalne pouzil, pokud by se nemusel starat o cestinu. Pokud se naopak filtruje CGI skriptem, jak nektere jednodusi zpusoby implementace cestiny do HTTPD nabizi, nema web-master tuto flexibilitu a volnost. V nasem reseni muze klidne pouzivat pravidla Exec/Pass zcela libovolne jakoby se jeho server ani o cestinu nemusel starat. To jest ma stejne problemy jako web-master v Americe, Nemecku atp., ktery sve stranky nabizi pouze v jedne kodove sade, tj. ma problemy pouze s informacemi a jejich presentaci, nemusi se starat o nic vic!

Rychlost a vykon?

• Toto reseni nebrani serveru provadet cachovani dokumentu podle pozadavku web-mastera (jeho pozadavky jsou uvedeny v konfiguracnim souboru HTTPD). Takze nektere dokumenty nejsou porad dokola prekladany do patricnych znakovych sad dynamicky, ale pouziva se jiz jednou dynamicky prelozeny dokument. Pokud se ale prislusejici dokument na disku zmeni, neni jiz pouzivan nacachovany dokument, ale provede se znovu preklad. Tim se samozrejme mimoradne zvysuje vykon. Na kazdy odesilany byte dokumentu typu 'text' (tj. text/html, text/x-ssi-html atd) je potreba v prumeru asi 1-3 tiky procesorovych hodin, ostatni dokumenty (jako treba obrazky) nejsou prekladany vubec, cimznezpusobuji vubec zadnou dodatecnou zatez. Tudiz zvyseni zatizeni procesoru na strane serveru je absolutne mizive, ba zadne (nebyli jsme schopni zmerit). Propustnost pri velkem zatizeni je obrovska a nijak nezpomaluje server. Nepodarilo se nam pri testech transferu nekolika desitek MB z HTTPD zjistit sebemensi pokles propustnosti (ani 1% !!!!). Nase reseni ani nealokuje dalsi zdroje, pouziva pouze ty, ktere jiz server alokoval pri svem startu! Zatim se nam nepodarilo objevit stejne vykone a konfigurovatelne reseni na ceskem internetu, coz muze vychazet z toho, ze jsme spatne hledali, ale to jiz posudte sami...

Vice jazyku na HTTPD?

• Dnes jiz HTTPD nabizi moznost rozliseni toho, jaka stranka se bude vracet, v zavislosti na typu browseru a pozadovanem jazyku. Se vsemi temito novymi vlastnostmi HTTP, je toto reseni plne kompatibilni, pricemz opet nesnizuje vubec konfigurovatelnost. Opet se uplatnuje vyhoda toho, ze web-master ma vlastne jen jakoby jednu kodovou sadu cestiny na strane serveru, v niz ma sve dokumenty, a server se mu postara o jejich dynamicky prevod do uzivatelovy kodove stranky. Nevznika tak mismas, kdy ma web master na svem serveru vlastne 'jakoby' nekolik jazyku- a to 'anglictina', 'nemcina' a pak 'cestina latin2', 'cestina kamenici', 'cestina windows 1250'...

Co to umi pro uzivatele navic?

• Web-master muze uzivateli nabidnout moznost prepnuti na LIBOVOLNE STRANCE do libovolneho kodu cestiny PRIMO. Nebo muze nabidnout PRECHOD na stranku, kde si po vyberu z nabizenych kodovych stranek a jejich ukazek sam uzivatel muze zvolit, ktera znakova sada odpovida jeho pouzivane diakritice. Po takovemto vyberu je uzivatel opet VRACEN NA STRANKU, ze ktere ODESEL, aby si zmenil kodovou stranku dokumentu. Avsak po navratu se jiz nachazi ve sve zvolene KODOVE STRANCE!

Kdo to nyni pouziva?

• Tento novy produkt zatim pouziva http://com-os2.ms.mff.cuni.cz (server KSVI bezici na OS/2 Warp serveru) a http://www.jobs.cz (komercni server). Nas tym ma prime napojeni na vyvojovy tym IBM, takze se da predpokladat, ze sebevetsi novinky v oblasti HTTP serveru nas ani v bodoucnu neprekvapi.

S pozdravem
Leo Galambos
OS/2 Warp server supervisor
http://com-os2.ms.mff.cuni.cz