- This topic has 6 hozzászólás, 3 résztvevő, and was last updated 14 years, 4 months telt el by
.
-
Bejegyzés
-
Frissen telepítettem az Apache-ot mpm-itk modullal, hogy a usereim jól elkülöníthetőek legyenek. Minden csodás, kivéve azt, hogy a PHP a $_SERVER['REQUEST_URI'] változóba a teljes kérelmezett url-t teszi be (http://www.valami.hu/index.php), nem csak a fájlnevet, ahogyan ezt definíció szerint kellene neki (/index.php).Semmi módját nem találtam, hogy ezen változtassak. Minden Apache és PHP modult kiszedtem már, de akkor is így működik.Az mpm-itk lehet az oka? (Ubuntu 10.04 LTS 64bit)Ha találkozott már valaki hasonlóval, netán a megoldásra is van ötlesze, szívesen olvasnám.
Nem vagyok biztos benne, hogy ennek file nevet kellene tárolni, de fordítva rosszabb lenne, mert az abszolút útvonalat bármikor szétbonthatod, de a file névből…Azt hiszem van erre külön függvény is, amire most nem emlékszem, de elvileg meg lehet csinálni az explode függvénnyel is.
A php.net szerint a fájlnevet kell tárolnia, mint minden más php-t futtató szerveremen is a fájlnevet tárolja.Egyedi esetben le lehetne vágni az url elejét, de erre a szerverre kész oldalak fognak költözni, mint például WordPress motorral készültek, ami elhal ettől a kis bug-tól.Mivel ezeket a tartalmakat nem én fogom kontrolálni, nincs más mód, mint a REQUEST_URI egészséges értékénjek elérése... 🙁
Magában a névben semmi nem utal arra, hogy ez egy filenév, sőt kifejezett filenevet ritkán neveznek uri-nek, vagy url-nek (de természetesen megeshet).Szerintem az, hogy egy kért uri abszolút helyet határoz meg nem bug, az, hogy egy akármi elhasal emiatt, az inkább tartanám hibának.[man url=http://www.php.net/manual/en/reserved.variables.server.php doc=a php.net szerint]"The URI which was given in order to access this page" szintén nem pont azt jelenti, hogy ez egy file-név, bár lehet az is, de annak feltételei vannak: azaz ha jól értem akkor az, ha azzal el lehet érni az oldalt... ha nem, akkor nem is lehet az. Azaz feltehetőleg függvénye annak, hogy honnan és hogyan éred el. Az abszolút elérési útvonallal viszont ilyen gond nem lehet. Sőt mi van, a "?..." akármivel? Lehet, hogy egy index.php simán értelmetlen.[/man]Persze, lehet, hogy én nem értem jól.Közben megtaláltam a fent említett függvényt: "pathinfo".
Tény, hogy a WordPress úgy kezeli, mintha csak a fájlnévrész lenne a REQUEST_URI-ban.Tény, hogy az összes többi - általam eddgi elért - szerveren ebben a változóban csak a fájlnév rész szerepel.Tény, hogy a php.net is példának a /index.html-t írja, és sehol nem tesznek említést arról, hogy ez más is lehet, vagy hogy bármi befolyásolhatná az érték minőségét.Ha ez egy rendesen valamitől függő érték lenne, akkor az érdekelne, mitől függ, és hogyan tudom ezt átállítani? Félek azonban, hogy a REQUEST_URI-ban csak a fájlrésznek kell szerepelni olyannyira, hogy erről külön senki nem emlékezik meg.(Egyetlen helyet találtam a google-ban, ahol egy rosszul konfigurált szerver cgi módban úgy futtatta a php-t, hogy a REQUEST_URI-ba a teljes url belekerült, de ott is hibaként említették ezt, és megoldásként a .htaccess-sel levágták az érték elejét. Ez nagyon csúnya megoldás lenne teljes szerverszinten.)
Most is tanultam …A kérdéses szerverre átvitt oldalakat először csak ellenőrizni akartam, hogy a verzióváltások miatt minden rendben van-e. Ezért - bár az oldal egy eredeti helyen még üzemelt - a böngészőben az új szervert adtam meg, mint proxy szervert.Ha a php oldalt proxy szerverként nézem meg, akkor a REQUEST_URI-ba a teljes url belekerül, míg ha élesben nézem, akkor a REQUEST_URI csak a fájlrészét tartalmazza a kérelemnek ...Érdekes. Már csak azért is, mert ugyanez a webszerver a cgi scriptek esetén függetlenül attól, hogy proxy-nak volt-e állítva vagy sem, a REQUEST_URI-ba csak a fájlnév részt helyezte be.No, mindegy. Legalább kiderült ... majd tesztelek máshogy 😉
- Be kell jelentkezni a hozzászóláshoz.
legutóbbi hsz