Tartalom

Bevezető

A .htaccess fájlok nagyon hasznos kellékei az Apache webkiszolgálónak, amiknek a hatékony használatával sok problémát megoldhatunk. Azonban egy összetettebb szerverkonfiguráció esetén több dologra is oda kell figyelnünk, különben könnyen Apache hibákat generálhatunk.

Ebben a hibaelhárítóban az átirányításokkal foglalkozunk, ahol bizonyos helyzetekben végtelen átirányítási ciklusba kerülhetünk, ami végül az "AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error." tartalmú hibákhoz vezet.

A hibajalenség

Az Apache hibanaplóba (error.log) tekintve az alábbihoz hasonló hibaüzeneteket találunk (az áttekinthetőség kedvéért több sorba tördeltem):

[Tue Sep 20 22:42:28.956778 2022] [core:error] [pid 18374:tid 140539768854272] [client 116.179.37.84:30821] 
AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. 
Use 'LimitInternalRecursion' to increase the limit if necessary. 
Use 'LogLevel debug' to get a backtrace., referer: https://www.linuxportal.info/leirasok/

Ez az azt jelenti, hogy egy Apache beállítás során, például valamelyik .htaccess fájlunkban egy átirányításunk következtében a végrehajtás egy végtelen ciklusba került, így az Apache letiltotta az átirányítási láncot a konfigurációban megadott 10 átirányításnál, és leírja, hogyan lehet megemelni ezt a limitet, stb.

Ez ugyan nem egy nagy hiba, mert ahogy a hibaüzenetben is jelzi az Apache hogy 10 átirányításnál leállította a végrehajtást. Ilyenkor végül egy 500-as HTTP válaszkódot kap a kliens, ami az "Internal Server Error" típusú hiba kódja. A fenti hibaüzenetek - ebben a szituációban - az Apache naplóban (access.log) lévő alábbi 500-as hibakódú bejegyzésekhez társulnak.

116.179.37.84 - - [20/Sep/2022:16:39:50 +0200] "GET /sites/default/files/theme/linux-logo_kicsi.png HTTP/1.1" 500 5674 
"https://en.linuxportal.info/" "Mozilla/5.0 (compatible; Baiduspider-render/2.0; +http://www.baidu.com/search/spider.html)"

Itt láthatjuk, hogy ugyanarról az IP-címről van szó, ami itt egy robot (Baidu spider).

A hiba oka

Egy Apache RewriteRule szabállyal letiltottuk a nem kívánatos robotokat, ami bizonyos szituációk esetén végtelen átirányítási ciklusba terelheti a webkiszolgálót.

Ennek oka nagyon sokféle lehet, de ebben a szituációban a következő:

Itt az alábbi Apache .htaccess átirányítási szabály mintát alkalmaztuk:

RewriteCond %{HTTP_USER_AGENT} ^.*(Baiduspider|robot2|robot3|stb).*$ [NC]
RewriteRule .* - [F,L]

Ez a szabály röviden a következőt csinálja:

• RewriteCond sor: Amennyiben a böngészőazonosító tartalmazza a zárójelben felsorolt neveket, akkor
• RewriteRule sor: Visszaad egy 403 Forbidden választ, és 

Felhasznált flag-ek:

• [NC]: No case-sensitive, azaz figyelmen kívül hagyja a kis- és nagybetűket, tehát beírhatjuk csak kisbetűkkel is a robotok nevét. Forrás.
• [F]: Forbidden. A flag hatására a kiszolgáló egy 403 Forbidden válaszkódot ad a kliensnek. Forrás.
• [L]: Last. Utasítja a mod_rewrite Apache modult, hogy állítsa le a további szabálykészletek végrehajtását a .htaccess fájlban. Forrás.

Tehát elvileg az "L" zászló hatására meg kellene állnia a további szabályok feldolgozásának, azonban bizonyos esetekben nem ez történik.

Lényegében annyi történik, hogy ha olyan szerver konfigurációnk van, ahol egyedi hibaoldalakat használunk, akkor a rendszer az adott HTTP hibakódok esetén átirányítja a klienst a hibának megfelelő hibaoldalra. És ha ez a beállítás nem egy .htaccess fájlban van beállítva, hanem például egy weboldal virtualhost fájljában, akkor a végrehajtási sorrend és prioritási szabályok alapján ott még végrehajtásra kerül egy további átirányítás az egyedi hibaoldalra. 

Jelen esetben ezzel csak annyi a probléma, hogy a fenti RewriteRule szabályunk a felsorolt robotoknak ad egy 403 Forbidden fejlécet, majd leállítaná a kiszolgálás  végrehajtását. De a prioritási szabályok alapján ez után jön az Apache egyedi hibaoldalas beállítása, ami ilyenkor a 403-as hibakód hatására átirányítja az egyedi hibaoldalra, ami egy új lekérés keretén belül történik, így a .htaccess fájlunk újra végrehajtásra kerül. Mivel a robotot tiltja az általunk beállított egyszerű szabály, így ezt az egyedi hibaoldalt sem érheti el, mert a RewriteRule onnan újra kitiltja egy 403-as fejléccel. Ezután a rendszer ismét átirányítja az egyedi hibaoldalra. Ezáltal a kör bezárul, és egy végtelen ciklusba lép a végrehajtás.

Ez persze nem probléma, mivel az Apache a beállított limit után leállítja az egész folyamatot, tehát a robot végül - az eredeti célnak megfelelően - tiltásra kerül, viszont ilyenkor a kiens - jelen esetben a robot - egy 500-as hibakódot kap, ami az Internal Server Error hibakódja. Továbbá a hibanaplónkat is teleszórja a fentebb is bemutatott "AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error. " tartalmú hibaüzenetekkel. És mint tudjuk, a robotok elég sűrűn járnak, tehát jó sok AH00124 típusú hibaüzenetünk lesz a hibanaplófájlban.

Így van ez például az ISPConfig-os szerverkörnyezetek esetén is, ahol a webtárhelyek a webgyökér alatt tartalmaznak egy /error alkönyvtárat, amiben benne vannak a különböző hibakódokhoz tartozó egyedi (ISPConfig fejlesztők által készített) html oldalak, mint például a 403.html is. Majd az oldal virtualhost fájljában pedig a következő részlet gondoskodik a hibaoldalak kezeléséről:

[...]
Alias /error/ "/var/www/linuxportal.info/web/error/"
ErrorDocument 400 /error/400.html
ErrorDocument 401 /error/401.html
ErrorDocument 403 /error/403.html
ErrorDocument 404 /error/404.html
ErrorDocument 405 /error/405.html
ErrorDocument 500 /error/500.html
ErrorDocument 502 /error/502.html
ErrorDocument 503 /error/503.html
[...]

Ha tehát a robotok 500-as HTTP hibakóddal kerülnek tiltásra, az még nem a világvége, csak egy kis szépséghiba, amit most javítunk.

A megoldás

A hibaüzenetben írja, hogy emelhetjük a belső átirányítások limitjét is, de ez nem jó megoldás, mivel egy végtelen ciklussal van dolgunk, így akármennyire is emelhetnénl ezt a limitet, nem oldaná meg a problémát.

A helyes megoldás ennél jóval egyszerűbb, amit a hiba okában kell keresnünk.

Hogy feloldjuk ezt a végtelen ciklust, elegendő betenni az átirányítási szabályunkba egy kivételt, ami megakadályozza az újbóli átirányítások sorozatát.

RewriteCond %{REQUEST_URI} !^/error/403\.html
RewriteCond %{HTTP_USER_AGENT} ^.*(Baiduspider|robot2|robot3|stb).*$ [NC]
RewriteRule .* - [F,L]

Az első sor tehát a megoldás. Ez annyit csinál, hogy egy további feltételben ellenőrzi, hogy a lekérés URL címe nem éppen maga a 403-as egyedi hibaoldal. Tehát csak akkor hajtja végre a 403 Forbidden válaszkód visszaadását, ha kliens éppen nem magán a hibaoldalon tartózkodik. Tehát ezzel betettünk egy kivételt, ami nem engedi a kiszolgálót végtelen átirányítási ciklusba.

Ha ezt a feltételt betettük a .htaccess fájlunkba, akkor  nem kapunk többé "AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error" típusú hibaüzeneteket, és a kliensek is 403-as (Forbidden) hibakódokat kapnak az 500-as (Internal Server Error) helyett.

Példa:

cat access.log | grep -E " 403 | 500 "

[...]
5.255.253.183 - - [22/Sep/2022:13:58:05 +0200] "GET / HTTP/1.1" 403 6811 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"
5.255.253.183 - - [22/Sep/2022:15:15:21 +0200] "GET /robots.txt HTTP/1.1" 403 6811 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"
216.244.66.248 - - [22/Sep/2022:15:53:15 +0200] "GET /robots.txt HTTP/1.1" 403 6728 "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; help@moz.com)"
[...]

Mint már korábban említettem, ez a hiba nem okoz semmi gondot, csak teleszemeteli a hibanaplófájlunkat, ezért érdemes elvégezni ezt a módosítást.

Konklúzió

Ezt a kis hibaelhárítót a Hogyan tartsuk távol szerverünk weboldalaitól a nem kívánatos robotokat című korábbi leírásom kiegészítőjének szánom, ahol már nem akartam ezekkel a részletekkel eltérni a leírás fő témájától. Így tehát ezek az információk konkrétan ehhez a specifikus esethez kapcsolódnak, azonban ennek analógiájára építve javíthatunk más eredetű AH00124 típusú Apache hibákat is.