ugrás a tartalomhoz

Szemantikus HTTP

Joó Ádám · 2008. Szep. 26. (P), 00.18
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.

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');
egyébként pedig mezei név–érték párként:

header('Cache-Control: no-cache');
header('Cache-Control: must-revalidate', false);
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.

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);
Fontos, 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 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!
 
Joó Ádám arcképe
Joó Ádám
A Weblabor szerkesztője, örök kritikus, a Budapesti Műszaki és Gazdaságtudományi Egyetem mérnök informatikus hallgatója. Leginkább a nyelv, a szemantika, a kommunikáció maga érdekli. A webfejlesztésen túl tipográfiával, a képzelet irodalmával, esetleg két láb acél forgatásával tölti idejét.
1

Wow!

janoszen · 2008. Okt. 6. (H), 17.10
Először is, gratula a cikkhez. Örülök, hogy vetted a fáradtságot és megírtad. Sajnos sok PHP-s életéből kimarad a HTTP lehetőségeinek alapos ismerete, ami remélhetőleg egy picit változik a cikknek köszönhetően.

Egyetlen megjegyzést, kérlek, engedj meg. A HTTP RFC kiköti, hogy a Location header tartalma csak abszolut URI lehet:

The field value consists of a single absolute URI.


A böngészők többnyire lekezelik, de szigorúan véve csak abszoluttal szabadna címezni.
2

Köszi

Joó Ádám · 2008. Okt. 6. (H), 17.35
Örülök, hogy egyetértünk, holott tényleg nem tegnap álltam neki ;)

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 Host mező eredménye. Mindenesetre javítottam, köszönöm a jelzést.
32

Az RFC 7231 már megengedi a

Joó Ádám · 2014. Dec. 18. (Cs), 12.49
Az RFC 7231 már megengedi a relatív URI-t is.
3

köszi!

gex · 2008. Okt. 6. (H), 17.49
nekem is tetszik a cikk, a témája szerintem sokunk szemében egyfajta fehér folt, mivel nem nagyon kell vele foglalkozni, talán a 301 és a 404 a kivétel.

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.
4

303, 201

Joó Ádám · 2008. Okt. 6. (H), 18.16
Igen, amennyiben szerkeszted, úgy egy 303 lesz a legjobb. Önmagában a Locationhöz a PHP kiad egy 302-t, de a függvény harmadik paraméterével ez felülírható:

header('Location: http://valami.hu/valamik/valamelyik', null, 303);
És akkor még helyezz el benne némi HTML-t, amivel leírod, hogy sikeres volt a művelet, és hol található az eredménye ;)

A létrehozás már érdekesebb, mert szóba jön a 201 Created is, 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.
5

Gyanús kérés

Joó Ádám · 2008. Okt. 6. (H), 21.15
Ma vetődött fel a levelezőlistán, hogy vajon milyen állapotkódot érdemel egy mod_security által megfogott, gyanús kérés. Ebben a kérdésben is várjuk a véleményeket, a helyes megfejtő jutalma az, hogy a Weblaboron is alkalmazásra kerül az ötlete.
6

400

Hodicska Gergely · 2008. Okt. 6. (H), 22.23
A 4xx és 5xx csoportból szerintem a 4xx, hisz a kliens kérése okozza a problémát, maga a szerver rendben van. Így a 400 lenne a legközelebb, ezzel jelezzük azt is egyértelműen, hogy a kliens ne ismételje meg a kérést, mert nincs értelme.
7

400, vagy 403

Heilig Szabolcs · 2008. Okt. 6. (H), 23.12
A 406 Not Acceptable a "hivatalos", a mod_security default. Felületesen nézve a "Not Acceptable" szöveg miatt ez rendbenlevőnek is látszik, de mint láthatjuk, nem az igazi amúgy.

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 :)
21

A 400 azert nem jo, mert azt

hron84 · 2008. Nov. 18. (K), 00.20
A 400 azert nem jo, mert azt a szabvany eredetileg a hibas / hianyos protokoll parancs jelzesere definialta. Vagyis, ha a POST helyett PSOT megy ki, barmilyen okbol, akkor kuld a rendszer 400 Bad Request-et.

Szerintem a mod_security-e a lehetosegekhez kepest a legjobb megoldas, hiszen maga a webalkalmazas nem fogadja el a beadott adatot.
23

Mást jelent

Joó Ádám · 2008. Nov. 28. (P), 02.08
A szabvány világosan leírja, hogy a 406 akkor alkalmazandó, ha a kiszolgáló nem tud az ügyfél kérésének megfelelő (az Accept-ben megadott) tulajdonságokkal rendelkező választ küldeni.
8

Példák

Gixx · 2008. Okt. 9. (Cs), 17.21
A cikk nagyon jó, én is előszeretettel használom ezeket (ahol indokolt persze). 404, és 403 alapból. Mindamellett szerintem jó lenne, ha mindenhol szerepelne 1-2 példa, mert bár tudom, hogy a google az én barátom, de pl nem feltétlenül egyértelmű, hogy melyiket hogy kell megadni.

Régebben (IE6 era) pl a 404-et nem volt elég így megadni:
header('Status: 404 Not Found');
hanem valamiért neki ez is kellett:
header("HTTP/1.0 404 Not Found");
Én használom még a 400-at is, bár mondjuk nem tudom, hogy ha egy kérést (legyen simán getsomething.php mindenféle paraméter nélkül) egyértelműen AJAX-on keresztül várok, de valaki a böngésző címsorból próbálja meghívni, akkor szabályos-e, ha egy "400 Bad Request"-et kap vissza?
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.
9

400 formai hiba esetén

Hodicska Gergely · 2008. Okt. 9. (Cs), 17.49
ha egy kérést egyértelműen AJAX-on keresztül várok
Ez talán határeset, mert maga a kérés rossz formátumú, hisz hiányzik belőle egy olyan header, aminek elvileg kötelezően benne kéne lennie.

ha nem létező Controller-re és/vagy Action-re hivatkozunk?
Ez már szerintem teljesen alkalmazás logika, formailag a kérés jó, szóval ez 404 error, vagy esetleg valami egyéb, ha régen volt ilyen URL, de már megszűnt stb..
10

Helyes alak

Joó Ádám · 2008. Okt. 10. (P), 22.53

header('HTTP/1.1 404 Not Found');
Ez a helyes alak, a Status-ost nem is értem, honnan eredhet.

Az állapotkódokkal kapcsolatban pedig egyetértek Felhővel. A 413 merésznek tűnik, de igazából nem tudnám indokolni, miért ne, szóval tulajdonképp miért ne.
11

ajax: 406

vbence · 2008. Okt. 11. (Szo), 11.38
406 Not Acceptable
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).
14

Nem rossz

Joó Ádám · 2008. Okt. 11. (Szo), 13.12
Ez is teljesen védhető, meg se fordult a fejemben :)
17

jó ötlet

Gixx · 2008. Okt. 13. (H), 14.53
A 406 jó ötlet, megnézem.

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ő.
12

Nagyon furcsa: 205

vbence · 2008. Okt. 11. (Szo), 11.58
Amikor írtad, hogy nem sikerült működésre bírni a 205 Reset Content-et, csípőből válaszoltam volna, hogy miért nem küldted el a formot is mégegyszer (megvan a szemantika és a küldött HTML-t biztos megjelenítik a böngészők). Előtte azért belenéztem az rfc-be, ahol feketén fehéren ez áll:
The response MUST NOT include an entity.

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?
13

Ezt vegyük át

Joó Ádám · 2008. Okt. 11. (Szo), 13.11
Nem teljesen értelek.
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.
15

A szabvánnyal nem értek egyet

vbence · 2008. Okt. 11. (Szo), 13.36
Könnyen implementálható lenne a helyes működés, ha magát az üres formot is visszaküldenéd (a feldolgozás után). Ekkor a buta böngészők, akik mit sem tudnak a 205-ről is "resetelnék" a formot.

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).
16

gratula!

virág · 2008. Okt. 13. (H), 12.13
Csak azt lehet mondani amit a többiek is! Gratula! Ez egy nagyon jó és hiánypótló írás!
18

Űrlap hibák

Joó Ádám · 2008. Okt. 15. (Sze), 13.32
Azon gondolkodtam, elég visszás dolog az, mikor egy hibásan kitöltött űrlap érkezik vissza a kiszolgálótól 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 Conflict számára.

The request could not be completed due to a conflict with the current state of the resource. This code is only allowed in situations where it is expected that the user might be able to resolve the conflict and resubmit the request.


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 409 használatát minden visszadobott hibás űrlap esetén. Vélemény?
19

4xx

vbence · 2008. Okt. 15. (Sze), 16.57
A gondolat jó, de attól félek, hogy böngészők a 400-as kódokat a resource hibájaként értékelik, hiába kliensoldali hibát jelent a szabvány szerint. Konkrétan: az IE nem fogja elfedni az ezzel a kóddal érekző "hibaoldalt"? (Persze tudom, van megkerülő megoldás, ha küldönk 8k soace-t vagy ilyesmi...)
20

Próba?

Joó Ádám · 2008. Okt. 15. (Sze), 18.00
Nekem most nincs a közelemben IE, ki kellene próbálni. Firefox alatt semmilyen problémát nem okoz a dolog.

(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.)
22

Hat en erre nem vennek

hron84 · 2008. Nov. 18. (K), 00.45
Hat en erre nem vennek merget. Sajnos az IE7 se sokkal szabvanykovetobb, mint ose.
24

Amit még érdemes tudni

EdgarPE · 2008. Dec. 15. (H), 02.17
Amit még érdemes tudni, és az egyébként nagyszerű cikk nem tartalmazta, hogy ha a kliens olyan http kódot kap, amit nem tud értelmezni, mert mondjuk később vezették be, és a kliens nem ismeri ezt a státusz kódot, a szabvány előírja, hogy ilyenkor a 100-as alapszámra kerekítés szerint kell eljárni.

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.
25

204 - tényleg hasznos?

Crystal · 2009. Már. 24. (K), 23.57
"Esetleg JavaScripttel a követelményeknek megfelelően módosíthatjuk azt, pl. egy köszönőüzenetet beszúrva a megfelelő helyre."

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:)
26

Tényleg

Joó Ádám · 2009. Már. 27. (P), 01.51
Van válasz: egy 204-es. Csak törzse nincs. A 2xx kódok, és így a 204 is azt jelenti, hogy a kérés sikeres volt. Ha hiba történik, akkor az annak megfelelő kódot kell visszaadni helyette.
27

405 Method Not Allowed

Poetro · 2009. Ápr. 7. (K), 21.44
Valamiért ez kimaradt pedig nagyon fontos szerepe tud lenni, főleg a mai AJAX-os világban, ahol mondjuk csak POST-tal fogadunk el adatokat, és ugyanazt GET-tel küldve már nem, ezzel biztosítva, hogy a crawler-ek nem csinálnak semmi rosszat.
28

Nagyon jó

Joó Ádám · 2009. Ápr. 9. (Cs), 21.37
Köszi, nagyon jó kiegészítés, bennem fel se merült. Pótoltam a hiányát.
29

Google érteni 410 Gone?

Max Logan · 2009. Május. 16. (Szo), 01.28
A Google foglalkozik a 410-es header-rel? Mert már jó néhány hete ilyen státuszkódot kap a már nemlétező oldalakra, de még mindig egy rakat szerepel az indexében.

Közben rájöttem, hogy a Webmaster Tools a barátom :-)
30

Állítólag

Joó Ádám · 2009. Május. 17. (V), 21.18
Elvileg igen.
31

Megy, csak lassú

Max Logan · 2009. Május. 17. (V), 21.54
Belőttem a kérdéses oldalra a Webmaster Tool-t. Már elég sok oldalt kilőtt az index-ből és még van hátra kb. ugyanannyi. Működik a dolog, csak kicsit lassú.