Szemantikus HTTP
Jelen írás egy a szerkesztői levelezőlistán indult vita továbbgondolása, mely a hitelesítés megkövetelésekor használandó HTTP fejlécek kérdésében bontakozott ki. A cikkben kitérünk ezekre és más, méltatlanul hanyagolt gyöngyszemekre is.
A világhálót lassan két évtizede szolgáló HTTP protokoll pedig széles eszköztárat biztosít számunkra ehhez, ennek ellenére elenyésző részét használjuk ki ennek.
A felállás hasonló a HTML még néhány évvel ezelőtt is oly mostoha helyzetéhez: a sok jelentésteljes fejléc közül alig egy-kettő van mindennapi használatban, ez pedig amellett, hogy nem hordoz információt, gyakran még hibásat is hordoz. Kétségkívül a leggyakoribb ezek közül is a
Hosszútávon azonban szükséges annak belátása, hogy a jövő elkerülhetetlenül a szemantikus háló irányába mutat, legyen szó esetünkben tudatosabb, a felhasználónak a válasz természetét egyértelműen jelző, arra reagáló böngészőkről, felolvasóprogramokról, vagy a keresőkről, hírolvasókról és minden más, az elkövetkező időkben egyértelműen növekvő számú önműködő gépi feldolgozásról, nem beszélve a webalkalmazások már ma is a médium kereteit feszegető szükségleteiről. Így tehát ezen cikk nem titkolt szándéka, hogy hasonlóan az előbbiekben párhuzamként már felhozott HTML használatának forradalmához, a HTTP esetében is párbeszédet, ötletelést, változást indítson meg.
Az alábbiakban tehát áttekintjük, hogyan befolyásolhatjuk a böngészőnek küldött fejléceket, illetve néhány példa mellett megnézzük, melyeket tudjuk mindennapi munkánk során hasznosítani.
Az első feladathoz a PHP beépítettegyébként pedig mezei név–érték párként:Az elhagyható második paraméterrel szabályozható, hogy a korábbi, azonos nevű mezőt felülírja, vagy hozzáadja a többihez.
AFontos, hogy a fejlécekre csak kimenet elküldése előtt van befolyásunk, tehát még akkor is hibát fogunk kapni, ha csak egy újsor karakter is kiment a függvény hívását megelőzően. Ennek elejét vehetjük kimenettárolással.
Hasznos lehet még a
Ami a megtekintést illeti, a Firebug Net lapján minden, az oldal összeállításához szükséges HTTP kérés és válasz fejléceit tanulmányozhatjuk.
A kiszolgált tartalom MIME típusa. Érdemes odafigyelni, mert a böngészők gyakran önkényesen kezelik őket, ami biztonsági veszélyeket is rejthet magában.
Típus/altípus alakban állnak, pontosvesszővel elválasztva, egyenlőségjelek két oldalán adhatók meg paraméterek név–érték párokként.
A nemzetköziesítés (I18N) és helyhezkötés (L11N) egyre fontosabb szerepet tölt be a hálón is, mindennaposak a soknyelvű webhelyek. A tartalom nyelvének kétbetűs rövidítését adhatjuk meg. Habár vesszővel elválasztva több is felsorolható, fontos megjegyezni, hogy a választás célját szolgálja, nem pedig a tartalomban előforduló minden nyelv felsorolását. Tehát ha egy szöveg mind angolul, mind németül megtalálható az oldalon, akkor mindkettő felsorolandó, míg ha egy angol nyelvű, példákkal ellátott német nyelvtanról van szó, akkor csak az előbbi. Elhagyása a tartalom egyetemes jellegét, vagy a nyelv ismeretlen voltát jelöli. Nem csak szöveges tartalmakra alkalmazható!
A
Ugyancsak MIME szabvány, értéke lehet
Alapbeállítás szerint az állomány utolsó módosításának kelte szokott lenni, dinamikus tartalmaknál azonban ez értelemszerűen nem hordoz sok információt. Bátran használhatjuk a blogbejegyzés, hír, cikk, hozzászólás utolsó szerkesztésének időpontját itt, csak figyeljünk az alakra.
A kérést kiszolgáló szoftverek, csökkenő fontossági sorrendben, a név után perjellel elválasztva a kiadásszám (vigyázzunk, mert a pontos megadása jó kiindulópontot adhat egy támadáshoz), zárójelben megjegyzés.
Kiszolgálóoldali tartalomegyeztetéskor (server-side content negotiation) van jelentősége. Hogy mit jelent ez? Ha egy tartalom több változatban is elérhető, legyen szó eltérő karakterkódolásról, nyelvről, állományformátumról, úgy megkísérelhetjük kiszolgálóoldalon eldönteni, melyik lehet a legmegfelelőbb az ügyfélnek. Jelentősége elsősorban a gyorsítótárazott tartalmak esetén van, ahol megadásakor feltételezhető, hogy ugyanazon fejlécértékek küldésekor, ameddig a tartalom friss, ugyanazt a választ fogjuk kapni. Ha a fejléceken kívül más információkat (pl. IP-cím) is felhasználunk a döntés meghozásakor, akkor a * értékkel jelezhetjük ezt.
Sikeres kérés.
A felhasználó ténykedése következtében új tartalom született (és a válasz elküldésekor már valóban megszületett!), a válasz tartalmazza rövid leírását és a hozzá vezető hivatkozás(oka)t. Tehát „Hozzászólásod elmentettük, az alábbi címen megtekintheted:” típusú dolgok. Helyét a
A kiszolgáló fogadta a kérést, azonban az még feldolgozásra vár. Használjuk megjelentetés előtt moderált tartalmak, esetleg egy cron lefutásához kötött ellenőrzés esetén. Adjunk egy címet a felhasználónak, melyen ellenőrizheti beküldött édesgyermeke állapotát, illetve valamelyes támpontot afelől, mikor várhat eredményt.
A kérés lefutott, kimenete azonban nincs, az esetlegesen frissült fejléceket alkalmazni kell a jelenlegi erőforrásra. Hogy mit jelent ez? Egész pontosan azt, hogy nincs szükség AJAX használatára ahhoz, hogy a háttérben adatokat küldjünk, például egy tartalom értékelésekor! Az adatok elmennek a háttérben, a böngésző nézet azonban változatlan. Esetleg JavaScripttel a követelményeknek megfelelően módosíthatjuk azt, pl. egy köszönőüzenetet beszúrva a megfelelő helyre. Rendkívül hasznos lehetőség, használjuk!
Az előzőhöz nagymértékben hasonló eljárás, elsősorban azokban a helyzetekben alkalmazható, amikor egymás után nagyszámú adatot kell felvinnünk, például egy adatbázisba. A tartalma elküldésre kerül a kiszolgálónak, majd az űrlapot alapállapotába hozza a böngésző – elméletben, ugyanis sem Firefox, sem Opera alatt nem sikerült helyes működésre bírnom. Ahol nem szükséges, de jól jöhet a dolog, ott alkalmazzuk, idővel javulhat a helyzet.
Amennyiben egy tartalomhoz több megjelenés is tartozik, mondjuk más állományfajták, nyelvek, úgy a megoldás a
A kért tartalom címe véglegesen megváltozott, a jövőben a
A kért tartalom címe ideiglenesen megváltozott, ez a
A
Használjuk akkor, ha az előző három kategóriába nem fér bele az elképzelésünk. Szokásos ügymenet.
A szerkesztőséget megosztó elem. A szabvány szerint kötelező a
Habár az ismertetésében csak annyi olvasható, hogy a jövőbeli használatra fenntartva, a neve elég sokatmondó.
Kevés manapság az olyan webalkalmazás, melyben nem kezelünk jogosultságokat. Amikor pedig tapintatosan (vagy kevésbé tapintatosan) közöljük a felhasználóval, hogy itt bizony semmi keresnivalója, na akkor érkezik ez. Ha egyáltalán nem óhajtjuk vele megosztani, miért nem történik az, amit eltervezett, akkor használhatunk
A kért tartalom nem található, nekünk pedig lövésünk sincs, mire gondolt a felhasználó. Hogy ne érezze magát elveszettnek, ajánljunk neki tartalmat, keresőt, kapcsolati lehetőséget. Lásd még vonatkozó cikkünket.
A kért erőforrásra nem alkalmazható a használt metódus: például csak
Nem tudunk az ügyfél (
A kérés nem hajtható végre, mivel az ütközik az erőforrás jelenlegi állapotával. Példaként hozható egy verziókövető alkalmazás, ahol időközben módosult a szóban forgó tartalom. A válaszban jelezzük a problémát, hogy a felhasználó korrigálhassa.
Amennyiben egy tartalmat törlünk, úgy ennek tényét egy
Amikor valami balul üt ki. Mondjuk alkalmazásunk dob egy esztétikus kivételt. Akár megjelenítjük, akár nem, adjunk ki egy
Karbantartás, estébé. Vegyük a fáradtságot és tegyük ki. Egy
■ Miért
A szemantika fontos. Mint informatikusnak, webfejlesztőnek, hivatásunk célja az információ tárolása, továbbítása és megjelenítése, melyeknek gépi környezetben elengedhetetlen feltétele a metaadatok használata.A világhálót lassan két évtizede szolgáló HTTP protokoll pedig széles eszköztárat biztosít számunkra ehhez, ennek ellenére elenyésző részét használjuk ki ennek.
A felállás hasonló a HTML még néhány évvel ezelőtt is oly mostoha helyzetéhez: a sok jelentésteljes fejléc közül alig egy-kettő van mindennapi használatban, ez pedig amellett, hogy nem hordoz információt, gyakran még hibásat is hordoz. Kétségkívül a leggyakoribb ezek közül is a
200 OK, mely az esetek túlnyomó többségében válogatás nélkül a kiszolgáló alapbeállítása szerint minden fajtájú válaszra alkalmazva van.Hosszútávon azonban szükséges annak belátása, hogy a jövő elkerülhetetlenül a szemantikus háló irányába mutat, legyen szó esetünkben tudatosabb, a felhasználónak a válasz természetét egyértelműen jelző, arra reagáló böngészőkről, felolvasóprogramokról, vagy a keresőkről, hírolvasókról és minden más, az elkövetkező időkben egyértelműen növekvő számú önműködő gépi feldolgozásról, nem beszélve a webalkalmazások már ma is a médium kereteit feszegető szükségleteiről. Így tehát ezen cikk nem titkolt szándéka, hogy hasonlóan az előbbiekben párhuzamként már felhozott HTML használatának forradalmához, a HTTP esetében is párbeszédet, ötletelést, változást indítson meg.
Az alábbiakban tehát áttekintjük, hogyan befolyásolhatjuk a böngészőnek küldött fejléceket, illetve néhány példa mellett megnézzük, melyeket tudjuk mindennapi munkánk során hasznosítani.
Hogyan
Ami az eszközöket illeti, egyrészt szükségünk lesz arra, hogy a megfelelő fejléceket elküldjük, másrészt arra, hogy ezeket megnézzük.Az első feladathoz a PHP beépített
header() függvényét használhatjuk. A megadott karakterláncot a HTTP válasz fejlécének egy soraként kezeli. Amennyiben a protokoll kiadásszámával kezdődik, a forrásban való helyzetétől függetlenül állapotsorként kezeli:
header('HTTP/1.1 404 Not Found');
header('Cache-Control: no-cache');
header('Cache-Control: must-revalidate', false);
A
Location fejléc küldésekor a PHP magától beállítja a 302 állapotkódot, ha más 3xx kód még nem lett beállítva. Ha ez keresztülhúzza számításainkat, akaratunkat a harmadik paraméter megadásával kényszeríthetjük rá a szerencsétlen jószágra:
header('Location: http://weblabor.hu/forumok/temak/1000000', null, 201);
Hasznos lehet még a
headers_sent() és header_list() függvény.Ami a megtekintést illeti, a Firebug Net lapján minden, az oldal összeállításához szükséges HTTP kérés és válasz fejléceit tanulmányozhatjuk.
Mit
Általános mezők
Először tekintsünk át néhány általános tartalomleíró mezőt.Content-Type
A kiszolgált tartalom MIME típusa. Érdemes odafigyelni, mert a böngészők gyakran önkényesen kezelik őket, ami biztonsági veszélyeket is rejthet magában.Típus/altípus alakban állnak, pontosvesszővel elválasztva, egyenlőségjelek két oldalán adhatók meg paraméterek név–érték párokként.
Content-Type: text/plain
Content-Type: application/xhtml+xml;charset=utf-8
Content-Language
A nemzetköziesítés (I18N) és helyhezkötés (L11N) egyre fontosabb szerepet tölt be a hálón is, mindennaposak a soknyelvű webhelyek. A tartalom nyelvének kétbetűs rövidítését adhatjuk meg. Habár vesszővel elválasztva több is felsorolható, fontos megjegyezni, hogy a választás célját szolgálja, nem pedig a tartalomban előforduló minden nyelv felsorolását. Tehát ha egy szöveg mind angolul, mind németül megtalálható az oldalon, akkor mindkettő felsorolandó, míg ha egy angol nyelvű, példákkal ellátott német nyelvtanról van szó, akkor csak az előbbi. Elhagyása a tartalom egyetemes jellegét, vagy a nyelv ismeretlen voltát jelöli. Nem csak szöveges tartalmakra alkalmazható!
Content-Language: en
Content-Language: en, de
Content-Description
A Content-Description MIME fejléc használható a tartalom rövid szöveges ismertetésére. A nem szöveges tartalmak esetén lehet különösen hasznos, gondoljunk a SEO vonatkozásaira.
Content-Description: "J. Goldenlane: A szélhámos és a varázsló című könyvének borítója"
Content-Disposition
Ugyancsak MIME szabvány, értéke lehet inline vagy attachment, előbbi esetben a böngésző megjeleníti a tartalmat, utóbbiban felkínálja mentésre. Ekkor jön képbe filename paramétere, mellyel megadhatjuk, milyen néven tegye ezt, mely nagyban növelheti a felhasználói élményt:
Content-Disposition: attachment;filename="A szélhámos és a varázsló.png"
Last-Modified
Alapbeállítás szerint az állomány utolsó módosításának kelte szokott lenni, dinamikus tartalmaknál azonban ez értelemszerűen nem hordoz sok információt. Bátran használhatjuk a blogbejegyzés, hír, cikk, hozzászólás utolsó szerkesztésének időpontját itt, csak figyeljünk az alakra.
Last-Modified: Sat, 04 Oct 2008 20:34:03 GMT
Server
A kérést kiszolgáló szoftverek, csökkenő fontossági sorrendben, a név után perjellel elválasztva a kiadásszám (vigyázzunk, mert a pontos megadása jó kiindulópontot adhat egy támadáshoz), zárójelben megjegyzés.
Server: Apache/2.0 (Ubuntu) PHP/5.1 MySQL/5.0 ZendFramework/1.6 Doctrine/1.0
Vary
Kiszolgálóoldali tartalomegyeztetéskor (server-side content negotiation) van jelentősége. Hogy mit jelent ez? Ha egy tartalom több változatban is elérhető, legyen szó eltérő karakterkódolásról, nyelvről, állományformátumról, úgy megkísérelhetjük kiszolgálóoldalon eldönteni, melyik lehet a legmegfelelőbb az ügyfélnek. Jelentősége elsősorban a gyorsítótárazott tartalmak esetén van, ahol megadásakor feltételezhető, hogy ugyanazon fejlécértékek küldésekor, ameddig a tartalom friss, ugyanazt a választ fogjuk kapni. Ha a fejléceken kívül más információkat (pl. IP-cím) is felhasználunk a döntés meghozásakor, akkor a * értékkel jelezhetjük ezt.
Vary: User-Agent
Vary: Accept, Accept-Charset, Accept-Encoding, Accept-Language
Vary: *
Állapotkódok
2xx
A kérés sikeresen megérkezett, megértették és elfogadták.200 OK
Sikeres kérés. GET metódusra válaszul a kért erőforrás, POSTnál az elvégzett művelet eredménye vagy ennek leírása.201 Created
A felhasználó ténykedése következtében új tartalom született (és a válasz elküldésekor már valóban megszületett!), a válasz tartalmazza rövid leírását és a hozzá vezető hivatkozás(oka)t. Tehát „Hozzászólásod elmentettük, az alábbi címen megtekintheted:” típusú dolgok. Helyét a Location mezőben is megadjuk, kiküldésekor figyeljünk a harmadik paraméterre!202 Accepted
A kiszolgáló fogadta a kérést, azonban az még feldolgozásra vár. Használjuk megjelentetés előtt moderált tartalmak, esetleg egy cron lefutásához kötött ellenőrzés esetén. Adjunk egy címet a felhasználónak, melyen ellenőrizheti beküldött édesgyermeke állapotát, illetve valamelyes támpontot afelől, mikor várhat eredményt.204 No Content
A kérés lefutott, kimenete azonban nincs, az esetlegesen frissült fejléceket alkalmazni kell a jelenlegi erőforrásra. Hogy mit jelent ez? Egész pontosan azt, hogy nincs szükség AJAX használatára ahhoz, hogy a háttérben adatokat küldjünk, például egy tartalom értékelésekor! Az adatok elmennek a háttérben, a böngésző nézet azonban változatlan. Esetleg JavaScripttel a követelményeknek megfelelően módosíthatjuk azt, pl. egy köszönőüzenetet beszúrva a megfelelő helyre. Rendkívül hasznos lehetőség, használjuk!205 Reset Content
Az előzőhöz nagymértékben hasonló eljárás, elsősorban azokban a helyzetekben alkalmazható, amikor egymás után nagyszámú adatot kell felvinnünk, például egy adatbázisba. A tartalma elküldésre kerül a kiszolgálónak, majd az űrlapot alapállapotába hozza a böngésző – elméletben, ugyanis sem Firefox, sem Opera alatt nem sikerült helyes működésre bírnom. Ahol nem szükséges, de jól jöhet a dolog, ott alkalmazzuk, idővel javulhat a helyzet.3xx
Átirányítás. A művelet teljesítéséhez fel kell keresni a megadott címet.300 Multiple Choices
Amennyiben egy tartalomhoz több megjelenés is tartozik, mondjuk más állományfajták, nyelvek, úgy a megoldás a 300 Multiple Choices, ahol ezek elérését felsorolhatjuk, opcionálisan pedig egy Location mezőben sugallhatjuk, melyet részesítjük előnyben; ez oly nyomós lesz, hogy rögtön át is irányítja majd a felhasználót, így ha mellette döntünk, úgy tetszetős listánkból leginkább a keresők és hasonló, kevéssé türelmetlen entitások fognak hasznot húzni – rajtuk keresztül pedig mi, de psszt.301 Moved Permanently
A kért tartalom címe véglegesen megváltozott, a jövőben a Location mezőben megadotton érhető el. Keresőoptimalizálás szempontjából esszenciális egy webhely átszervezésekor. Pirospontot ér és a szabvány is megköveteli, hogy egy rövid szöveges üzenetben, illetve mellékelt hivatkozással tájékoztassuk a felhasználót a tényállásról, még ha az nem is fogja ezt látni az automatikus átirányítás okán (már amennyiben GET vagy HEAD kérésről van szó: mást elvileg nem lehet felhasználói beavatkozás nélkül továbbítani az új URI felé).302 Found
A kért tartalom címe ideiglenesen megváltozott, ez a Location mezőben olvasható, azonban a jövőben továbbra is a jelenlegi használandó. Amiképp az előzőnél, most is helyezzünk el egy rövid magyarázó szöveget és hivatkozást az ideiglenes pozícióra.303 See Other
A POSTtal működésre bírt erőforrás kimenete egy másik címről GETtel érhető el. Location mező. Leírás, hivatkozás.307 Temporary Redirect
Használjuk akkor, ha az előző három kategóriába nem fér bele az elképzelésünk. Szokásos ügymenet.4xx
Hiba az ügyfél oldalán.401 Unauthorized
A szerkesztőséget megosztó elem. A szabvány szerint kötelező a WWW-Authenticate mező kiküldése, következésképp a protokoll szinten megvalósított hitelesítés. Gábor szerint ennek ellenére használhatjuk abban az esetben, ha alkalmazásunk a felhasználó beléptetését követeli meg, Gábor ezzel szemben javasolja a belépőoldalra való átirányítást. Várjuk a véleményeket a megjegyzésekben, az eredmény közvetlenül befolyással lehet a Weblaboron, illetve a Drupalban lévő megvalósításra, jól.402 Payment Required
Habár az ismertetésében csak annyi olvasható, hogy a jövőbeli használatra fenntartva, a neve elég sokatmondó.403 Forbidden
Kevés manapság az olyan webalkalmazás, melyben nem kezelünk jogosultságokat. Amikor pedig tapintatosan (vagy kevésbé tapintatosan) közöljük a felhasználóval, hogy itt bizony semmi keresnivalója, na akkor érkezik ez. Ha egyáltalán nem óhajtjuk vele megosztani, miért nem történik az, amit eltervezett, akkor használhatunk 404-et is.404 Not Found
A kért tartalom nem található, nekünk pedig lövésünk sincs, mire gondolt a felhasználó. Hogy ne érezze magát elveszettnek, ajánljunk neki tartalmat, keresőt, kapcsolati lehetőséget. Lásd még vonatkozó cikkünket.405 Method Not Allowed
A kért erőforrásra nem alkalmazható a használt metódus: például csak POST kérést fogadó műveletek esetén alkalmazhatjuk. Ha így teszünk, akkor kötelező a válaszban egy Allowed mezőben felsorolni az engedélyezett metódusokat.406 Not Acceptable
Nem tudunk az ügyfél (Accept típusú) elvárásainak megfelelő tartalmat kiszolgálni, így inkább felsoroljuk, hogy milyen változatokkal tudunk szolgálni.409 Conflict
A kérés nem hajtható végre, mivel az ütközik az erőforrás jelenlegi állapotával. Példaként hozható egy verziókövető alkalmazás, ahol időközben módosult a szóban forgó tartalom. A válaszban jelezzük a problémát, hogy a felhasználó korrigálhassa.410 Gone
Amennyiben egy tartalmat törlünk, úgy ennek tényét egy 410 Gone-nal jelezhetjük a semmitmondó 404 helyett. Ennek hatására a vonatkozó hivatkozásokat a megfelelő szoftverek elfelejtik.5xx
Hiba a kiszolgáló oldalán.500 Internal Server Error
Amikor valami balul üt ki. Mondjuk alkalmazásunk dob egy esztétikus kivételt. Akár megjelenítjük, akár nem, adjunk ki egy 500-at.503 Service Unavailable
Karbantartás, estébé. Vegyük a fáradtságot és tegyük ki. Egy Retry-Afterben jelezhetjük, mikor várható ismét üzem.Tehát
Ennyi lett volna, remélem gondolatébresztő volt, esetleg referenciaként is használható az írás fejlesztés során. Várjuk a véleményeket, ötleteket, írjátok meg, ti mit és hogyan használtok!
Wow!
Egyetlen megjegyzést, kérlek, engedj meg. A HTTP RFC kiköti, hogy a Location header tartalma csak abszolut URI lehet:
A böngészők többnyire lekezelik, de szigorúan véve csak abszoluttal szabadna címezni.
Köszi
A abszolút URI-val kapcsolatban igazad van, bár szerintem sokkal logikusabb az abszolút elérési út – valószínűleg ez a követelmény az 1.0-s alkalmazások által még kevéssé támogatott
Hostmező eredménye. Mindenesetre javítottam, köszönöm a jelzést.Az RFC 7231 már megengedi a
köszi!
a POST kérések után, amennyiben átment mindenféle ellenőrzésen és változást okozott pl egy adatbázisban, általában a php header parancsával kiadok egy location fejlécet, hogy átdobjam egy másik oldalra (felvitelnél egy listához) vagy épp ugyanarra (szerkesztésnél). a cikk alapján ez egy 302-es fejlécet generál, viszont itt elvileg egy 303-asat kéne kiadni. jól látom ezt?
ezen kívül még a 403-ast fogom sűrűbben használni, eddig ott is a 404 ment, de tényleg előremutatóbb ha a gépek is értik mi miért történt.
303, 201
303lesz a legjobb. Önmagában aLocationhöz a PHP kiad egy302-t, de a függvény harmadik paraméterével ez felülírható:A létrehozás már érdekesebb, mert szóba jön a
201 Createdis, bár itt egyrészt marad az URL, másrészt elvileg egy rövid megjegyzésben kéne tudatni az új tartalom létrejöttét és elérhetőségét – bár ez még tulajdonképp ráerőszakolható a listára.Gyanús kérés
400
400, vagy 403
A 400 Bad Request valóban az, ami a legközelebb áll a valósághoz. A 406-hoz elvileg magyarázatot is mellékelni kellene hivatalosan. Ráadásul a válasznak az Accept* fejlécekhez semmi köze.
A 403 Forbidden is szóba jöhet esetleg feltéve, ha valóban tudjuk közölni is a kliens oldallal, miért is tartjuk csukva a kaput.
Ha meg humorosak akarunk lenni, akkor 402 :)
A 400 azert nem jo, mert azt
Szerintem a mod_security-e a lehetosegekhez kepest a legjobb megoldas, hiszen maga a webalkalmazas nem fogadja el a beadott adatot.
Mást jelent
406akkor alkalmazandó, ha a kiszolgáló nem tud az ügyfél kérésének megfelelő (azAccept-ben megadott) tulajdonságokkal rendelkező választ küldeni.Példák
Régebben (IE6 era) pl a 404-et nem volt elég így megadni:
Vagy ugyanez a Zend Framework estében, ha nem létező Controller-re és/vagy Action-re hivatkozunk? Mert a leírás alapján ez is rossz kérés és nem kéne megismételni.
Illetve, ha mondjuk egy form oldalon van egy textarea, amire ugye nem lehet karakter limitet rakni úgy, mint az inputra (persze az input is széthekkelhető firebuggal ha az kell), akkor php oldalon, ha valamelyik mező értéke hosszabb, mint szeretnénk, akkor túl durva lenne a hiba visszaadásán túl egy "413 Request Entity Too Large" fejlécet is dobni? Ez viszont csak kérdés, mert ilyenre még nem vetemedtem :) Meg ez már kicsit ló túloldala eset.
400 formai hiba esetén
Helyes alak
Status-ost nem is értem, honnan eredhet.Az állapotkódokkal kapcsolatban pedig egyetértek Felhővel. A
413merésznek tűnik, de igazából nem tudnám indokolni, miért ne, szóval tulajdonképp miért ne.ajax: 406
Nem tudunk az ügyfél (Accept típusú) elvárásainak megfelelő tartalmat kiszolgálni
Ajax kérés böngészőbe gépelése esetén ez a válasz is jól hangzik, hiszen nem tudunk a böngésző által logikailag elvárt formátumú adatot küldeni. (Sőt fizikailag sem: nem hinném, hogy az accept mezőben text/json gyakran szerepelne).
Nem rossz
jó ötlet
A "Status:"-szal (10-es hozzászólás) kapcsolatban pedig a php.net oldalon a hozzászólások között rengetegszer felbukkan hol az egyik, hol a másik, hol mindkettő.
Nagyon furcsa: 205
Ami azért érdekes, mert a HTTP tele van redundanciával. Gondolunk csak a 3xx kódokra, ahol a Location mellett azt javasolják, hogy küldjünk egy HTML üzenetet is a kattintható linkkel.
Csak nekem tűnik disszonánsnak a dolog?
Ezt vegyük át
Elvileg
205-nél a háttérben fel kell mennie az adatoknak, az űrlapot pedig alapállapotba kell hozni.Firefoxban, ha jól emlékszem, volt oldalújratöltés, Operában pedig fehér oldalt kaptam.
A szabvánnyal nem értek egyet
A probléma ott van, hogy a szabvány kimondottan megtiltja, hogy adatot is küldjél a 205 mellé. Azért tartom ezt furcsának, mert a szabány sok helyen beiktat egy "fallback" megoldást (például a 3xx + Location mellett HTML küldését).
gratula!
Űrlap hibák
200 OK-val, hisz a kérés éppen hogy nem lett teljesítve. Emellett ugye az összes forgalom igen nagy százalékát adják az efféle válaszok, tehát valamiféleképp mégiscsak jelezni kellene ilyenkor, miről van szó.Végignézve a rendelkezésre álló kódokat pedig, azt hiszem, ez volna a megfelelő alkalmazás a
409 Conflictszámára.A felhozott példában – verziókezelés – is a „current state” értelmezhető úgy, hogy egy megadott szabállyal („ha a tartalom felhasználó általi utolsó lekérdezése és módosításainak elküldése között a tartalom változott, akkor a módosításai nem menthetők”) ütközik a kérés. Ez már lefedi a helyzetünket, és természetesen az üzenetek alapján a felhasználónak lehetősége van javítani a hibákat, majd megismételni a kérést, tehát minden kitételnek megfelelünk.
Szóval javaslom a
409használatát minden visszadobott hibás űrlap esetén. Vélemény?4xx
Próba?
(Egyébként meg ilyesmi azért gondolom egy 7-es IE-ben sem fordul már elő, a 6-ot pedig lassan tényleg elfelejthetjük.)
Hat en erre nem vennek
Amit még érdemes tudni
Tehát ha ilyen ritkán használt kódokat küld ki valaki, esetleg ne lepődjön meg, ha a kliens nem azt csinálja amit elsőre várnánk. Ha meg klienst ír vki, és 499-et kap státusz kódként, akkor is van szabványos eljárás, 400-ként kell értelmezni.
204 - tényleg hasznos?
Ezt pontosan hogy gondoltad? Ha nincs válasz, akkor honnan tudja a javascript, hogy sikeresen lefutott a kérés, és valóan egy köszönő üzenetet kell megjelenítenie, nem pedig hibaüzenetet?
Tkp nem hiszem, hogy lenne olyan egyszerű eset, mikor nincs szükség válaszra szerver-oldalról (hiszen szerver-oldali hiba bármikor történhet), és ha így nézzük, ez a 204-es fejléc gyakorlatilag használhatatlan:)
Tényleg
204-es. Csak törzse nincs. A2xxkódok, és így a204is azt jelenti, hogy a kérés sikeres volt. Ha hiba történik, akkor az annak megfelelő kódot kell visszaadni helyette.405 Method Not Allowed
Nagyon jó
Google érteni 410 Gone?
Közben rájöttem, hogy a Webmaster Tools a barátom :-)
Állítólag
Megy, csak lassú