Category: Bugs | Vulnerabilities

The requested URL is too large to process.

Friday, 16. November 2012 / / 0 Comments

Eine interessante Meldung, vor allem weil es dem Chrome Browser handelt und bei der Webseite die Google Webmaster Sitemap, bei dem Versuch meine Nachrichten bzgl. den Crawling-Fehlern, zu löschen. Lustig auch das Title Tag “Error 414 (Request-URI Too Large)!!1” fehlt nur noch das hinten “elf” steht. Nach einer Überprüfung (www.zeichenzähler.de) stellte sich heraus das die URL tatsächlich 3130 Zeichen enthält. In einer Antwort auf Stack Overflow (http://stackoverflow.com/questions/6955302/http-error-414-the-request-url-is-too-long) wird die praktikable Länge mit 2000 Zeichen angegeben.

Der Wikipedia Artikel Query String (http://en.wikipedia.org/wiki/Query_string) benennt explizit den Internet Explorer und das dieser nur maximal 2083 Zeichen in der URL versteht. Ich bin mir nicht sicher, warum die URL in meinem Fall so lang ist bzw. die Daten nicht mit POST übertragen werden. Trotz der Fehlermeldung wurden meine Nachrichten gelöscht, was ich jetzt unbedingt erwartet hätte.

Google Webmaster Sitemap: Gekürzte Antwort Teil 2

Tuesday, 13. November 2012 / / 0 Comments

Wie angekündigt, habe ich meine Seite nochmals mit wGet gespidert, zunächst nach der selben Methode wie im Artikel “Googlebot can’t access your site” beschrieben. Um das Logfile zu minimieren habe ich zusätzlich die Option -A html hinzugefügt, damit nur html Dateien und keine Bilder, JavaScript und Anderes herunterladen geladen wird. Im Logfile konnte ich keine Auffälligkeiten entdecken.

Als nächstes schrieb ich zwei kurze PHP-Skripte:

[PHP]
// file: start.php

$link = mysql_connect(DB_HOST, DB_NAME, DB_PASSWORD);
if (!$link) {
die(‘Could not connect: ‘ . mysql_error());
}

$db_selected = mysql_select_db(DB_NAME, $link);

mysql_query(“INSERT into statistik (ip, token, time1, script)
VALUES (‘”.$_SERVER[‘REMOTE_ADDR’].”‘, ‘”.$_SERVER[‘REQUEST_TIME’].”‘,'”.microtime().”‘,'”.mysql_real_escape_string($_SERVER[‘REQUEST_URI’]).”‘ );”);

mysql_close($link);
[/PHP]

und passend dazu auch

[PHP]
// file: stop.php

$link = mysql_connect(DB_HOST, DB_NAME, DB_PASSWORD);
if (!$link) {
die(‘Could not connect: ‘ . mysql_error());
}

$db_selected = mysql_select_db(DB_NAME, $link);

$str = “UPDATE statistik SET time2 = ‘”.microtime().”‘
WHERE ip = ‘”.$_SERVER[‘REMOTE_ADDR’].”‘ AND token = ‘”.$_SERVER[‘REQUEST_TIME’].”‘ AND script = ‘”.mysql_real_escape_string($_SERVER[‘REQUEST_URI’]).”‘;”;

mysql_query($str);

mysql_close($link);
[/PHP]

diese wurden direkt in die index.php eingebunden:

[PHP]
// file: index.php

define(‘WP_USE_THEMES’, true);

require(‘./start.php’);

/** Loads the WordPress Environment and Template */
require(‘./wp-blog-header.php’);

require_once(‘./stop.php’);
[/PHP]

Zunächst vermutete ich, das es am Favicon.ico liegen könnte

[PHP]
IP Token time1 time2 Script
6.23.4.8 1352762248 0.29693200 1352762248 0.43673200 1352762248 /5/google-webmaster-sitemap-gekurzte-antwort/2012/11/11/
6.23.4.8 1352762251 0.13867900 1352762251 /favicon.ico
6.23.4.8 1352762330 0.97333000 1352762330 0.10298000 1352762331 /5/google-webmaster-sitemap-gekurzte-antwort/2012/11/11/
6.23.4.8 1352762337 0.54685600 1352762337 /favicon.ico
[/PHP]

Also bastelte ich eines, es kam aber weiterhin zu Datenbank-Einträgen bei denen keine “time2” angegeben war.

Erst nach dem ich den WordPress Quick Cache abgeschaltet hatte, wurde auch immer eine time2 eingetragen. Mal schauen was Google bzw. Webmaster Sitemap Tools beim nächsten Crawlen sagen.

Google Webmaster Sitemap: Gekürzte Antwort

Sunday, 11. November 2012 / / 0 Comments

Schon seit längerem zeigen die Google Webmaster Sitemap, unter dem Menüpunkt Crawling-Fehler, an dass bis zu 78% der BugBlog Seiten eine “Gekürzte Antwort” zurückgeben. Vor einem Monat waren es noch überwiegend “Zeitüberschreitung beim Verbindungsaufbau”, die jedoch durch die Deinstallation einer WordPress-Erweiterung, mit welcher PHP-Code direkt in einen Post geschrieben werden konnte und damit inkompatibel war zu einer Erweiterung um PHP-Code hervorzuheben, behoben wurde.

Im Access-Logfile vom Apache lässt sich das Ganze nachvollziehen. Neben der Größe muss dabei auch der Statuscode berücksichtigt werden, da bspw. Urls ohne abschließenden / einen 301 (Redirect) zurückliefern. Der Aufbau findet sich hier: http://httpd.apache.org/docs/2.2/logs.html

[PHP]
[04/Nov/2012:22:28:57 +0100] “GET /seo/bots-bots-bots/2011/05/29/ HTTP/1.1” 200 7547 “-” “Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)”
[08/Nov/2012:12:39:03 +0100] “GET /seo/bots-bots-bots/2011/05/29/ HTTP/1.1” 200 29952 “-” “Mozilla/5.0 (compatible; Infohelfer/1.3.0; +http://www.infohelfer.de/crawler.php)”
[09/Nov/2012:04:23:32 +0100] “GET /seo/bots-bots-bots/2011/05/29/ HTTP/1.1” 200 29950 “-” “Mozilla/5.0 (compatible; SISTRIX Crawler; http://crawler.sistrix.net/)”
[10/Nov/2012:20:14:27 +0100] “GET /seo/bots-bots-bots/2011/05/29/ HTTP/1.1” 200 7528 “-” “Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; […])”
[/PHP]

Es ist erkennbar, das immer der Erfolgs-Statuscode 200 (OK) zurückgegeben wird, die Antwort jedoch zwischen 7547 und 29952 Bytes variiert. Kleinere Abweichungen sind dabei durchaus möglich, weil unterhalb der Posts verschiedene weitere relevante Posts angezeigt werden. Dies erklärt aber nicht eine Abweichung von bis zu 75% nach unten.

Google Webmaster Sitemap URL Fehler vom BugBlog

Als nächstes werde ich nochmal mit wget versuchen dem Fehler auf die Spur zu kommen, bzw. habe ich das LogLevel im Apache auf “info” gestellt und erhoffe mir dadurch weitere “sachdienliche Hinweise” ;-) Die Google Webmaster Sitemap bzw. der Menüpunkt Crawling Fehler lässt keine weiteren Rückschlüsse auf die Ursachen zu. So habe ich keine Einstellungsmöglichkeiten gefunden das Frontend auf Englisch umzustellen, um nach der Fehlermeldung besser suchen zu können, noch werden die fehlerhaften URLs aufgeführt.

WordPress Update ohne FTP aktualisieren

Sunday, 7. October 2012 / / 0 Comments

Erst dachte ich, es würde an den Rechten des Dateisystems liegen, aber selbst nachdem ich der Gruppe und allen anderen Schreibrechten gegeben hatte, war kein Auto-Update möglich. Internet fand ich den Tipp den upgrade-Ordner in wp-content zu entfernen. Aber auch dies half nichts. Geholfen hat letztlich ein Eintrag in die wp-config.php:

[PHP]
define(‘FS_METHOD’,’direct’);
[/PHP]

Gefunden habe ich es hier: http://www.hongkiat.com/blog/update-wordpress-without-ftp/

Wie im Blog beschrieben habe ich den Code ganz unten eingefügt in der wp-config.php:

[PHP]
/* That’s all, stop editing! Happy blogging. */

if ( !defined(‘ABSPATH’) )
define(‘ABSPATH’, dirname(__FILE__) . ‘/’);
require_once(ABSPATH . ‘wp-settings.php’);

define(‘FS_METHOD’,’direct’);
[/PHP]

Wichtig: Vor jedem Update ein Backup von der Datenbank und den Dateien anfertigen.

Googlebot can’t access your site

Tuesday, 21. August 2012 / / 1 Comment

Derzeit sendet Google immer wieder Mails, dass der Googlebot Fehler bei indizieren von BugBlog.de hat. Für die Fehleranalyse habe ich per wget die komplette Seite heruntergeladen:

wget -m -o log.txt http://www.bugblog.de

Im Logfile findet sich folgender Eintrag:


--2012-08-21 13:44:27-- http://www.bugblog.de/javascript-java-script/java-tutorial-hibernate-mysql-xml/2008/11/23/
Verbindungsaufbau zu www.bugblog.de|78.47.220.180|:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 500 Internal Server Error
2012-08-21 13:44:27 FEHLER 500: Internal Server Error.

Auf der Seite erscheint eine Fehlermeldung:

Parse error: syntax error, unexpected T_STRING in htdocs/wp-content/plugins/exec-php/includes/runtime.php(42) : eval()’d code on line 57

Dies verursacht zwar keinen 500 Error, jedoch ist die Ausgabe nicht gewollt. Um den Fehler zu beheben wird folgender Code ergänzt:

[php]
function eval_php($content)
{
// to be compatible with older PHP4 installations
// don’t use fancy ob_XXX shortcut functions
ob_start();
eval(“?>$contentParse error:’) !== false){
$output = $content;
}
// Ende

ob_end_clean();
return $output;
}
[/php]