Szia!

> Egy html lapon az eger kurzor egy gif vagy jpg kep folott van, akkor
a
> bongeszom valamilyen hangot jatszon le ( wav, midi ), de csak akkor,
> amikor a kep fole er az eger es csak addig, amig a kep folott van.
> Megoldhato ez???!
Szerintem igen.

Ha jobb otletet nem kapsz, akkor tegyel fel egy onallo keretet, aminek
a
hatterzeneje a hang. Ha a kep fole ersz, akkor el lehet inditani egy
JavaScript-et,
ami betolti a framebe a html-t, aminek a hatterzenejet lejatszhatja.

Szerintem IE 3.0-ba es NC 3.0-ba is mennie kellene.
----------
Mic (Krizsak Laszlo)
UIN: 5471019
mailto:
http://w3.datanet.hu/~micsoft
(Az ekezeteket is ismerem :-)

Udv!
A szamomra legegetobb kerdest teszem fel - a bongeszok ezer eve ismerik a
Progressziv JPG-et (Valamikor meg a NN 1.12 volt az utolso, aki nem volt
kepes kezelni) - erre most ugy latom, hogy WIN95 + IE4 platformon abszolute
semmi nem latszik beloluk - egy rahedli web oldalam igy
hasznalhatatlan.......


Kuvari Tamas

Hello!

> Felado :  [Hungary]
> 
> eltarolja a legutobbi 10 keresesedet. A gonoszabbak (pl.
> alt.doubleclick.net) abbol elnek, hogy a te gepeden nyomon kovetik, hogy
> milyen hirdetesre szoktal kattintani, aztan olyan jellegueket mutatnak
> Neked. Ez utobbit nehanyan nem kedvelik, innen jon a cookie-gyulolet.

Ez igy imho megteveszto. Nem a te gepeden kovetik nyomon, ez ugy hangzik,
mint egy vad kemtortenet. A doubleclick.com fele sutigyar mindossze az
aktualis cookie kepessegeket hasznalja ki igen ugyesen. Ez nem tobb,
minthogy egy HTTP keresnel a szerver automatikusan egy kis infot kuldhet,
valamint a kliens is automatikusan elkuldi a mar tarolt, adott szerverhez
tartozo cookie infot a szervernek. A szerver es klien minden egyes
lekeresnel cookie-t cserelhet, de ez gyakorlatilag egy string informaciot
jelent. A sutik engedelyezesevel meg nem kell arra szamitani, hogy egyszer
megjelenik a gondolatrendorseg.. :)

udv,
-- 
Boca  -=> http://winnie.obuda.kando.hu/~boca/ <=-  Bo'cz Pe'ter

Szabolcs irta:
> problemairol, annak ellenere, hogy a ceg a csod szelen van es 400
> embert elbocsajtottak, legalabb valaszolnak a kerdesre, ha nem is rogton,

Azert ez eros tulzas. Ha szamitasba veszem, hogy milyen gyorsan fejlodott a
ceg gyerekkoraban, meg nem esek ketsegbe 400 ember elbocsatasatol. En ugy
latom, hogy ez pont az esszerusites jele, es mint ilyen nem fogja csodbe
juttatni oket. Legalabbis drukkolok nekik. Na nem azert, mert imadom oket,
hanem mert igy legalabb fent marad egy egeszseges verseny a bongeszok
piacan. Regen rossz lenne, ha csak egy dominans bongeszo maradna. Sot,
megkockaztatom, hogy a MS-nak is jot tesz a verseny. Latjuk, milyen dolgokat
kepesek produkalni monopolhelyzetben (pl. win95, stb.) es mit kemeny
versenyben (pl. IE4, ami mar megjarja).

udv,
-- 
Boca  -=> http://winnie.obuda.kando.hu/~boca/ <=-  Bo'cz Pe'ter

A süti - angolul cookie - egy olyan információ, amelyet a szerver a HTTP
válasz fejlécében helyez el, és amelyet a kliens ettől kezdve egy ideig
minden egyes HTTP kérés fejlécében elküld a szervernek. A szerver
megadhatja azt az URL tartományt, amelynek a sütit el kell küldeni,
illetve megadhat egy időtartamot, ameddig a süti érvényes. Ennek
lejártakor a kliens elfelejti a sütit, és nem küldi többet a szervernek.
Egy szerver megadhat több sütit egyszerre, vagy egymás utáni HTTP
válaszokban. A kliens oldalon pedig lehetnek több szerverről kapott
sütik is. A szerver által megadott tartomány vonatkozhat például csak a
szerverre. Ebben az esetben a kliens a sütit csak az adott szervernek
küldi el a további HTTP kérésekkel, de ha egy másik szerverről kér le a
böngésző információt, akkor annak nem küldi el a sütit. De küldhet a
szerver olyan sütit is, amely a szerver csak bizonyos részeire
vonatkozik, például a /scripts alkönyvtárra, ebben az esetben a kliens
csak a CGI scripteknek fogja elküldeni a sütit, ugyanezen szerveren a
statikus Web oldalak lekéréséhez nem. Viszont lehetőség van arra is
sajnos, hogy olyan tartományt adjon meg a szerver, amely alapján a
kliens az egyik szervertől kapott sütit egy másik gépnek is elküldi. Ad
abszurdum, az is elképzelhető, hogy a programozó lustasága miatt olyan
tartományt ad meg a szerver, hogy azután a kliens a sütit annak
lejáratáig minden gépnek elküldi.

A kliens minden olyan sütit elküld egy HTTP kéréssel, amely még nem járt
le, és a kérésben szereplő URL benne van a süti érvényességi
tartományában. Ez azt jelenti, hogy egy HTTP kéréssel a kliens akár
nagyon sok sütit is elküldhet, jelentősen növelve a HTTP forgalmat,
esetenként feleslegesen.

A sütik kezelése a felhasználó számára láthatatlan.  Ha csak nem veszi
valaki magának a fáradtságot, hogy szövegszerkesztővel beleeditáljon a
megfelelő böngésző fájlokba, akkor a böngésző nem mutatja meg, hogy
milyen tartalmú, lejáratú és tartományú sütit küld a HTTP kéréssel a
szervernek, illetve, hogy az egyes szerverektől milyent kap. Emiatt és
azért, mert a szerver által meghatározott tartományra nincsen megkötés a
Netscape ajánlásában, a sütik komoly biztonsági rést jelenthetnek.
Persze csak akkor, ha valamilyen szerveralkalmazást igénytelenül írnak
meg, és nem figyelnek a felhasználó biztonságára.

Példaképpen tekinthetjük az Internetes áruházakat, mert éppen ezek
között volt, vagy talán van is néhány olyan, amelyet hanyagul
készítettek el, és emiatt a vevőik kerültek veszélybe.

Egy Internetes áruház használata során a felhasználó több lapon halad
keresztül, miközben a virtuális kosarába rak megveendő árukat. Annak a
nyilvántartása, hogy egy vevő kosarában milyen áru van és a vevő
azonosítása általában sütikkel történik. A megoldás az lehet, hogy a
vevő kap egy azonosítót, amelyet automatikusan a szerver generál
vigyázva arra, hogy egy azonosítót ne adjon ki kétszer, és ezt elküldi a
kliensböngészőnek. A vevő kosarában levő árukat egy adatbázis tarthatja
nyilván, amelyben minden vevőhöz tartozik egy vagy több rekord tárolva
az eddigi vásárlásait, a hitelkártyaszámát, nevét, szállítási címet stb.

Persze ez a szerver oldalon komoly erőforrást igényel. Az áruház
üzemeltetője számára olcsóbb, és a programozók számára kényelmesebb, ha
ezeket az információkat mind belepakolják a sütikbe, és keresztül küldik
a hálózaton. Ekkor nem kell adatbázisban keresni a felhasználói
azonosító alapján, hanem minden rendelkezésre áll a sütiből. És a
hitelkártyaszámot lehet használni vevői azonosításra, hiszen az biztosan
egyedi. A vevő pedig mit sem vesz észre a dologból, legfeljebb egy
kicsit lassabb lesz a kommunikáció. Ezért ez a megoldás nem igazán
elegáns. És esetleg minden egyes alkalommal a hitelkártya száma is
átmegy a hálózaton. Ezért ez a megoldás nem igazán biztonságos. És ez
még nem minden. Volt a hálózaton olyan bolt, amelynek programozói
mindezen merényletek mellett még arra is lusták voltak, hogy rendesen
beállítsák a sütik érvényességi tartományát, így a vevők a bolt
meglátogatása, és egy esetleges vásárlást követően - amikor is megadták
a hitelkártya számukat - minden meglátogatott Web szervernek elküldték
ezeket az információkat. Ezért ez a megoldás egyáltalán nem biztonságos
:-)

Semmi kulonos csak erdekessegkeppen az oldalam utolso 5 nap latogatasanak megos
zlasa bongeszok szerint. A Netspace meg vezet. Nem rossz az MSIE4. Mindkettonek
 van gondja. De. Ha az MSIE4 bedoglik, magaval rantja az asztalt is. Erdekes, h
ogy az MSIE3-et meg mennyien hasznaljak, ez biztosan a kliens gep miatt. Na ja 
nem mindenkinek telik P200-asra meg xGb vinyora. Ott meg menne a Netscape 3 is,
 de szerintem erosen belejatszik, hogy a Netscape-nel nem magyar nyelvu a bonge
szo.

Internet Explorer 3.01 (1)     
Internet Explorer 3.02 (11)     
Internet Explorer 3.0B (5)     
Internet Explorer 4.0 (16)     
Internet Explorer 4.01 (3)     
Navigator 2.0 (1)     
Navigator 3.04 (1)     
Navigator 4.02 (1)     
Navigator 4.03 (31)     
Navigator 4.04 (36)     
Navigator Gold 3.0 (2)     
Navigator Gold 3.01 (1)     
Navigator Gold 3.04 (2)

Hello!

On Sat, 21 Mar 1998  wrote:

> A rendszer egy Sulinetes LAN, a server egy NT, a kliensek vagy
> Win95-k vagy WinNT-k. Az Internet-re a server-en keresztul
> kapcsolodunk egy ISDN vonalon. A server a proxy, igy fizikailag
> megkerulhetetlen (?). A proxy a magyar cimek, a heureka, a
> microsoft.com es meg vagy 2-3 cim kivetelevel mindent visszadob.
> A feladat a proxy megkerulese lenne.
Mivel helyi proxyrol van szo, tenyleg a rendszergazdaval kell targyalnod.
Mellesleg a helyi proxy folott meg ott van a sulinetes proxy, es azt hiaba
kerulod meg, ui. anelkul semmit se fogsz elerni. Amig a mi halozatunkon be
nem konfiguraltam legalabb a klienseket a sulinetes proxyra, semmit se
lattunk...


     Press any key to continue, any other key to quit...
+-----------------------------------------------------------\
|  Ferenc Bajan                     listowner of Musica-L   \
|                                        \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Hello!

On Mon, 23 Mar 1998, Baksa Zsolt wrote:

> Tisztel webmesterek
> 
> Szeretnem a majordomo listakezelot a
> szerveremre feltenni.
> Linux Slackware -t hasznalok, de
> gondolom ez nem baj.
> Perl : 5.003, Majordomo : 1.94.4
En a perl 5.004-1-et, de ezen mar semmi se mulik.

> Erre azt irja :
> :  is not a
> valid
> return address.
Ez nekem is igy volt, de ennek ellenere a majordomo megcsinalta a config
fajlt a listahoz...

     Press any key to continue, any other key to quit...
+-----------------------------------------------------------\
|  Ferenc Bajan                     listowner of Musica-L   \
|                                        \
\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\