everflux

Ubuntu Lucid beinhaltet eine neuere Version des Apache  Modules mod_fcgid als FastCGI Anbindung. Wer nun per FastCGI z.B. PHP laufen hat, und sich ueber defekte Dateiuploads wundert, dem sei dieser kurze Blogartikel ans Herz gelegt! (Wer kein FastCGI bzw. nicht mod_fcgid und Apache unter Lucid verwendet, bzw. kein Problem hat, dass z.B. Bilder nach dem Upload defekt sind, kann den Artikel getrost ignorieren.)

Weiterlesen »

Ein Ubuntu Hardy Heron Update auf Ubuntu Intrepid Ibex kann einen schwer ins Schwitzen bringen – zumindest wenn danach der Apache nicht mehr funktioniert.

Einzig die Warnung von Apache beim Starten „Warning: SuexecUserGroup directive requires SUEXEC wrapper.“ war ein Hinweis auf das Problem. Weiterlesen »

Suchmaschinen – vor allem Google – können sehr hartnäckig sein. Gerade was alte Seiten oder Forumsbeiträge angeht, möchte man diese vielleicht aus Suchmaschinen ausnehmen.

Für Ressourcen, die nicht mehr verfügbar sind, gibt es ab HTTP 1.1 den Status Code 410 (Gone). Mit diesem Wissen gewappnet läßt sich eine Suchmaschine gut steuern.

Im Beispiel handelt es sich um ein Forum, in dem unerwünschte Beiträge nicht gelöscht werden sollen, sondern in einen Bereich verschoben werden, der öffentlich nicht verfügbar ist. (Das Forum ist PHPBB3 – hier kann leider nicht zwischen „eigentlich gelöscht“ und in einem Beitrag nur für bestimmte Benutzer unterschieden werden.)

Kennt man die alte URL des Beitrags, so ist dieser zwar nicht mehr verfügbar, aber es erscheint eine „bitte melden Sie sich an“ Seite. Nicht gerade das, was man sich wünscht um diesen Beitrag schnell aus dem Google Index verschwinden zu lassen.

Also kommt nun die Apache htaccess hinzu – leider geben sich Suchmaschinen gerne als HTTP 1.0 Browser aus, „echte“ HTTP 1.0 Browser verstehen den HTTP Statuscode 410 jedoch nicht. Also kommt noch ein htaccess Trick hinzu: Ein HTTP 1.1 Browser nur kennt den „Host“ Header, damit läßt sich eine hinreichende Differenzierung erreichen.

Zu guter letzt möchte man noch den Administratoren ermöglich in dem Bereich Beiträge zu sehen – hier gehe ich einfach mal davon aus, dass sich keine vernünftige Suchmaschine als „Firefox“ User ausgeben würde, und die Administratoren seinerseits Firefox verwenden.

Zusammengebaut sieht das dann so aus:

#exclude archive pages from search engines, if http 1.1 capable (using host header check)
RewriteCond %{HTTP_HOST} .
#not for humans
RewriteCond %{HTTP_USER_AGENT} !Firefox [NC]
#else: gone
RewriteRule ^archiv/ - [G,L]


Gott, ich hasse schlecht dokumentierte Software! Ein echter Krampf sind die FastCGI und fcgid Module. fcgid sollte als (binärkompatibler) Nachfolger in die Fußstapfen des kaum gepflegten FastCGI Moduls treten. Das hat es sicherlich in mehrfacher Hinsicht geschafft: Die fcgid Webseite ist zum fürchten und sieht alles andere als professionell aus. Die Dokumentation ist eher dürftig und sinnvolle Beispiele für aktuelle Anwendungsfälle fehlen. (Rails, PHP, …)

Weiterlesen »

PhpBB3 ist nun schon eine Weile veröffentlicht – und so stellt man das eine oder andere Forum um. Probeläufe werden gemacht, ob eine phpBB2 nach phpBB3 Migration klappt, alle Userdaten und Avatare mitkommen.

Nachdem dann auch das Avatar-Salt richtig gesetzt ist, sieht erstmal alles gut aus. Bis die ersten User des phpBB3 Forum klagen, dass „die Seite langsam“ ist. Auch mir selber kamen längere Ladezeiten unter.

Manchmal dauerte es 15 Sekunden bis ein Avatar Bild geladen war – der Rest des phpBB Forums war schnell wie erwartet.

Des Rätsels Lösung fand sich dann dank Stefan:

Nur bei HTTP 1.1 Requests und aktiviertem Keepalive bzw. HTTP Pipelining und nur bei Bildern trat das Problem auf. Schnell war identifiziert, dass die 15 Sekunden genau der maximalen Keepalive Zeit des Apache entsprachen.

Was war nun passiert: Im Apache ist mod_gzip (bzw. DEFLATE) aktiviert. Die Avatare werden von einem PHP Script ausgeliefert und nicht mehr direkt verlinkt. Dabei wird von dem Script auch der Content-Length Header gesetzt – auf die Größe der Bilddatei.

Dann braust das mod_gzip einmal über das Bild und macht es kleiner – und sei es nur ein kleines Byte. Der Content-Length Header wird nicht angepaßt, und der Browser glaubt er müsse noch auf fehlende Bytes warten. Das tut er dann, bis der Timeout erreicht ist.

Lösung dafür war dann diese Zeile in der Apache Config, zumindest als vorläufiger Workaround:

SetEnvIfNoCase Request_URI download/file\\.php$ no-gzip dont-vary

PHP, Apache2 und FastCGI bringt neben ein paar Annehmlichkeiten einen Haufen Probleme mit. So funktioniert z.B. die gewohnte WWW-Authenticate „Basic Authentication“ nicht mehr wie gewohnt.
Das wird durch verschiedene Faktoren bestimmt:
Das mod_fastcgi muss so konfiguriert werden, dass die entsprechenden Header weitergereicht werden. Bei Apache 1 ist es HTTP_AUTHORIZATION – Apache2 verwendet den standardkonformen „Authorization“ HTTP Header.
Dafür sieht dann die FastCGI Konfiguration etwa so aus:

FastCgiConfig -pass-header Authorization -pass-header HTTP_AUTHORIZATION

PHP – zumindest in der aktuellen Version – wertet diesen Header offenbar nicht aus.
Dazu bedarf es dann eines kleines PHP Snippets als Workaround. Oder Zend behebt das Problem mal.

if (isset($_SERVER['Authorization']) && !empty($_SERVER['Authorization']))
{
    list ($type, $cred) = split (" ", $_SERVER['Authorization']);

    if ($type == 'Basic')
   {
        list ($user, $pass) = explode (":", base64_decode($cred));
        $_SERVER['PHP_AUTH_USER'] = $user;
        $_SERVER['PHP_AUTH_PW'] = $pass;
    }

}

Der Rest funktioniert dann wie gewohnt.