Beware of XHTML
Érvek az XHTML helytelen használata ellen
■ 
Friss blogmarkok
- Web Akadálymentesítési Útmutató (WCAG) 2.1 – nyilvános munkaterv – Megjelent a WCAG (Web Akadálymentesítési Útmutató) 2.1 nyilvános munkaterv (0)
- MongoDB Apocalypse Is Here as Ransom Attacks Hit 10,000 Servers – Több tízezer védtelen MongoDB szerverre csaptak le hackerek (2)
- 12 Signs You’re Working in a Feature Factory – A cél nélküli funkciógyártás néhány tünete (0)
- Translatable, custom dates in Twig templates of Drupal 8 – Saját dátumok megjelenítése, fordíthatóan a Drupal 8 smink rétegével dolgozva (0)
- NativeScript – Cross-Platform Native Development with Javascript – Fejlesszünk natív mobilalkalmazást JavaScripttel (0)
- GitHub Security Update: Reused password attack – Érdemes bekapcsolni a kétfaktoros azonosítást, ha a GitHub jelszavunkat más oldalakon is újra felhasználtuk (17)
- UX Design könyv – Hogyan tervezz felhasználóbarát és szerethető alkalmazásokat? (0)
- Introducing unlimited private repositories – Megváltozik a GitHub díjszabása: minden előfizetéshez korlátlan számú privát repository jár (0)
- Drupal 8 Twig: add custom CSS classes to menus (based on menu name) – Saját elképzeléseink szerinti CSS osztályok (automatizált) hozzáadása a Drupal 8 menüihez (0)
Cikkajánló
RajcsanyiZ:
Hierarchikus adatkezelés SQL-lel PHP-ben III.- Poetro:
JavaScript függvények 
Hodicska Gergely:
Karakterkódolási problémák kiküszöbölése
Friss csiripek
Csiripek betöltése…
Aktív fórum témák
Új fórum témák
Archívum
| H | K | Sze | Cs | P | Szo | V |
|---|---|---|---|---|---|---|
| 30 | 1 | 2 | 3 | 4 | 5 | 6 |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 | 1 | 2 | 3 |
a doctype ezek szerint nem számít?
"When a web browser sees the text/html content type, regardless of what the doctype says, it automatically assumes that it's dealing with plain old HTML."
Ha jól értelmezem a cikket, a webszerver a tárhelyen lévő lapomat text/html-ként küldi a böngészőnek. A böngésző ha így kapja, nem foglakozik a doctype-pal és simán HTML-ként kezdi feldolgozni a dokumentumot.
Hiába írom , hogy <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN">
az egész semmit nem ér? ... nem így tapasztaltam. Valami sántít a cikkben. ... vagy valami infó hiányzik, ami alapján értelmezni tudom.
... de ha így is van, mi értelme van ennek? Ha a content type text/html, miért gátolja meg ez a browsereket abban, hogy észrevegyék a doctype-ot, és ezek után már XHTML-ként foglalkozzanak a dokumentummal? Hihetetlen gagyiságnak tűnik ez nekem.
csatlakozom
nem gyagyiság
Az XHTML Media Types dokumentum írja le, hogy mit hogyan kell kezelni. A lényeg, hogy ha text/html-ként küldesz egy XHTML dokumentumot, akkor a böngésző mindenképpen standard HTML-ként fogja kezelni. Azért küldted úgy, mert ezt akartad; ha mást akarsz, akkor az XHTML saját típusát kell használni (*). A neked legérdekesebb rész a text/html kiszolgálásról többek között ezt írja:
A DOCTYPE nem azt mondja meg, hogy HTML vagy XHTML dokumentumról van szó, hanem hogy a MIME típuson túl milyen struktúrát várjon el a böngésző, a HTML illetve XHTML melyik verzióját, stb.
(*) Sajnos nem olyan egyszerű mást akarni, mert az Internet Explorer 6 nem támogatja az XHTML MIME típusát és az IE 7 sem fogja.
well-formedness errors may not be detected by user agents
Csak egy hibaüzenet, sárga alapon piros betűk (FF), vagy nagy ERROR felirat (Opera) ami a felhasználók 99%-ának számára nem csak, hogy érthetetlen, de érdektelen is lesz.
Kicsit fázom ettől, hogy a gyakorlatban mennyire vállalható ez. Okéoké, van tidy a világon, de azért bátor ember legyen a talpán, aki erre rábíz majd mondjuk egy portálrendszert, ahol minden egyes aloldalnak - amit mondjuk az ügyfél is töltögethet akár wysiwyg editorral -, jól formázotnak kell lennie.
Merésznek tűnik ez még nekem, nem igazán tudom mit gondoljak... Valahol ez nagyon sérülékeny modell, amiből teljesen hiányzik a hibatűrés, amihez szerintem már kezdünk nagyon hozzászokni. Nem tudom, hogy hosszú távon kinek származik majd ebből előnye.
Nyilván idióta a példa, de kicsit olyannak érzem, mintha egy mp3-ban pár byte rosszul jön át és mondjuk egy pattogás helyett az egész számot nem lehet meghallgatni... :/
szerintem ez igen rossz irány
De vissza arra, hogy szerintem mi a rossz irány: ha én a szerverre feltöltök egy dokumentumot, az egy fájl. Szerintem igen nagy butaság, ha ezekután még a szervernek külön headerekkel meg kell adnom, hogy a fájl voltaképpen mi is. Ez igen megnehezíti a szerverek közti hordozhatóságot. Szerintem a fájl tartalmának kell mindent meghatároznia, a mime típust, az xml altípust, vagy akármi mást. Más elgondolás egyszerűen nevetséges macerás gagyi (SZVSZ).
... egy időben a fájnév határozta mag a fáj típusát, aztán rájöttek, hogy jobb, ha a fájlon belül elhelyezett header-rész írja le a fájltípust, és ez sokkal korrektebb megoldás. Nem értem, miért kellett, hogy a webes transzer protokolloknál mást találjanak ki. (így is-úgy is digitális jelfolyam, de ha elszakítjuk a fájltól/dokumentumtól az értelmezéshez szükséges header/leíró részt, felesleges macerának vetjük alá magunkat.)
És: én örülnék neki, ha a "mágikus detektálás gagyiság" -- ha az a dokumentum részeként megadott header értelmezését jelenti (mindegy, hogy kliens, vagy szerver oldalon) -- mindenhol elterjedne, és lenyomná a mostani felesleges előheaderezést.
örülnél a mágikus detetálásnak
A szerveren múlik, hogy hogyan állapítja meg azt a MIME típust, amit kiküld. Az Apache szerver például a mod_mime modulban a fájl kiterjesztésekhez rendel MIME típusokat, és a mod_mime_magic modulban nézi a fájlok első bájtjait, megpróbálva felismerni a valódi formátumot függetlenül a kiterjesztéstől. Ezek igény szerint beállíthatóak. Ha valamilyen szerver oldali nyelvet használsz, akkor abban meg tudod adni, hogy milyen tartalom típus fejlécet küldjön vissza a kliensnek, és ez arra kell hogy épüljön, hogy a kliens jelezte-e, hogy minek a fogadására képes. A kliensnek az az alapvető kötelessége, hogy a kapott adatot a kapott MIME típus alapján kezelje. A web így lett kitalálva; ahol ettől eltértek, az többnyire biztonsági résekhez vezetett, és folyamatosan tömik be ezeket a lyukakat.
egyetértek, kell fejléc
miért kéne a bináris fájloknál?
"hogyan tudom megcsinálni, hogy ne betöltse a word doksimat, hanem letölthető legyen?" -- na erre sem kell header. Ha van is, csak annyit szabad, hogy jelezzen, hogy a szerverre aki felrakta, milyen feldolgozás-indítást javasol, de ennek is felülbírálhatónak kell lennie kliens oldalon, ez alapvető biztonsági problémákhoz vezetne, ha nem így lenne.
De itt is nevetséges, hogy a macerás headerezést választották megoldásnak, és remélem ez is kikopik előbb-utóbb, hiszen sokkal megfelelőbb ha szétválasztjuk a tartalmat és a javaslatot a feldolgozás megkezdésére és ez utóbbit máshogy, máshol jelezzük: például úgy, ahogy a popup ablakok megnyitását, a dokumentum vezérlést indító részben, a helyén, a link mellett, a (X)HTML leíróban. Vagyis mivel ennek végképp semmi köze sem a fájl tartalmához, sem a feldolgozási információkhoz, ez tökéletesen elkülönítve érdemes kezelni a dokumentum nyitásához illeszkedő kliens oldali javaslat formájában.
Röhelyes, hogy egy fájlhoz plusz headereket kell illeszteni, hogy értelmezni lehessen, minden ilyet ki kell koptatni. (Az olyan fájlformátumokat, amik nem a netre valók, meg kell változtatni, vagy egyértelműen "nem netre való"-ként kell kezelni) Az pedig még nevetségesebb, hogy ugyanezt a szerver próbálja kitalálni, amikor ez tartalmi feldolgozási kérdés. Múljon el hamar!
hibás mime tipus
Az, hogy egyes fájltipusok a böngészőben jelennek meg letöltés helyett pedig nem mérnöki probléma, hanem az illető gyártól puszta üzleti döntése, ami kivétel nélkül minig rosszat tesz a web fejlődésének.
miért, a cikkben nem ez történt?
Butaság, hogy a szerveren múlik, milyen headert ad és az próbálja kitalálni a fájlnév alapján -- vagy a fájlok első bájtjai alapján, mikor a fájl készítője egyértelműen valamilyen célra gyártja a tartalmat és ezt jelezni is képes a header részben (pl. a doctype deklarációban)
Miért kötelessége a kliensnek, hogy a szerver által adott MIME típus alapján kezelje az adatokat? Szerintem pont ez ami veszélyes.
A helyzet fordított: nem a szerver adja az adatokat, hanem a fejlesztő, és a böngésző kéri azokat. Pont az a veszélyes, ha valamit kérek, mást kapok és még köteles vagyok a kapott formátumot feldolgozni. Pont ez vezet ahhoz, hogy jpg-t kérek és veszélyes kódot kapok --- és még felül sem bírálhatom? Ugyan... Ugye látható, hogy ez a veszélyes, nem?
A felesleges headerezés ráadásul nemcsak, hogy macerás, de más szerver környezetben más működést is eredményezhet, ami szintén megoldható lenne, ha a feldolgozáshoz szükséges infó a fájlban tárolódna. Kicsit más a helyzet az átvitelhez szükséges, vagy a feldolgozás indítását kezelő információkkal, ezeket nem kéne összekeverni, de ezt a köv. postra reagálva írom, alább.
nem típust kér a böngésző, hanem URL-t
A HTTP kérésben nincs benne, hogy a böngésző milyen MIME típusú dolgot kért. Az van benne, hogy mi a webcíme az entitásnak amit kért, és különben milyen MIME típusú dolgokat képes fogadni a kliens. Igenis a szerver adja az adatokat. Nem kapsz mást, mint amit kértél, mert nem kértél konkrét MIME típust.
A szerver dolga eldönteni, hogy az adott entitás a lehetséges MIME típusok valamelyikével plusz a böngésző által adott nyelvi preferenciák (magyar, angol, német, francia stb), plusz a böngésző által adott folyam tömöríthetőség (pl. gzip) stb. alapján hogyan érhető el. A szerver megkísérli a lehető legjobban kiszolgálni a klienst, hogy olyan adatot adjon neki, amit fel tud dolgozni, azok alapján, amit a kliens a saját képességeiről állít.
A kliens a képességeit írja le, nem pedig azt, hogy mit kér konkrétan, hiszen azt nem tudhatja. Honnan tudja a böngésző, hogy egy URL most XHTML, HTML vagy TXT információra mutat, ha mondjuk ennyi, hogy http://google.com/. Hol van ebben elrejtve mindez az információ? Sehol! Jobb lenne, ha benne lenne? Hogyan lehetne benne? Rossz ez a modell?
hiszen persze hogy rossz
Igen, a HTTP kérésben nincs benne, hogy milyen MIME típust kér, de nem arról beszéltem, ami most van, hanem arról, hogy hogyan lenne jobb.
(Ne csak azt nézd, ami most van és ne csak azt, hogy miben nincs igazam -- előre kell tekinteni: miért is nem jó a mostani? hogyan lenne jobb? erről írtam.)
A szerver dolga lehet eldönteni az adatátviteli folyamatot, de nem az adattartalom feldolgozási módját, ahogy sokszor most teszi. (Néha azt is írhatod, hogy egyetértesz) A cikk pont arról szólt, hogy a tartalom feldolgozási módjába szól bele (szerintem feleslegesen) a content type. Te itt most más szerver feladatokról beszélsz, ami logikus is. Pl. ha a kliensnek létezne nyelvi preferencia listája, és a szerver ebből választana a meglévők közül, az érthető, de a leküldött dokumentum feldolgozási módjához (és így a "fájl" headerjéhez) semmi köze, nem kéne beleszólnia.
A kliens igenis leírja, le kell írnia konkrétan, hogy mit kér, minél konkrétabban, annál jobb. Ezt teszi, amikor pl. egy jpg kiterjesztésű fájlt kér: ezzel jelzi, hogy mit kér. Szomorú, hogy a típus meghatározásához a kliens csak a fájnévben tudja közölni, hogy mit szeretne.
Az más kérdés, ha a kliens nem tudja pontosan, hogy mit is szeretne. Ebben az esetben is el kell különíteni azt a folyamatot, hogy "mit tudok szolgáltatni" "kéred-e" és hogy mi a végülis leszállított fájl tartalma és szorosan ehhez tartozóam a feldolgozási módja. (Igen, ennek kb így kellene történnie: a kliens elmondja hogy milyen címről kér valamit, ami legyen pl. magyar nyelvű, lehetőleg XHTMl. Erre a szerver aszondja, hogy HTML van csak és koreai. Kéred? A kliens pedig vagy kéri, vagy nem. Preferenciáktól függően akár a usert is megkérdezheti. Az itt elküldött kommunikációs elemeknek azonban semmi közük nincs a végül leszállításra kerülő fájlhoz és annak headerjéhez.)
És az is más kérdés, ha valami jön, de a szerver félreinformál -- ahogy a cikkből is kiderül. Nonsense.
feltételezzünk
- Kliens elküldené, hogy mit tud fogadni, és egy URL-t
- Szerver válaszolna, hogy mit tud adni (csak metainformációval)
- Kliens ebből kiválasztaná (akár felhasználói interakcióval), hogy mit kér
- Ezt megkapná.
Bár látszólag több önállóságot adna a modell a kliensnek, a szervertől kapott válaszokban továbbra is feltétel nélkül meg kellene bíznia. Biztos lehet benne, hogy ha a szerver azt mondja, hogy csak HTML van és koreai, akkor az tényleg HTML és tényleg koreai? Ez a javaslatod semmit nem változtat azon, hogy a szervernek kell felismernie, hogy milyen típusa van a fájloknak, hiszen csak úgy tud választási lehetőséget kínálni a kliensnek. Így az XHTML text/html-ként való kiszolgálásának problémáját sem oldja meg, pedig erről szól ez a téma itt.a lényeg hogy a doktípusba ne szóljon bele
1: a dokumentum kezelési leírása legyen a dokumentummal egy halmazban, ez legyen a dokumentum header. Ez a dokumentummal egyértelműen, egy fájlként kerüljön transzerálásra, minden esetben. Nem kell elé magyarázó header, felesleges, félrevezető lehet (ha ennek a plusz headernek a meghatározását a szerverre bízzuk, az tévedhet, vagy kiolvassa a fájl headerjéből, és azt küldi, ami felesleges, vagy nekem kell plusz foglalkoznom vele, ez meg már gagyi)
2: el kéne különíteni a dokumentum tartalmat és a kommunikációs protokollt, ami alapján a böngésző és a szerver megbeszéli, hogy mi legyen. Ezt ne nevezzük headernek. Szépen leírható ez pl. magában a html dokumentumban. A netes kommunikáció pedig minden esetben szabványos, a böngésző által értelmezhető dokumentumból induljon ki, pl HTML vagy XHTML dokumentumból, amiben jól leírható, hogy ki mit akar. Tehát ha a böngésző nem tudja, hogy mit kér, akkor csak HTML/XHTML doksit kérhessen és kaphasson. Ebben pedig leírható, hogy mi legyen pl egy worddoksival, XML lappa, stylesheettel, jsscripttel, képpel stb. Ha direkt linkelünk egyéb fájlokat, annak lényegében semmi értelme. (akkor már legyen FTP)
Nem kell megbíznom a szerverben. A szerver azt mondja, hogy koreait küld, de aztán mégis japán jön? Ha az én konvenciómat követjük, akkor a japán doksi headerjét nem módosíthatja a szerver, így abból kiderül, hogy nem koreai. A "koreait adok" megbeszélés csak a transzfer kezdetéig tart, a dokumentum leírása a dokumentummal együtt érkezik és aszerint dolgozza fel a böngésző, vagy utasítja el.
A szevernek csak azért kelljen felismernie a doktípust, hogy ilyen extra kommkérdésekre válaszoljon, nem azért hogy kikövetelje a dokumentum kezelési módját. A dokumentum és kezelési leírása legyen szuverén, sérthetetlen és összekapcsolt.
És még egyszer: az végképp nem jó, ha a doksi elején van egy header (doctype) aztán van egy másik, ami ugyanazt a célt szolgálja, de a doksitól függetlenül. Értelmetlen.
a HTTP nem csak HTML-t hordoz
Mivel te a HTTP visszaszorítását tartod üdvözítőnek a HTML-ben tárolt metainformáció javára (aminek lenne és van is létjogosultsága például asztali, azaz nem HTTP-n keresztüli megtekintés esetén), ezért az összes HTTP-vel küldött más formátumot is el kellene látni valamilyen belső metainformációs résszel, ami legalább a típusát azonosítja. Mivel a formátumok mind eltérőek, a böngészőnek minden kérésre kapott válasznál az összes lehetséges fejléc formátumot meg kellene vizsgálnia, keresnie a fájlban, és úgy azonosítania a fájlt.
Végső soron arra jutunk, hogy teljesen mindegy, hogy mi van megadva, úgyis a konkrét fájl formátuma döntené el, hogy a böngésző hogyan kezelje. Tehát ha elfelejtjük a Content-type fejléc információt, akkor a böngészőnek csak az marad, hogy maga találgasson az adott fájl formátumáról.
az alap az a html
"HTTP felett egy csomó formátum utazik, aminek nincs semmilyen belső metainformációja magáról" --- igen, nem is kell, mégis nagyon jól le lehet kezelni. A szükséges infókat a meghíváskor határozhatjuk meg. Miért kell a content-type? Ahogy írtad, akár a MIME típust is megadhatjuk, ez egy működő dolog. Nincs felesleges headerezés, stb. Működik! Frappáns!
Ahogy írtad, a content type nem elegendő arra, hogy részletes infót adjon... egyáltalán mire jó? Ha a videonál vagy a HTML verzió meghatározásánál úgyis bele kell nézni a headerbe, minek van a content-type?
A böngészőnek nem kéne meghatároznia a fájl típusát, az "összes lehetséges fejléc formátum" vizsgálatával, hiszen a böngésző kéri a bizonyos formátumot. Ugyanúgy, ahogy most a jpg-t kéri, a JS-t, meg a többit, de ezt már írtam.
"Egy hasonló modell most is működik, a JavaScript vagy CSS csatolásakor meg kell adni annak MIME típusát a böngésző számára a HTML kódban. De ez ugye pontosan annyira sebezhető, mint a szerver által adott fejléc, semmivel sem kevésbé biztosítható a megfelelő értéke."
Miért sebezhető? Van egy dokumentumom, amit épp nézegetek. Van benne egy JPG. Miért kellene ehhez content type header? Így is, úgy is vagy jpg töltődik le, vagy nem, a böngészőnek ellenőriznie kell. Ki kell olvasnia a headert -- meg az egész fájlt.
"Mennyivel jobb különben az, ha az összes egy adott fájlra linkelő HTML dokumentumban kell megadni, hogy az egy adott formátumú, mint ha az URL letöltésekor a szerver mondja meg?"
Mennyivel roszabb? Ugyanaz az infó jön le: vagy a html dokumentumban, vagy a szerver küldi le külön content type header formában, amit külön kell legenerálni (vagy téveset generál magától a szerver), odafigyelni rá... Ha egy olyan fájlt akarunk "beilleszteni" egy html dokumentumba, amelyik nem net-kompatibilis, nincs headerje, akkor a beillesztés előtt beírjuk a szükséges infókat (MIME típus, kódlap stb), tiszta sor. Ha pedig böngésző kompatibilis, semmit sem kell tennünk és nem lesz felesleges plusz header sem (és a fájllal együtt van a header).
"...a böngészőnek csak az marad, hogy maga találgasson az adott fájl formátumáról"
Egyrészt nem hinném, hogy a böngésző rosszabban találgatna, mint a webszerver. De nem kell találgatnia, már említettem 2(+1) eset van:
1: a doksi "net kompatibilis" headerrel rendelkezik (pl. doctype) - ekkor nem kellene már most sem a content type. Felesleges.
2: Nem rendelkezik ilyen headerrel -- ahogy manapság a JS,CSS fájlok, képek, avik stb. amelyeknek egy részéhez kell plusz infó, más részükhöz nem. Ha kell, akkor a html doksiban kell ezeket az infókat előre raktározni
(+1): A legelején, a szerverre csatlakozáskor a böngésző nem tudja pontosan, hogy milyen MIME típus jön le (google.com beírásakor) de már manapság sem jöhet le más, csak "net kompatibilis" doksi, ahol megintcsak felesleges a content type header...
Nem értek egyet a konklúzióddal. Csak némi kis változtatás kéne és könnyen meg lehetne szabadulni a content type headertől.
xhtml html xml
Azért az nem úgy van, hogy van a jóságos weblapkészítő, a jóságos böngésző és a gonosz szerverüzemeltető, aki gonosz header-eket állít be. :)
melyik fejléc?
"When a web browser sees the text/html content type, regardless of what the doctype says, it automatically assumes that it's dealing with plain old HTML"
Vagyis mégegyszer: azt írja, hogy ha a content type header text/html (amit a gonosz webszerver küld, annak ellenére hogy én, a fájl előállítója erre utasítanám) akkor süthetem a doctype deklarációmat, akkor is HTML-ként lesz feldogozva, nem XHTML-ként. Ezt írja a cikk, vagy nem?
Írod, hogy a "fejléc megadásával döntöd el" melyik fejlécre gondolsz? Szerintem jó lenne, ha csak egy lenne és akkor egyértelmű. Szerinted nem lenne jó?
xml xhtml html plain text
szerinted helyes
"utasítottad azzal, hogy..." tudom, hogy hogy működik és épp ezt nem helyeslem. Nincs lehetőségem egyetérteni vagy nem egyetérteni, csak úgy, ha feleslegesen foglalkozok a felesleges content type headerrel, ami felesleges, és zavarokhoz vezet, mert esetleg csak véletlenül passzol a tartalomhoz. Kettős headerezés, ugyanarról a dologról. Ne küldjön headert arról a tartalomról, amit én már meghatároztam. Felesleges és megtévesztő. Felesleges. Megtévesztő. Satöbbi.
"Nagyon helyesen, mert ekkor az XHTML fájlt...HTML-ként fogja értelmezni"
Neked helyes, vagy a protokollnak? Nekem nem tetszik ha a protokollnyavaja miatt félrekezeli a böngésző a dokumentumomat. A böngésző a weboldalt megjelenítő program és nem tehet arról, hogy vacak felesleges protokollhalmozással félrevezető infókat kap a doksi kezeléséről, ami nem is történne meg, ha a gonosz webszerver 1) nem is küldené el a téves headert 2) nem kényszerítene rá hogy fölösleges headerekkel vacakoljak 3) jól állapítaná meg a dokumentumtípust és/vagy csak akkor tenne headert rá, ha jó a protokoll, ami alapján meg tudja állapítani a dokumentumtípust.
Nekem ne működjön text-ként egy html ha azt akarom, hogy html-ként működjön. Ha html-t küldök, működjön html-ként, ha text/plain-t, akkor működjön textként. Ez utóbbi példádból is látszik, milyen felesleges kiküldeni a headert, főleg pedig nincs értelme text/plain headert küldeni egy html fájlhoz.
Biztos, hogy egy dokumentumnak csak egy típusa lehet?
Ott tévedsz, hogy úgy véled, hogy egy dokumentumnak csak és kizárólag egyféle típusa lehet. Ragaszkodsz ahhoz, hogy egy XHTML fájl csak és kizárólag xml dokumentum. Miközben egy XHTML fájl
- XML dokumentum is,
- HTML dokumentum is,
- TEXT dokumentum is,
- stb., stb.
Vagy egy javascript fájl alapértelmezetten application/x-javascript típusú, de kiküldheted plain/text ként is, ami máris mást jelent.
- Mi fogja eldönteni, hogy mégis miként akarod megjelenítettni a böngészőben a dokumentumot?
- Nem a kiszolgáló által küldött fejléc hivatott erre, hogy jelezd a böngészőnek, hogy ez a dokumentum ez és ez lesz?
- Így már világos, hogy miért a kiszolgáló által küldött Content-Type az elsődleges, és nem esetlegesen a dokumentumba épített. - Az előbbi szabadon - tetszés szerint, az alkalomnak megfelelően - megváltoztatható.
egy dokumentumnak csak egy típusa lehet
Egy dokumentumnak csak egy típusa van. Lehet aszerint kezelni és lehet máshogy.
Mondj egy dokumentumot, aminek több tipusként is van értelme értelmezni.
A MIME megadásának nem az a lényege, hogy a szerver módosítsa a típust, hanem azért keletkezett, mert eredetileg nem tudták máshogy közölni a browserrel (vagy az oprendszerrel), hogy az elküldésre (kezelésre) kerülő dokumentum micsoda.
Eltekintve egészen ritka esetektől, mindig a dokumentumot a típusa szerint akarjuk megjeleníteni.
"Mi fogja eldönteni...?" mindig a böngésző dönti el, most is az teszi, mivel a böngésző jeleníti meg. A szerver a content type headerrel csak javasol valamilyen megjelenítést. A cikk alapján realizálódott bennem, hogy az így kialakult kettős típusheaderezés milyen gagyi.
"Nem a kiszolgáló által..." sajnos manapság sokszor igen, és ez a hiba.
"Így már világos..." igen, természetesen számomra is világos, hogy jelenleg ez így van. És az is, hogy ez így vagy macerás, vagy felesleges, vagy gagyi -- de semmiképp sem jó. Márcsak azért sem, mert bár "tetszés szerint, az alkalomnak megfelelően megváltoztatható", a cikkből is kiderül hogy nem megfelelően kezelt, nehézkes és kétértelműségre ad lehetőséget (stb)
A kérendő és küldendő típuskezelés nem-headereel történő lekezelésének alternatívájáról és egyéb érveimről már írtam.
Remélem, ha egyszer véletlenül ezeknek a protokolloknak a fejlesztésébe beleszólási, döntési helyzetbe kerülsz, figyelembe veszed az én (és mások) alternatív véleményét is (remélem az újító szándék nem vétek) :-)
pl. forráskód
Mondj egy dokumentumot, aminek több tipusként is van értelme értelmezni.
Egy lehetséges helyzet, amikor többféle típusként akarod kezelni:
Képzeld el, amikor csinálsz egy demo oldalt egy ügyes javascriptnek, s mondjuk folyamatosan frissítgeted a js fájlt mögötte, s egy linket akarsz adni js-fájlra. Egyik esetben text/javascript mime-type-ra lenne szükséged (amikor a demo oldalon behívod a script taggal), illetve egyszer text/plain, amikor meg akarod mutatni a kódot.
Tegyük fel, hogy mondjuk korábbi verziókat is akarsz mutatni, ezért egy php fájl küldi ki a javascript fájl megfelelő verzióját, mondjuk js.php, ami két paraméterrel rendelkezik: verzioszam s source
a verziószám alapján választja ki, melyik verziójú fájlt includolja, s a source alapján, hogy miként akarod felhasználni: pl. ha 0, akkor scriptként akarod kezelni, ha meg 1, akkor a forráskódot akarod megmutatni.
máris több típusa van ugyanannak a fájlnak
ritka és nem tipikus
Megmutatni a kódot php-vel szebben is lehet, a plaintext csúnya. Értelmesebb, ha ilyenkor a php-vel beolvastatod, mint fájlt, gyártasz belőle egy szép html-t, és azt küldöd el.
És itt a lényeg: ebből is láthatod, hogy a content type headeres megoldásod csak ráerőszakolása a megjelenítésnek. Az igazi célod nem az, hogy egy fájlt kétféleképp elküldhess a böngészőnek, hanem a kétféle feldolgozás--és ilyenkor kétféle fájl is keletkezik, amit értelmezhet a böngésző: az első a tiszta JS script, a másik a jólformázott kódmegjelenítés html formátumban.
A content type-os megjelenítés a példádban csak azt reprezentálja, hogy hogyan használható valamilyen rossz protokoll mégiscsak valamire (minden rosszban van valami jó), de felesleges, csak kavart okoz.
nem állítottam, hogy tipikus lenne
Csak ennyit tettem
nem tipikust én is tudok
... de köszi, nem tettél semmi rosszat. ... De azért van igazság abban, amit írtam, ugye? (Senki sem mond semmi pozitívat a hozzászólásaimhoz, szomorú...)
:-)
.jpg link
A kiens az a bástya, ami még ellenőrizheti, hogy mi jön ki a csövön, és rákérdezhet, hogy akarod-e futtatni a kapott tartalmat (külső pluginnel, exec()-cel, vagy akárhogy).
A ".jpg linkjére kattintasz" amúgy sem reális. Én sose nézem meg milyen linkre kattintok, és az átlagos netező sem hiszem, hogy tudja a kölünbséget a jpg és az exe között. A böngésző feladata, hogy megkülönböztesse a veszélytelen és a potenciálistan veszélyes tartalmat. Te rábíznád magad a MIME tipusra, és kivennéd a böngészőből ezt a funkcionalitást? Én biztosan nem.
nem biztonsági kérdés