ugrás a tartalomhoz

Barátságos hibaüzenetek - 404

Baranyai László · 2005. Aug. 28. (V), 20.00
Barátságos hibaüzenetek - 404
Böngészés során számtalanszor akad az ember hibaüzenetekbe, ezek közül is a leggyakoribb talán az "Error 404: File not found.". Jelentése pedig az "igen, egyszer volt itt egy oldal, de már nincs"-től kezdve az "ezt valaki elgépelte"-ig terjed. A legrosszabb megoldás, ha webfejlesztőként nem törődünk e jelenséggel, és hagyjuk, hogy a webszerver tegye amire képes. A hiba oldal megtervezése is fontos egy site építése során és nem is mindig olyan egyszerű eldönteni, hogy mit tartalmazzon.

Hibaüzenetek és kódok

A hibaüzeneteket és kódjaikat (legalábbis egy részüket) az alábbi táblázat foglalja össze. A kódok a szerver által adott válasz fejlécében "HTTP/x.y KÓD" kapnak helyet (az RFC 1945 6.1 pontja definiálja ezt a kérdést, egy részletesebb listát pedig az RFC2616-ban olvashatunk). A szerveren futó programokkal - indokolt esetben - befolyásolhatjuk, hogy mi kerüljön ide, például így működik a phpMyAdmin 'http' beléptetési módja is. Figyeljük meg, hogy a kód első száma (a százas helyiértéken levő) a kód típusát definiálja, a négyessel kezdődő (4xx) a kliens, míg az ötössel kezdődő (5xx) a szerver oldalon keletkező hibákat jelöli:

Válasz kódok és jelentésük
KódJelentése
400Bad Request - rosszul formázott kérés
401Unauthorized - a felhasználó még nem azonosította magát
403Forbidden - a kért anyaghoz nincs hozzáférési joga
404Not Found - a kért anyag nem található
500Internal Server Error - váratlan programhiba történt
501Not Implemented - a keresett funkció nem elérhető
502Bad Gateway - a gateway/proxy hibás adatokat kapott
503Service Unavailable - a szerver túlterhelt, vagy karbantartás miatt nem elérhető


A felsorolásból a klienshez köthető hibák jelzéséhez érdemes dinamikus hibalapot készíteni. A szerverhez köthetőeknél inkább egyszerű HTML lapot javasolnék, hogy ne terhelje tovább a gépet és programhiba esetén is megjeleníthető legyen. A továbbiakban a 4xx hibák esetén megjelenítendő információs oldalakkal, ezen belül is a leggyakoribb 404-es lapjával foglalkozunk.

Funkciók

Ian Lloyd a "The Perfect 404" cikkében azt javasolja, hogy az oldal tartalmazzon:
  • Navigációs elemeket, legalább egy linket a címlapra vagy honlaptérképre
  • Kulcsszavas keresési lehetőséget
  • Visszafogott grafikát
A kiépített navigációs elemek (pl. menü) segítségével irányítani tudjuk az eltévedt látogatót. Lehetővé tesszük számára, hogy a honlap jól körülhatárolt logikai egységeit röviden áttekintse és kiválassza azt, amelyik érdekli. Egy ilyen hiba oldalon a hagyományos navigáció mellett nagy értéke van a támogatási linkeknek is ("technikai segítség", "webmester", "hiba bejelentése" stb.).

A kulcsszavas keresés szép gesztus a hibaoldalon, hiszen tetszőleges kifejezésre kilistázza a honlap témába vágó oldalait. Ezt érdemes saját kereső programmal vagy a nagyobb keresők sitesearch szolgáltatásával megoldani. Ha nem regisztráljuk az oldalunkat ilyen szolgáltatáshoz, akkor választhatunk a rendelkezésre álló programokból, mint pl. ht://Dig, vagy mi magunk is barkácsolhatunk a meglévő eszközökből, pl. grep. A dinamikus weblapok esetén a keresés nagyobb odafigyelést igényel, nehogy a kódjainkat is megmutassuk a látogatónak.

A visszafogott grafika erősen ízlés dolga, hiszen a robotok úgysem töltik le a képeket. Érdemes úgy megtervezzük a hibalapot, hogy ízléses legyen, de mértékkel, pl. Flash reklámok nélkül. Az is derüljön ki egyértelműen, hogy azért ezt látja a látogató, mert valami hiba történt, ez nem a keresett tartalom.

Az oldal összeállítására Ian Lloyd JavaScript megoldást javasol. Ezáltal a saját 404.html hibakezelő lapunk dinamikussá válhat és kiválasztott paraméterek alapján összeszerkeszthető a tartalma. Ha pedig a böngészőben a látogató letiltotta a JavaScript támogatást, egy statikus lapot kap (<noscript> tagon belüli rész). Ezt én annyiban egészíteném ki, hogy szerintem szerver oldalon érdemes összeállítani egy ilyen dinamikus lapot és akkor teljesen mindegy, hogy van-e JavaScript támogatás, vagy sem. További előnye, hogy a szerver oldalon hozzáférhetünk adatbázisokhoz, a tartalomkezelőhöz stb.

Minta megoldások

Több nagyobb cég honlapját meglátogatva kipróbáltam, hogy mit is gondolnak az ottani programozók a 404 hibaüzenet megjelenítéséről. Érdekes, hogy sokan választották az egyszerű átirányítást, tehát a látogató hiba esetén a címlapra érkezik. PHP-ban ez valahogy így néz ki (legyen a neve "elso404.php"):
<?php header('Location: http://www.mysite.com/'); ?>
Fontos, hogy a HTTP/1.0 (RFC 1945 10.11 pontja) szerint az átirányításban a teljes URL-t illik feltüntetni. Tapasztalataim szerint a relatív URL-eket is lekezelik a böngészők, de alkalmazásuk esetleg nem várt eredményhez vezethet. Működéséhez természetesen be kell állítani a webszerveren is ezt a kódot hibakezelőnek:
  • Apache esetén a .htaccess fájlba vagy a <VirtualHost> beállításainál megadni:
    ErrorDocument 404 /elso404.php
  • Microsoft IIS szerveren az IIS Manager-ben állítható át (help: "About Custom Error Messages").
Az "error 404 page" kulcsszavakra keresve a tréfás lapoktól kezdve a haiku versekkel tarkított hibalapokig sok-sok példát találtam. Az ilyen lapokra vadászóknak tudom ajánlani a 404 Research Lab oldalait. Sajnos a példák keresése közben azt tapasztaltam, hogy ezeket az oldalakat sokan ugyanúgy hibákkal készítik el, mint a honlapjuk többi részét. Kommentár nélkül íme két megoldás a homokaasu.org és index.hu címekről.

A látottak közül nekem a Sun Microsystems hibaüzenete volt a legszimpatikusabb. A hibát úgy erőszakoltam ki belőle, hogy a nemlétező http://hu.sun.com/noezbiztosnincs címet írtam a böngészőbe. A kapott oldal számomra azért tetszetős megoldás, mert:
  • A cégre jellemző navigációs panel látható a lap tetején.
  • A Sun és a technikai központ elérhetősége kiemelt dobozokba került a bal oldalon.
  • A dinamikus tartalomban feltünteti a legutóbb létrehozott és változott URL-ek listáját.
Különösen a legutolsó pont szerencsés, amely megpróbálja kitalálni, hogy miért is történt ez a hiba és aktív segítséget nyújt a látogatónak. Az oldal tartalmaz még egy visszajelzés linket is, amely a látogatóra bízza az eset jelentését.

Hasonlóan pozitív példaként hozhatom fel a Weblabor hibalapját is. Itt a tartalomkezelő rendszer egyik oldalát mutatja meg a webszerver, így a dinamikus részben láthatóak a honlap újdonságai (friss blogmarkok, aktív és új fórumtémák).

Haladó megoldás

Webmester értesítése

Azon kívül, hogy webmesterként időnként átbogarásszuk a szerver logokat, egyéb lehetőségek is vannak. Ha már rászánjuk az időt és dinamikus hibalapot készítünk, legyen része az automatikus visszajelzés is (masodik404.php):
<?php
//... levél a webmesternek ...
$mailbody = 'Request: '. $_SERVER['REQUEST_URI'] ."\n";
$mailbody .= 'Referer: '. $_SERVER['HTTP_REFERER'] ."\n";
$mailbody .= 'User: '. $_SERVER['REMOTE_ADDR'] .' : ';
$mailbody .= $_SERVER['HTTP_USER_AGENT'] ."\n";
mail('webmaster##kukac##mysite.com','404 Error report',$mailbody);
//... a dinamikus tartalom kódja ...
?>
A fenti megoldással a webmester automatikusan kap egy levelet minden hiba esetén. Néhány hét (perc) után az is kiderül, ha elfelejtettünk 'favicon.ico' vagy 'robots.txt' állományokat elhelyezni tárhelyünkön. A HTTP_REFERER segítségével kideríthetőek a szerkesztési hibák (a hivatkozó oldalra rosszul helyeztünk el egy linket), a HTTP_USER_AGENT segítségével (elvileg) eldönthetjük, hogy egy robot kéri-e a lapot, vagy egy ember ül a gépe előtt és böngészget. Ez utóbbi feltétel felhasználható a dinamikus tartalom felépítésében is. A webmesternek küldött levél pedig kiegészíthető egyéb információkkal is, akár a $_SESSION és a $_COOKIE tömbök tartalmával is.

Az elektronikus levélben történő értesítések hátránya, hogy egy rosszul beállított robot vagy egy aktív hacker gyorsan megtömheti a webmester postaládáját. Ennek elkerülésére célszerű saját logfájlt vagy adatbázist használni. Adatbázis esetén induljunk ki valami hasonló szerkezetből (SQLite példa):
CREATE TABLE errorlog (
  ido INTEGER,
  hibakod INTEGER,
  ip VARCHAR(40),
  request VARCHAR(250),
  referer VARCHAR(250),
  user VARCHAR(250)
);
Az elkészített tábla 'ido' eleme tartalmazza a dátumot Unix timestamp formátumban. Feltöltésére az e-mail küldés helyett a következő kódot használhatjuk (harmadik404.php):
<?php
//... adatbázis feltöltés ...
include 'adodb/adodb.inc.php';
$errorDB = &ADONewConnection('sqlite');
$errorDB->PConnect('pathto/logfile.db');

$bind = array();
$bind[0] = intval(date('U'));
$bind[1] = isset($_SERVER['REMOTE_ADDR']) ? substr($_SERVER['REMOTE_ADDR'],0,40) : 'n/a';
$bind[2] = isset($_SERVER['REQUEST_URI']) ? substr($_SERVER['REQUEST_URI'],0,250) : 'n/a';
$bind[3] = isset($_SERVER['HTTP_REFERER']) ? substr($_SERVER['HTTP_REFERER'],0,250) : 'n/a';
$bind[4] = isset($_SERVER['HTTP_USER_AGENT']) ? substr($_SERVER['HTTP_USER_AGENT'],0,250) : 'n/a';

$Query = "INSERT INTO errorlog VALUES(?, 404, ?, ?, ?, ?)";
$ok = $errorDB->Execute($Query, $bind);
//... a dinamikus tartalom kódja ...
?>
A fenti példa ADOdb felhasználásával könnyen átvihető tetszőleges szerverre és adatbázisra. Az SQL utasítás összeállításában a szöveges adatok levágása a substr függvénnyel akkor hasznos, ha valaki megpróbálja túlterhelni programjaink bufferét. A webmester értesítését pedig bízzuk inkább naponta automatikusan (pl. crontab) lefuttatott önálló programra. A site adminisztrációs felületén pedig napló nézegető és elemző menüket helyezhetünk el:
  • Az utóbbi N nap bejegyzései (a határidő számítása PHP-ben : date('U') - $nap*24*3600):
    SELECT * FROM errorlog WHERE ido>={hatarido} ORDER BY ido DESC;
  • Legaktívabb IP címek Top10 listája:
    SELECT ip,count(*) as darab FROM errorlog GROUP BY ip ORDER BY darab DESC LIMIT 10;
    

Mit is keresett...

Különösen nagyobb oldalakon előfordul a tartalmak átszerkesztése, URL-ek eltűnése, átnevezése. Ez zavarba hozza a látogatót és a kereső robotokat is. A zökkenőmentes átállás segítésére megpróbálkozhatunk egy "gondolatolvasó" trükkel. A webszervereken beállítható, hogy a beérkező kérést átfogalmazza. Apache esetén ezt a mod_rewrite modul végzi el. Használata a httpd.conf vagy .htaccess fájlokban a következő:

RewriteEngine on
RewriteRule ^/regiurl(.*) /athelyezett$1
A fenti példával tetszőleges átirányítás megoldható egyszerű regulás kifejezések alkalmazásával, akár másik szerverre is. Átköltözés esetén az Apache dokumentáció a következő mintát javasolja:

RewriteEngine on
RewriteCond /your/docroot/%{REQUEST_FILENAME} !-f
RewriteRule ^(.+) http://webserverB/$1
Amely leellenőrzi, hogy létezik-e a fájl és ha nem, a kérést átküldi webserverB.com-ra. Ez a megoldás természetesen csak a DocumentRoot-on belüli fájlokra használható. A feltétel kicserélhető, és ekkor minden URL-t lekezel:

RewriteCond %{REQUEST_URI} !-U
Sajnos a használata többletmunkát igényel a szervertől, ezért a teljesítmény megtartása érdekében általában a szkriptekre bízzák az átirányítást is. További hátránya, hogy a site-on belüli átirányítás esetén a látogató a régi URL-t is valódinak és érvényesnek látja. Ezt a problémát már csak programozással oldhatjuk meg. A látogatót a megfelelő fejléc elküldésével értesíthetjük arról, hogy ezentúl új címet keressen:

Átirányítási lehetőségek
KódJelentése
300Multiple - több helyre is költözhetett (jelenleg nem támogatott a böngészőkben)
301Moved Permanently - véglegesen áthelyezve
302Moved Temporarily - pillanatnyilag ideiglenesen áthelyezve
304Not Modified - a tartalom nem változott (válasz feltételes kérésre)


A 301 és 302 kódok közötti különbség, hogy a 302 esetében később a tartalom ismét megtalálható lesz az adott URL-n, de a 301 esetében már nem. A 301-es kódot látva a keresőrobotok lecserélik a tartalomhoz vezető URL-t az új címre.

Érdemes tehát esetleg a hibakezelést kombinálni egy átirányítás ellenőrzéssel is. Ekkor figyelni kell arra, hogy az elküldött header információ megelőzzön minden más kiírt szöveget. Sikeres átirányítás során a státusz kód és az új cím megadása után lépjünk is ki a programból. Mivel a REQUEST_URI változó tartalmazza a kérést, célszerű az előbbi adatbázist kiegészíteni egy átirányítás táblával, amiben kereshetünk:

CREATE TABLE redirect (
  id INTEGER,
  regicim VARCHAR(250),
  ujcim VARCHAR(250)
);
Ennek a karbantartása a webmester feladata, a programba illesztése pedig egyszerű (negyedik404.php):
<?php
//... adatbázis feltöltés ...
//... átirányítás, ha lehetséges ...
$kerdes = strtolower(substr(urldecode($_SERVER['REQUEST_URI']),0,250));
$protocol = isset($_SERVER['SERVER_PROTOCOL']) ? $_SERVER['SERVER_PROTOCOL'] : 'HTTP/1.0';
$Query = "SELECT * FROM redirect WHERE regicim = ? LIMIT 1;";
$row = $errorDB->GetAssoc($Query, array($kerdes));
if (isset($row['ujcim'])) {
  header($protocol .' 301 Moved Permanently');
  header('Location: '. urlencode($row['ujcim']));
  exit;
}
//... a dinamikus tartalom kódja ...
?>
A fenti program dekódolja a kérés címét, majd megkeresi az esetlegesen hozzá kapcsolódó átirányítást. Érvényes XHTML generálásakor ugyan problémás az URL paramétereket elválasztó '&' jel, amelyet ott '&amp;' formában illik átadni, a header függvény használatakor az eredeti '&' jelet kell alkalmazni.

Összegzés

A hibalapok közül leggyakrabban a 404-esekkel találkozunk böngészés során. A 404-es hibalapoknak a feladata az eltévedt szörfözők és robotok útba igazítása. A statikus "File not found" szöveg helyett ma már elvárható, hogy a honlapunk navigációs elemei, keresés és dinamikus útbaigazító tartalom jelenjenek meg. Ezeken felül a hibakezelő szkript automatikus értesítő levelet küldhet a webmesternek vagy adatbázisban tárolhatja az eseményeket, a kérés elemzésével pedig megtalálhatja a keresett tartalom új helyét és oda átirányíthatja a látogatót. A honlap programozójának ilyen pár soros apró figyelmességei bőven megtérülnek a site fenntartása és esetleges későbbi átalakítása során.
 
Baranyai László arcképe
Baranyai László
A Budapesti Corvinus Egyetem docense, munkája egyben a hobbija is (szeret oktatni és programozni). Több tudományos honlap tervezője, készítője. Szeret nassolni és saját bevallása szerint jó palacsintát süt.
1

angol v. magyar

Benjamin · 2005. Aug. 29. (H), 07.03
Szerintem nem szerencses keverni a kettot: ido, hibakod, request, referer v. $kerdes, $protocol
10

angol v. magyar

Baranyai László · 2005. Aug. 31. (Sze), 10.40
Ez régi szokásom. Igyekszem magyar nyelven elnevezni azokat a dolgokat, amiket a felhasználó ad meg vagy én magam, és angolul, ami valamilyen automatizmus révén generálódik, pl. a rendszer/gép/kliens/stb. paramétere.
2

Linkek

Anonymous · 2005. Aug. 29. (H), 07.31
Néhány idevágó link:

Creating Custom Error Messages in Apache

adoDB Execute

Az utóbbit azért mert a cikkben kicsit 'piszkos' módon használod.
9

execute javítva

Hojtsy Gábor · 2005. Aug. 30. (K), 10.57
Az Execute() példát javítottam, több ponton lehetett korrektebbé tenni. Köszönjük a linket.
3

html entity?

vince · 2005. Aug. 29. (H), 08.35
"Hasonlóan problémás az URL paramétereket elválasztó '&' jel, amelyet '&amp;' formában illik átadni a header függvényben."

Ez tévedés, ezt a bizonyos '&' jelet csak (x)html kódban illik '&amp;' (ld. html entities) formában írni, a header függvény esetében nem kell a html entity, elég maga a '&' jel (mint ahogy a böngésződ címsorába sem http://www.szerver.hu/index.php?p=x&amp;q=y formában írod az url-t)

----

Az első példaszkript (elso404.php) nem tökéletes ebben a formájában:
<?php header('Location: <a href=\"http://www.mysite.com/');\">http://www.mysite.com/');</a> ?>
4

Első script

Bártházi András · 2005. Aug. 29. (H), 09.44
Javítottuk, a syntax highlighting hibája volt a dolog.

-boogie-
6

html entity?

Anonymous · 2005. Aug. 29. (H), 23.05
Nem csak hogy nem kell a Location-nál &amp;-ot írni, hanem nem is lehet.
Header("Location: file.php?a=1&amp;b=2");
eredménye:
Array
(
    [a] => 1
    [amp;b] => 2
)


Gyulus
7

nem feltétlen

bbalint · 2005. Aug. 30. (K), 08.37
létezik egy olyan konfigurációs beállítás, hogy arg_separator.input ami arra való, hogy a bemenetkor milyen karakter(eke)t tekintsen elválasztónak.
ez alapértelmezésben csak az és-jel (&)
valahol azt ajánlották, hogyha érvényes (X)HTML oldalakat generál az ember, akkor érdemes a pontosvesszőt (;) is belevenni a felsorolásba; így a HTML elemeket nem értő böngészők és internet explorerek kéréseit ki lehet szolgálni helyesen:

GET /index.php?valtozo1=ertek1&#38;valtozo2=ertek2 HTTP/1.0
ekkor a $_GET/$_REQUEST változókban lesz három tömb-elem valtozo1, #38 és valtozo2 kulcsokkal.

bbalint
8

igazatok van

Hojtsy Gábor · 2005. Aug. 30. (K), 10.43
Javítottam a cikket.
5

503

Anonymous · 2005. Aug. 29. (H), 10.03
503-as hibakódra, van itt egy jó megoldás:

http://alo.antville.org/
11

:-))

-ii- · 2005. Szep. 2. (P), 11.04
Ilyen állapotban azért én nem reklámoznám magam...
12

Elköltözött oldal

Anonymous · 2005. Szep. 4. (V), 22.04
Az oldalam nemsokára el fog kölötzni egy másik tárhelyre. És úgy akarom megoldani, hogy ha a régi oldalon hivatkozik pl. a ?p=view&id=4 -re, akkor ezt irányítsa át az új serverre. Ezt ugye a 301-es kóóddal meg is tudnám csinálni, viszont azt hogy tudom megcsinálni, hogy előtt mondjuk 5 mp-ig kiírja, hogy az oldal elköltözött?
13

Új címen

attlad · 2005. Szep. 4. (V), 23.23
Ha a háttérben nyitom meg az oldalt, akkor nem fogom látni az 5 mp-es figyelmeztetést, ezért szvsz inkább az új címen írj ki egy rövid figyelmezetést a tartalom előtt, hogy régi címről érkezett és már új címek vannak, persze csak akkor kell kiírni, ha a régi címről átirányítással került az új címre.

Attila
14

Micsoda ötlet!

Anonymous · 2005. Szep. 5. (H), 13.17
Te ez nagyon jó ötlet! Köszi. Már csak a megvalósítást kell kitalálni. Ugye referrer nem lehet, mert az sok helyen le van tilva. A session mennyire jó megoldás? Vagy csak adjam át egyszerűen url-ben a tényt, hogy a régi oldalról érkezett?
15

URL paraméter

Hojtsy Gábor · 2005. Szep. 5. (H), 13.23
Én URL paramétert használnék, nem olyan kritikus a feladat, hogy ez gond legyen, sessiont nem tudsz használni, mert a kiindulási oldal munkamenet adatai nyilván máshol vannak tárolva, mint a céloldalé.
16

<Nincs cím>

attlad · 2005. Szep. 5. (H), 13.36
Szerintem egy session adat beállítása is megoldás lehet. Viszont ha a domain megváltozott, akkor session sütit nem tudsz beállítani. Ekkor talán kettő átirányításra lehet szükség:

Kérés: http://regicim/oldal.html
Válasz: HTTP 301, ide irányítva: http://ujcim/regi-cimrol-jon/http://regicim/oldal.html

Kérés: http://ujcim/regi-cimrol-jon/http://regicim/oldal.html
Válasz: HTTP 301, ide irányítva: http://ujcim/oldal.html + session adat beállítás, hogy régi címről érkezett

Kérés: http://ujcim/oldal.html
Válasz: HTTP 200, taratlom + figyelmeztetés ha régi címről érkezett

Attila
17

Szerintem...

Anonymous · 2005. Szep. 5. (H), 14.43
Én így gondoltam:

http://regicim/index.php?p=view&id=4
ebből a rquest_uri-ból megkapom a "index.php?p=view&id=4" stringet
és átirányítom a kérést a
http://ujcim/index.php?p=view&id=4&regi=true
és ha regi == true, akkor kiírom a szöveget, hogy új az oldal, meg 200-as státusz.

Ez így milyen
18

<Nincs cím>

attlad · 2005. Szep. 5. (H), 14.57
Én azért írtam a másik megoldást, mert úgy "tiszta" marad a webcím, ha berakod a webcímbe, akkor lehet, hogy a keresőkbe a regi=true végződéssel kerül majd be a cím ami nem biztos, hogy szerencsés (minden keresőből érkező figyelmeztetést fog kapni).

Attila
19

<Nincs cím>

Anonymous · 2005. Szep. 5. (H), 20.33
Igaz. Viszont a http://ujcim/xy/regi_uri -t hogy tudom lekezelni?
Ezt nem Rewrite-al kéne megcsinálni?
mert az új tárhelyemen IIS van.
20

<Nincs cím>

attlad · 2005. Szep. 6. (K), 10.32
Nem kell hozzá, mert ilyen is lehet:
http://ujcim/redir.php?oldUri=http://regicim/index.php?p=view&id=4

De az oldUri paraméter értékét (ebben az esetben is) először át kell kódolni, PHP-ban rawurlencode(), ha minden igaz, bár ez ennél a cikknél már teljesen off.

Attila
21

<Nincs cím>

Anonymous · 2005. Szep. 6. (K), 13.40
http://ujcim/regi/index.php?p=view&id=2
Az is megoldás, hogy a regi mappába is lehelyezek egy index.php-t, ami átirányítja az usert a http://ujcim/index.php?p=view&id=2 -re.

Amúgy ebben a sorrendben kell csinálni az átirányítást: Igaz?
1. az user megnézi a régi oldalt
2. kiadom a 301-es státuszt
3. átirányítom az usert az új címre
4. az új címen kiadok egy 200-as státuszt (vagy ez nem is kell?)
5. átirányatom a végleges címre.
22

<Nincs cím>

attlad · 2005. Szep. 6. (K), 14.32
Ezt kéri: http://regicim/index.php?p=view&id=4
index.php lényegi része kb:

header('Location: http://ujcim/regi/index.php?keres=' . rawurlencode($_SERVER['REQUEST_URI']), true, 301);
Ide kerül: http://ujcim/regi/index.php?keres=%2Findex.php%3Fp%3Dview%26id%3D4
index.php lényegi része kb:

session_start();
$_SESSION['regi-cimrol-jott'] = true;
header('Location: http://ujcim' . $_GET['keres'], true, 301);
Ide kerül: http://ujcim/index.php?p=view&id=4
index.php lényegi része kb:

session_start();
if (isset($_SESSION['regi-cimrol-jott'])) {
    unset($_SESSION['regi-cimrol-jott']);
    echo 'Régi címről jöttél..';
}
echo 'Tartalom';
Attila
23

<Nincs cím>

Anonymous · 2005. Szep. 6. (K), 15.27
Nem a régi oldalon kellene kiadni a 301-es headert?
24

Ki van adva

attlad · 2005. Szep. 6. (K), 15.42
az első sor azt csinálja.

Attila
25

<Nincs cím>

Anonymous · 2005. Szep. 6. (K), 16.14
Bocs. Hülye vagyok. Nem görgettem végig :P
26

Bérelt tárhelyen hogyan tudok ...

klimakiraly · 2005. Szep. 13. (K), 18.16
Hello!

A kérdés tehát hogyan tudom a bérelt tárhelyemen létre hozni hogy meg kapjam a referer-t.
A .htaccess lehetséges beleírtam az első példát, és megírtam a másodikat. De így az URI az az elso.php tehát nem az igazi 404 kérés.

A másik kérdés a 301 kiadása egy megszüntetet oldalnál. (olvasom, de nem értem sajna) Van php nysql meg .htaccess csak magához szerverhez nem férek hozza ugye bár.

K.K.
27

Szerver tulaj?

Bártházi András · 2005. Szep. 13. (K), 19.32
Bérelt tárhely esetén fordulj a tárhely szolgáltatóhoz. Ha nem válaszol, fordulj egy másik tárhely szolgáltatóhoz... :) Miért mi találjuk ki, hogy mit állított be a tárhely szolgáltatód?

A 301 kiadása csak akkor lehetséges, ha a régi szerverhez, régi domain névhez is hozzáférsz. Nyilvánvalóan nem lehetséges, ha nem.

-boogie-
28

Köszi de ..

klimakiraly · 2005. Szep. 13. (K), 19.36
Hello!

Ha jól olvastam a cikket akkor ehhez nem feltétlen kell server admin.
Ami ugyan megoldható hogy írok egy mail-t de én szeretném át állítani az oldalt html-ről php-re. De a régi oldalak hivatkozásait se akarom elveszteni. A keresők meg sajna nagyon lassan felejtenek. :-(
Ezért az adatbázisos - 301 - átirányításig szeretnék eljutni.

Köszi.

K.K.
29

Nem de...

Bártházi András · 2005. Szep. 13. (K), 19.50
Nem, a szerver admin nem kell. De ő tud válaszolni a kérdésedre, hogy ha nem megy valami a cikkben leírtaknak megfelelően, akkor miért nem megy, milyen beállítást engedélyezett, milyet nem. Nem mindenhol engedélyezik a .htaccess használatát, nem mindenhol engedélyeznek egyes beállításokat állítani .htaccess-ből.

-boogie-
30

Re: tárhely szolgáltatón

Baranyai László · 2005. Szep. 14. (Sze), 10.39
Tárhely szolgáltatónál az egyetlen szükséges feltétel, hogy a 404-es hiba kezelőjét ("ErrorDocument" Apache esetén) átállítsa a te PHP kódodra.

Üdv.: BarLac
31

Igen megtettem létre tudok hozni nincs letiltva.

klimakiraly · 2005. Szep. 14. (Sze), 10.48
Hello!

*szerk Jajj látom az URI az jogos, de ugye sokszor nem jön referer. :-(

Igen megtettem egy .htaccess a gyökérbe.
ErrorDocument 404 /elso404.php tartalommal.

A z elso404.php-ba meg a

<?php
//... levél a webmesternek ...
$mailbody = 'Request: '. $_SERVER['REQUEST_URI'] ."\n";
$mailbody .= 'Referer: '. $_SERVER['HTTP_REFERER'] ."\n";
$mailbody .= 'User: '. $_SERVER['REMOTE_ADDR'] .' : ';
$mailbody .= $_SERVER['HTTP_USER_AGENT'] ."\n";
mail('webmaster##kukac##mysite.com','404 Error report',$mailbody);
//... a dinamikus tartalom kódja ...
?>
De így mindig a request_uri az az elso404.php.

Mit csinálok rosszul.

K.K.
32

<Nincs cím>

Baranyai László · 2005. Szep. 14. (Sze), 15.05
"De így mindig a request_uri az az elso404.php"

Akkor ott valami nem stimmel. Nem lehet, hogy van egy RewriteRule, ami nem létező kérés esetén az "elso404.php"-t adja vissza? Egy
<?php
 echo '<pre>';
 print_r($_SERVER);
 echo '</pre>';
?>
egyébként minden más információt helyesen tartalmaz?

Üdv.: BarLac
33

Szerintem nincs semmi baj a szerverrel, én vagyok buta.

klimakiraly · 2005. Szep. 14. (Sze), 18.42
Helló

Nem ReWrite van, én tettem a szolgáltató által adott mappámba (gyökér)

Egy ErrorDucoment ... tartalmú htaccess fájlt.
Mert én így értettem a példát.

Télleg nem tudom hogy kéne.
A htaccess-be írhatok php-t?
Vagy nem tudom.....

K.K.
35

Írhatsz

Anonymous · 2005. Szep. 18. (V), 11.47
Elvileg nekem is ez van, igaz, közvetlenül a szerver confjában.

ErrorDocument 404 http://www.kiszolgalo.com/error/index.php?error=404

Amúgy meg:
http://httpd.apache.org/docs/1.3/misc/custom_errordocs.html

Sok sikert hozzá!
34

Mintha haladnák.

klimakiraly · 2005. Szep. 18. (V), 10.47
Helló!

Az elöbbi kódodban még jó az URI. Közdük még vele, nem tudnám lemásolni a masodik.php-t. :-(

K.K.
36

ez se rossz...

Anonymous · 2005. Dec. 20. (K), 14.31
http://www.ultrashock.com/404/
37

Ez nagyon barátságos:

eMeLA · 2009. Okt. 17. (Szo), 21.18
38

404

Evy · 2012. Okt. 11. (Cs), 21.07
Szia / Sziasztok!

Van egy oldalam,amit már hetek óta nem nyit meg az internet sem nekem,sem másnak. Mivel nem értek hozzá,ezért fogalmam sincs,mit tehetek annak érdekében,hogy sikerüljön helyrehozni.Megoldódik magától is vagy muszáj rásegíteni?Kérlek segítsetek!!!
Előre is köszi!

dr-csont-bonesfanfic.blogspot.com

UI: Sajnos nem értem,ami ide le van írva.

(Ezt írja ki nekem: 404 Not Found nginx/1.1.19 )
39

player

Poetro · 2012. Okt. 11. (Cs), 21.20
A problémát a http://scmplayer.net/script.js szkript okozza. Ez valamilyen player-nek mondja magát, bár igazából nem tudom, mit csinál, mindenesetre minden rajta kívül álló elemet töröl a dokumentumból, így csak ő látszik, ráadásul mivel valami hiba van a kódjában, így ő sem. Legjobb lenne, eltávolítani ezt a szkriptet az oldal forrásából.
40

Köszönöm a gyors választ!!

Evy · 2012. Okt. 12. (P), 06.42
És ezt hogy csináljam?

Kb 2 hónapja felraktam egy zenelejátszót a blogomra,amihez át kellett írni a html címet. Lehet ez a probléma?
41

Eltávolítod

Poetro · 2012. Okt. 12. (P), 07.44
Vagy eltávolítod a lejátszót az oldalról, vagy a mostani beállítások mentén frissíted az oldaladat.
42

Nem tudom mi történt,de végre

Evy · 2012. Okt. 12. (P), 14.22
Nem tudom mi történt,de végre sikerült megnyitni az oldalam!!!! :DD
Köszönöm a segítséget!
43

https://github.com/cshum/SCM-

Poetro · 2012. Okt. 12. (P), 14.59
https://github.com/cshum/SCM-Music-Player/issues/25