ugrás a tartalomhoz

Relatív abszolút hivatkozások

Marcell · 2007. Júl. 19. (Cs), 13.48
Sziasztok!

A problémám röviden az, hogy rossz helyen keresi a böngésző a fájlokat, pedig elvileg jól van megadva - elvileg...

A kód elején van egy 
<base href="http://lalala.hu/" />
sor, ezután pedig mondjuk egy ilyen sor van: 
<link rel="stylesheet" href="/css/style.css" type="text/css" media="all" />
Teszteltem Firefox 2, IE6, IE7, Opera 9 alatt és minden tökéletes volt, mégis a 404 naplóban olyanokat látok, hogy http://lalala.hu/zenekarok/css/style.css, ami ugye úgy jön ki, hogy a http://hallgass.hu/zenekarok maga a rövid webcím és utána rakja a css/style.css-t.

Már több hete ölöm magam ezen és minden különböző változatot kipróbáltam, de csak nem szűnnek meg a hibák a naplóban.

Első körben azt kérdezném, hogy van-e olyan böngésző, ami másképp kezeli ezeket a hivatkozásokat, ha pedig nincs ilyen, akkor mit rontok el??? Már nagyon unom a hibaüzeneteit...
‹ Weboldal megjelenítése új rétegként Nem működő tallózás gomb ›
 ■
1

User agent?

janoszen · 2007. Júl. 19. (Cs), 14.38
Nézd meg a user agent mezőt is, lehet hogy valamelyik bugyuta bot okoz fejfájást Neked.
2

köszi

Marcell · 2007. Júl. 19. (Cs), 15.04
Ez eszembe sem jutott volna, már nem látom a fától az erdőt.. :) Most viszont beraktam és sasolok pár napig, folytatás várhatóan hétfőn.
3

Hmm...

Ronyn · 2007. Júl. 19. (Cs), 15.21
Az nem lehet hogy kétféleképp van irva? Pl.: ./css/style.css<=>/css/style.css
Előbbi esetben lehet hogy hozzáadja az aktuális konyvtárat...
4

Nem.

Marcell · 2007. Júl. 21. (Szo), 15.43
Ez nem lehet hiba, mert a style.css csak egyetlen helyen van a kódban és ott is jól.
5

Érdekes eredmények...

Marcell · 2007. Júl. 21. (Szo), 15.59
http://lalala.hu/koncertek/function.mysql-insert-id, USER_AGENT: Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html: erre van valakinek tippe, mi lehet??? Ilyen link biztos nincs az oldalamon és nem is hiszem, hogy kívülről így linkelnének be hozzám. :D
6

Hibajelzés

Ronyn · 2007. Júl. 21. (Szo), 16.07
Gondolom rákattant egy php hibajelzésre az oldaladon,ugy kerulhetett bele (referrer?)
Ugyhogy ha használod a mysql_insert_id() függvényt,azt is ellenőrizheted...
7

Hibakezelés

Marcell · 2007. Júl. 21. (Szo), 16.36
A hibákat nem iratom ki, tehát ez rossz irány.

Mellesleg naplózom is őket, és a naplóban ilyen jellegű hibák nincsenek.
10

E WARNING

Ronyn · 2007. Júl. 21. (Szo), 20.52
Bizonyos hibákat beállitástol fuggetlenul is kiir a php,ugyanakkor a saját hibakezelőbe nem jegyzi be...
Szoval...
11

hmm

Marcell · 2007. Júl. 22. (V), 14.51
Ebbe nem akartam ilyen mélyen belemenni, de akkor lássuk:
- az oldalon csak olyan helyen használom a függvényt, ahol semmilyen kiírás nincsen, lefut és ha jó, ha nem továbblép. Tegyük fel, vmi core hiba van (bár 100x volt tesztelve) és mégis kiírta.
- Ahhoz, hogy a Google linkként értelmezze, bele kéne kerülnie egy <a> tagba. Ez teljesen valótlan, mert semmi ilyen kód nincs, de tegyük fel még ezt is összehozta kedvenc keresőnk.
- Ilyen hozzáadásokat csakis regisztrált felhasználók csinálhatnak. Azt már tényleg nem tudom elképzelni, hogy a Google kitöltse a regisztrációs űrlapot, megadjon egy formailag megfelelő e-mail címet, elfogadja a szabályzatot, aktiválja a levélben megadott kódjával a profilját, majd belépve megpróbáljon új programokat hozzáadni... :D

Úgyh ez halott ötlet.
12

hiba kijelzés, loggolás

Hodicska Gergely · 2007. Júl. 22. (V), 16.13
A fenti hozzászólás teljesen false. Ha a display_errors ki van kapcsolva, akkor biztosan nem kerül megjelenítésre PHP hibaüzenet. Másrészről ha be van kapcsolva a loggolás (log_errors), akkor minden hiba loggolásra kerül, kivéve ha azt saját hibakezelővel kezeljük.


Üdv,
Felhő
13

Tapasztalatom szerint...

Ronyn · 2007. Júl. 22. (V), 18.15
"Mellesleg naplózom is őket,..."
Abból indultam ki,hogy saját hibakezelő van alkalmazva(set_error_handler),igy "kivéve ha azt saját hibakezelővel kezeljük." vagyis igy valoban nem biztos hogy bejegyzésre kerül.

"Ahhoz, hogy a Google linkként értelmezze, bele kéne kerülnie egy <a> tagba."
Láttam egynémely esetben hogy a a php linkként jeleníti meg a hibát okozó függvény nevét-arra nem emlékszem,hogy ez csak bizonyos esetekben vagy bizonyos verziónál,vagy beállítás(html_errors) van-e igy.

error_reporting(0);
ini_set("html_errors","Off");
ini_set("display_errors","Off");
set_error_handler("logerror");
Nálam ilyen induló beállítás mellett is jelenik meg hibaüzenet,mégpedig:
Warning: Unknown(): A session is active. You cannot change the session module's ini settings at this time. in Unknown on line 0
...és az adott függvénynél megszakad a program futása...
Ez egy fsockopen hivás esetén jelentkezik bizonyos esetekben...
És végül egy idézet a php manualból-azt hiszem?-hogy vonatkozik erre az esetre...
"A következő hibafajták nem kezelhetők le saját, felhasználói hibakezelő-függvényekkel: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR és E_COMPILE_WARNING."
14

...szintén

Hodicska Gergely · 2007. Júl. 23. (H), 01.02
Abból indultam ki,hogy saját hibakezelő van alkalmazva
Én nem láttam erre utaló megjegyzést a hozzászólásban, de ha saját hibakezelőt használsz, akkor nyilván a Te felelősséged, hogy mit kezdesz a hibával. Mondjuk azt is megteheted, hogy FALSE értékkel térsz vissza belőle, mely esetben beindul a PHP saját loggoló mechanizmusa (már amennyiben engedélyezted azt).

error_reporting(0);
ini_set("html_errors","Off");
ini_set("display_errors","Off");
set_error_handler("logerror");
Nálam ilyen induló beállítás mellett is jelenik meg hibaüzenet,mégpedig:
Warning: Unknown(): A session is active. You cannot change the session module's ini settings at this time. in Unknown on line 0
...és az adott függvénynél megszakad a program futása...
Ez egy fsockopen hivás esetén jelentkezik bizonyos esetekben...
Hát ez elég gyanús. Az ini_set után biztosan nem jelenhet meg hibaüzenet a képernyőn. Azt tudom elképzelni, hogy a hibát kiváltó kód még az ini_set állítás előtt fut le. Első blikkre pl. egy olyat el tudok képtelni (az fsockopen nem nagyon eredményhetné ezt az üzenetet), hogy megpróbálsz session beállítást változtatni, miközben a session már elkezdődött (pl. session autostart). Persze lehet, hogy van valami bibi a PHP-éddal, de ennek nagyon kicsi az esélye. Mutasd meg a kérdéses kódot!

És végül egy idézet a php manualból-azt hiszem?-hogy vonatkozik erre az esetre...
"A következő hibafajták nem kezelhetők le saját, felhasználói hibakezelő-függvényekkel: E_ERROR, E_PARSE, E_CORE_ERROR, E_CORE_WARNING, E_COMPILE_ERROR és E_COMPILE_WARNING."
Ezek olyan hibák, amelyek esetén a kódod kb. nem indul el, vagy parse error, illetve nem létező függvény meghívása, de az általad leírt esetben erről nincs szó. Ez is erősíti bennem a gyanút, hogy Te rontasz el valamit.


Üdv,
Felhő
15

Én is találkoztam már ezzel

zila · 2007. Júl. 23. (H), 10.33
Nálem akkor csinált ilyet, amikor egy osztályon belül lévő adodb kapcsolat objektumot próbáltam átadni egy másik (singleton) osztálynak. Kikapcsolt hiba megjelenítés mellett is megjelent a Warning: unknown() in line 0...
16

Re

Ronyn · 2007. Júl. 23. (H), 13.39
Mivel a Php alapbeállítás szerint-általában-amugyis naplózza a hibákat,ezért-ha valaki külön megjegyzi,hogy naplózza is őket-én saját hibakezelőre gondolok... de végülis ez mindegy...

"Az ini_set után biztosan nem jelenhet meg hibaüzenet a képernyőn. Azt tudom elképzelni, hogy a hibát kiváltó kód még az ini_set állítás előtt fut le..."


A program igy kezdődik:

<?php
error_reporting(0);
ini_set("html_errors","Off");
ini_set("display_errors","Off");
tehát minden ez után következik...

Az adott hiba jelen esetben szándékosan lett előidézve(hibás erőforrás azonosító átadása az fputs() függvénynek az fsockopen hivás után),tehát egyértelmüen kodhiba,,de ennek -jelen esetben-nincs jelenősége,mivel most pusztán arról van szó hogy
"Bizonyos hibákat beállitástol fuggetlenul is kiir a php..."
,és pusztán azért kellett szándékosan,mert nem emlékeztem hogy egyébként mikor is szokott ilyen előfordulni,pedig már más esetben is előfordult hasonlo "WARNING" jellegű hibaüzenet fejlesztés során,az adott ini beállítások mellett(és ugy látom,másnál is előfordult már-hogy milyen okból az jelen esetben mindegy))).
Egyébként a session is az oldal/program elején van indítva,a saját kezelők regisztrálása után-hasonlóan az ini és egyéb beállításokhoz.
Az oldal fejrésze meg is jelenik,de a tulajdonképpeni tartalom már nem(az adott függvény egy rss olvasó lenne,ahhoz használom az fsockopen-t)
A php verzió:4.3.3
Van regisztrálva "register_shutdown_function" is,(szintén az oldal tetején)bár nem hiszem hogy az küldené vissza az adott hibajelzést-viszont a manuálban csak egy helyen találtam az Unknown() "függvényre" utalást:
"Általában a nem definiált függvények fatális hibát okoznak a PHP-ben, de ha a register_shutdown_function()-nak átadott function paraméter nem definiált függvényt tartalmaz, egy E_WARNING szintű hiba keletkezik. A PHP belsejéből származó okok miatt ez a hibajelzés a 0.-dik sorban az Unknown() nevű függvényre fog hivatkozni."

Az hogy ez csak az adott verzió sajátossága,vagy egy általános "php belső hiba",azt nem tudom,de mindenesetre létező jelenség(és nemcsak nálam fordult már elő),igy azt hiszem mégsem "teljesen false" amit irtam...
17

Rere

Hodicska Gergely · 2007. Júl. 23. (H), 21.02
Mivel a Php alapbeállítás szerint-általában-amugyis naplózza a hibákat
Alapbeállítás szerint biztosan nincs bekapcsolva hibák logolása.

A hibát nem sikerült reprodukálnom, de elhiszem, hogy volt ilyen, de ez akkor sem "szokás", inkább egy elég ritka bug lehet.

Az hogy ez csak az adott verzió sajátossága,vagy egy általános "php belső hiba",azt nem tudom,de mindenesetre létező jelenség(és nemcsak nálam fordult már elő),igy azt hiszem mégsem "teljesen false" amit irtam...
Ok, az első részét visszavonom. ;)


Üdv,
Felhő
18

újabb fura URL

Marcell · 2007. Aug. 6. (H), 14.55
http://lalala.hu/_vti_bin/_vti_aut/author.dll - ezt is én iratom ki szerintetek? :) Ezek ilyen próbálkozó robotok gondolom - "USER_AGENT: core-project/1.0".. Nem igazán értem, mi értelme bepróbálni ezt az URL-t bárkinek/bárminek is???
19

törési kísérlet

zila · 2007. Aug. 6. (H), 18.48
Ez tipikusan egy felderítés, hogy használsz-e frontpage extension-t, mert ha igen, akkor az emberünk (robotunk) megpróbálja kihasználni annak hibáját, hogy betörhessen a szerverre.
20

hehe

Marcell · 2007. Aug. 6. (H), 22.10
Miért, a Frontpage .dll fájlokat tölt a szerverre? :)
21

haha

zila · 2007. Aug. 7. (K), 15.28
Idézek magamtól:
frontpage extension


És igen a frontpage extension dll-eket használ (legalábbis IIS-en). Meglepő módon.
22

hihi

Marcell · 2007. Aug. 7. (K), 23.31
Na jó, de a public_html-en (vagy hívják ahogy akarják IIS-ben) belül...?? Ez valami iszonyat hülységnek tűnik így elsőre nekem...
23

bezony

zila · 2007. Aug. 8. (Sze), 13.08
Csinál mindenféle _vti_akármi foldereket és bizony oda pakolgat mindenféle binárist, ha jól emlékszem, utoljára 96-97 körül használtam... Meg aztán attól mert az url http://example.com/_vti_bin attól még nem biztos, hogy az a docrootban van, alias is lehet...
24

Még egy ok...

Marcell · 2007. Aug. 8. (Sze), 13.31
Még egy ok, hogy ne használjak ilyet...
8

url

Harder · 2007. Júl. 21. (Szo), 17.03
Most lehet hogy hülye kérdésem lesz, de miért nem jó a 
<link rel="stylesheet" href="http://lalala.hu/css/style.css" type="text/css" media="all" />
?
9

sok helyen van így

Marcell · 2007. Júl. 21. (Szo), 17.18
Nem csak a style.css-t nem találja, hanem a JS-eket se, és néha még a képeket is így keresi. Összefüggéseket még nem igazán találtam, mert ha én nézem (akármelyik böngészővel), soha egy hiba, a naplóba viszont időnként bekerül egy két fincsi URL.

Sok helyen "beleégetni" az előtagot macera, meg el is veszti a kód a rugalmasságát, nem beszélve arról, hogy sok felesleges betű kerül a kódba, ami lassítja az oldal letöltését.