Ich habe das Kommentieren in meinem Blog leicht geändert.

Änderungen

1. Es ist möglich Kommentare mit Markdown zu formatieren; HTML ist auch erlaubt, allerdings werden mittlerweile werden nur noch bestimmte HTML-Elemente zugelassen.
Erlaubt sind folgende:

• <a>
• <b>
• <blockquote>
• <br>
• <code>
• <em>
• <h1>
• <h2>
• <h3>
• <h4>
• <h5>
• <hr>
• <i>
• <img>
• <li>
• <ol>
• <p>
• <pre>
• <strong>
• <tt>
• <ul>

Nicht erlaubtes wird ausgefiltert, was ja gut in der Vorschau des Kommentars zu sehen ist.

2. Das Einbetten von Videos mittels <VID http://.....> (VID-Element) ist möglich wie ich schon beschrieb.
Wen der Perl-Code dazu interessiert, sei auf meinen Beitrag Videos einfach in Kommentare einbinden verwiesen.

Anwendung des VID-Elements in Kommentaren dieses Blogs

Im Kommentar nur <VID VideoURL> einfügen. Dann erzeugt das Feedback-Plugin die Einbindung des Videos.

So wird aus <VID http://www.youtube.com/watch?v=ju1IMxGSuNE> das folgende Video mit Larry Wall, der Perl als für Menschen verständlich Programmiersprache ansieht:

Quelle: YouTube

Bislang werden nur die URLs folgender Anbieter erkannt:

• video.google.com
• youtube.com
• myvideo.de
• vimeo.com

Ich bitte um weitere Vorschläge, auch für die URLs auf Videos bei seriösen Videohostern.

Bei Problemen bitte einfach hier was dazu schreiben oder an mich per Mail.

Ich teste gerade hier die Möglichkeit mit einem einfachen Tag Video in Kommentare einzufügen.

Markdown oder Textile beherrscht das leider nicht und diese Ungetüme, die auf den Video-Seiten als HTML-Code angeboten werden sind ziemlich sperrig und fehlerträchtig für unerfahrene Nutzende.

Aber es geht einfach, mit ein bisschen Perl-Code als Hilfe.

Pseudo-HTML

Ich verwende zum Einbetten ein HTML-ähnliches Konstrukt,
bestehend aus <VID Url_des_Videos>.

Perl-Code

#### GwenDragon: Change Video tags <VID http://example.org/...>

# !!!!!!!!! ACHTUNG !!!!!!!!!!!!!
# zweifaches eval im Ersetzen 
# weiter unten ist es risikoreich!
#
my %replaces = (
    'video.google.com/' => {
        name => 'Google-Video',
        from => qr'\/videoplay\?',
        to   => q'/googleplayer.swf?'
    },
    'youtube.com/' => {
        name => 'Youtube',
        from => qr'\/watch\?v=',
        to   => q'/v/'
    },
    'myvideo.de/' => {
        name => 'MyVideo',
        from => qr'\/watch\/(\d+)\/.+',
        to   => q'/embed/$1'
    },
    'vimeo.com/' => {
        name => 'vimeo',
        from => qr'\/\/vimeo\.com\/(\d+)',
        to   => q'//player.vimeo.com/video/$1'
    },
);
my $repl = sub {
    my $url      = shift;
    my $template = shift;
    my $src;

    return if not length $url;
    for my $k ( keys %replaces ) {
        if ( $url =~ m|$k| ) {
            my $from = $replaces{ $k }->{ from };
            my $to   = $replaces{ $k }->{ to };
            $src = $url
              if length $url
                  and $url =~ /$from/;
            $url =~ s|$from|qq{"$to"}|ee;
            $src = $url if not defined $src;
            $template =~ s|###NAME###|$replaces{$k}->{name}|g;
            $template =~ s|###URL###|$url|g;
            $template =~ s|###SRC###|$src|g;
            return $template;
        }
    }           
    return qq{<p style="color:red"><em>Video von '$url' kann nicht eingebettet erden!</em></p>};
};
my $regex = qr|\<VID\s+([^\>]+)?\s*\>|i;        
$comment =~ s|$regex|$repl->("$1",<<HTML)|egi;
<object width="480" height="320" data="###URL###">
<embed src="###URL###">
<br>Der Browser kann das Video nicht darstellen</embed>
</object>
<br>Quelle: <a href="###SRC###">###NAME###</a>
HTML

#### end replace <VID ...>

Anwendung in Kommentaren dieses Blogs

Im Kommentar nur <VID VideoURL> einfügen. Dann erzeugt das Feedback-Plugin die Einbindung des Videos.

So wird aus <VID http://www.youtube.com/watch?v=ju1IMxGSuNE> das folgende Video mit Larry Wall, der Perl als für Menschen verständlich Programmiersprache ansieht:

Quelle: YouTube

Bislang werden nur die URLs folgender Anbieter erkannt:

• video.google.com
• youtube.com
• myvideo.de
• vimeo.com

Ich bitte um weitere Vorschläge, auch für die URLs auf Videos bei seriösen Videohostern.

Wer auf dem Apache-Webserver Webanwendungen (CGI-Programme; meistens Perl, Python oder PHP) laufen lässt und über diverse Apache-Direktiven wie SetEnvIf oder RewriteRule Umgebungsvariablen gesetzt hatte, wird oft erstaunt feststellen, dass diese gesetzten Umgebungsvariablen gar nicht einlesbar sind.

Anwendungsfall für Umgebungsvariablen in CGI

Es könnte über die Apache-Direktive SetEnvIf eine Variable gesetzt werden, wenn bestimmte Umstände vorliegen wie die Beispiele zeigen.

Mein Anwendungsfall wäre der Hinweis für ein CGI auf bestimme Mobilbrowser wie das unvollständige Beispiel erläutern soll.

Apache-Konfiguration

Die Apache-Konfiguration dazu wäre:

### Apache config MOBILEDETECT ###
SetEnvIfNoCase User-Agent "Mozilla/5.0 (Linux; U; Android 2.2.1; fr-ch; A43 Build/FROYO) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1"  is_mobile_browser=1
SetEnvIfNoCase User-Agent "Mozilla/5.0 (Danger hiptop 3.4; U; AvantGo 3.2)" is_mobile_browser=1
SetEnvIfNoCase User-Agent "Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3" is_mobile_browser=1
SetEnvIfNoCase User-Agent "Nokia6230i/2.0 (03.25) Profile/MIDP-2.0 Configuration/CLDC-1.1" is_mobile_browser=1
SetEnvIfNoCase User-Agent "SonyEricssonW800i/R1BC Java/SEMC-Java/2.0 Profile/MIDP-2.0 Configuration/CLDC-1.1" is_mobile_browser=1
SetEnvIfNoCase User-Agent "Blackberry" is_mobile_browser=1
SetEnvIfNoCase User-Agent "Opera Mini" is_mobile_browser=1
SetEnvIfNoCase User-Agent "iPad"
SetEnvIfNoCase User-Agent "DoCoMo/2.0 SH901iC(c100;TB;W24H12)" is_mobile_browser=1
SetEnvIfNoCase User-Agent "J-PHONE/5.0/V801SA/SN123456789012345 SA/0001JP Profile/MIDP-1.0" is_mobile_browser=1
SetEnvIfNoCase User-Agent "Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320)" is_mobile_browser=1
SetEnvIfNoCase User-Agent"OPWV-SDK UP.Browser/7.0.2.3.119 (GUI) MMP/2.0 Push/PO" is_mobile_browser=1
SetEnvIfNoCase User-Agent "Mozilla/5.0 (PDA; NF35WMPRO/1.0; like Gecko) NetFront/3.5" is_mobile_browser=1
SetEnvIfNoCase User-Agent "Mozilla/4.0 (compatible; MSIE 4.01; Windows CE; PPC; 240x320; HP iPAQ h6300)"
SetEnvIfNoCase User-Agent "SonyEricssonG700/R100 Mozilla/4.0 (compatible; MSIE 6.0; Symbian OS; 958) Opera 8.65 [ru]" is_mobile_browser=1

Inzwischen könnten noch weitere Umleitungen und Änderungen in den Request vorkommen. Ein CGI-Programm in Perl sollte dann später auswerten, ob ein Mobilbrowser angefragt hat und darauf reagiere.
Der Apache hat die Möglichkeit bestimmte Aktionen mit der Direktive Action zu definieren und dafür ein CGI aufzurufen. Das CGI wird dabei als Handler verwendet:

Action mymobile /cgi-bin/mobiredir.pl
<Files ~ "\.html?">
   SetHandler mymobile
</Files>

Damit übernimmt das CGI mobiredir.pl sämtliche URI, die an die Dateiendungen .htm oder .html gehen.

Perl-CGI als Action-Handler

Da ja durch die SetEnvIf-Direkten schon früher die Umgebungsvariable is_mobile_browser gesetzt wurde, falls ein Mobilbrowser verwendet wurde, sollte jetzt folgender Perl-Code als eine Art Umleitung auf die Mobil-Webseite möglich sein:

#!/usr/bin/perl -w

use strict;
use CGI qw(:cgi);

my $DEBUG = defined param('DEBUG');

my $url = url(-full=>1, -query=>1, -path_info=>1);

my $host = virtual_host() || remote_host();
my $cgi = script_name();

my $real_url = $url;
$real_url =~ s/$cgi//; 

my $new_host = $host;
$new_host =~ s/(www\.)?/mobil\./; # falls eine www.-Domain vorliegt

my $mobil_url = $url;
$mobil_url =~ s/$host/$new_host/;
$mobil_url =~ s/$cgi//;

if ($DEBUG) {
	print header(-type=>'text/plain');

	print <<TXT;
called CGI:   $cgi
internal URI: $url

Host:         $host
New Host:     $new_host 

URI:          $real_url
Mobil-URI:    $mobil_url
TXT
}
elsif ($ENV{'is_mobile_browser'}) {
	print redirect($mobil_url);
} 
else {
   # gib die Normale Seite aus 
}

1;

Problem

Leider kommt es aber nie zu einer Weiterleitung. Weil nämlich das CGI gar nicht die Umgebungsvariable is_mobile_browser erhält.

Wie kommt das?

Nichtverfügbarkeit der gesetzten Umgebungsvariablen

Grund für die Nichteinlesbarkeit ist oft eine spezielle Betriebsart der CGI auf dem Webserver. Diese werden meistens aus Sicherheitsgründen der Nutzertrennung mit dem Programm suexec gestartet.

suexec hat die spezielle Eigenschaft, dass es nur bestimmte Umgebungsvariablen weiterreicht. Es ist in der Apachedokumentation zu suexec nicht klar zu erkennen, welche das sind und sie benennt nur folgendes im Abschnitt suEXEC Security Model:

Can we successfully clean the process environment to ensure safe operations?

suEXEC cleans the process' environment by establishing a safe execution PATH (defined during configuration), as well as only passing through those variables whose names are listed in the safe environment list (also created during configuration).

suexec lässt demnach nur besondere Variablen zu. Welche das sind, ist wieder woanders, in der Dokumentation Environment Variables in Apache versteckt:

Some Caveats
(...)

• When suexec is used to launch CGI scripts, the environment will be cleaned down to a set of safe variables before CGI scripts are launched. The list of safe variables is defined at compile-time in suexec.c.

• For portability reasons, the names of environment variables may contain only letters, numbers, and the underscore character. In addition, the first character may not be a number. Characters which do not match this restriction will be replaced by an underscore when passed to CGI scripts and SSI pages.

Die Nomenklatur für die Namen wäre ja klar, aber welche sind erlaubt? Erst der genaue Blick in den Quellcode für suexec.c zeigt, welche. Der relevante Abschnitt:

94	static const char *const safe_env_lst[] =
95	{
96	    /* variable name starts with */
97	    "HTTP_",
98	    "SSL_",
99	
100	    /* variable name is */
101	    "AUTH_TYPE=",
102	    "CONTENT_LENGTH=",
103	    "CONTENT_TYPE=",
104	    "DATE_GMT=",
105	    "DATE_LOCAL=",
106	    "DOCUMENT_NAME=",
107	    "DOCUMENT_PATH_INFO=",
108	    "DOCUMENT_ROOT=",
109	    "DOCUMENT_URI=",
110	    "GATEWAY_INTERFACE=",
111	    "HTTPS=",
112	    "LAST_MODIFIED=",
113	    "PATH_INFO=",
114	    "PATH_TRANSLATED=",
115	    "QUERY_STRING=",
116	    "QUERY_STRING_UNESCAPED=",
117	    "REMOTE_ADDR=",
118	    "REMOTE_HOST=",
119	    "REMOTE_IDENT=",
120	    "REMOTE_PORT=",
121	    "REMOTE_USER=",
122	    "REDIRECT_HANDLER=",
123	    "REDIRECT_QUERY_STRING=",
124	    "REDIRECT_REMOTE_USER=",
125	    "REDIRECT_STATUS=",
126	    "REDIRECT_URL=",
127	    "REQUEST_METHOD=",
128	    "REQUEST_URI=",
129	    "SCRIPT_FILENAME=",
130	    "SCRIPT_NAME=",
131	    "SCRIPT_URI=",
132	    "SCRIPT_URL=",
133	    "SERVER_ADMIN=",
134	    "SERVER_NAME=",
135	    "SERVER_ADDR=",
136	    "SERVER_PORT=",
137	    "SERVER_PROTOCOL=",
138	    "SERVER_SIGNATURE=",
139	    "SERVER_SOFTWARE=",
140	    "UNIQUE_ID=",
141	    "USER_NAME=",
142	    "TZ=",
143	    NULL
144	};

Das sieht ganz informativ aus!
Zeile 96–98 besagt also, dass die Variablennamen, die mit HTTP_ oder SSL_ beginnen, weitergereicht werden. Das bedeutet, dass auch so seltsame Variablennamen wie HTTP_blaaah_blubb oder HTTP_isn_browser das CGI erreichen können ohne durch suexec geschluckt zu werden.

Lösung

Anstatt in der früher genannten Apache-Konfiguration MOBILEDETECT die Umgebungsvariable is_mobile_browser zu verwenden, einfach HTTP_ davorsetzen; aus is_mobile_browser wird HTTP_is_mobile_browser.

Eine Beispielzeile aus der korrekten Konfiguration:

SetEnvIfNoCase User-Agent "Opera Mini" HTTP_is_mobile_browser=1

Damit das früher genannte Perl-CGI funktioniert, muss auch anstatt

else if ($ENV{'is_mobile_browser'}) {

die Zeile

else if ($ENV{'HTTP_is_mobile_browser'}) {

verwendet werden.

Weitere Hinweise

SetEnv und URL-Rewrites

Weiterhin erwähnt die Apache-Dokumentation zu Umgebungsvariablen einen Umstand, der bei SetEnv & Co. unbedingt zu berücksichtigen ist, und meines Erachtens eine kleine Falle birgt:

Some Caveats
(...)
The SetEnv directive runs late during request processing meaning that directives such as SetEnvIf and RewriteCond will not see the variables set with it.

Mit SetEnv gesetzte Variablen werden erst spät ins den Request eingefügt, sodass diese in den Direktiven SetEnvIf oder RewriteCond nicht verwendbar sind.

Andere Programmiersprachen

Die oben genannte Problematik gilt im Grunde genommen für alle CGI-Programme, die mit Wrappern wie suexec laufen. Im Zweifelsfall muss das getestet werden.
Es betrifft also auch PHP, Python oder andere Programme die als CGI laufen.

Module mod_perl, mod_php und FastCGI

Ich möchte noch darauf hinweisen, dass die früher genannten Probleme mit den Umgehungsvariablen bei der Verwendung von mod_perl, mod_php, mod_python oder FastCGI nicht entstehen. Auch das ist für das jeweilige Programm zu testen.
Allerdings sind diese Module das nicht auf allen Servern oder Webhosterpaketen möglich, auch aus Datenschutz- und Sicherheitsgründen.

Quellen

• http://httpd.apache.org/docs/2.2/suexec.html
• http://httpd.apache.org/docs/2.2/env.html
• http://svn.apache.org/viewvc/httpd/httpd/branches/2.2.x/support/suexec.c?view=markup
• http://httpd.apache.org/docs/2.2/mod/mod_setenvif.html#setenvif
• http://www.perl-community.de/bat/poard/thread/16657

Fazit

Mir ist schon klar, dass die oben genannte Umleitung auch ohne CGI druch das Modul mod_rewrite möglich ist; es sollte im Artikel nur klar gemacht werden, dass das Zusammenspiel von CGI und Umgebungsvariablen problematisch sein kann.

Wer weitere Tipps und Hinweise hat, kann die gerne hier im Kommentarbereich posten.

Blosxom ist ein in Perl programmiertes Blogsystem, das durch Plugins in der Funktionalität erweitert werden kann und mit normalen Textdateien als Artikelspeicher arbeitet.

Aktueller Stand

Leider ist Blosxom seit Version 2.1.2 aus 2008 nicht mehr weiter entwickelt worden. Fixes in Blosxom wurden zuletzt im Oktober 2010 eingespielt.

Auch die Plugins dümpeln vor sich hin, manche sind auf diversen Webseiten im Internet verstreut, die teilweise auch nicht mehr existieren. Die offiziellen Plugins wurden zuletzt 2007 geändert. Wer Blosxom weiter verwenden will, ist gezwungen selbst die vorhandenen Plugins zu fixen, zu erweitern oder eigene zu entwickeln.

Weitere Entwicklung

Die von Rael Dornfast angedachte Version 3.0 ist nie über ein PoC herausgekommen und eingestellt worden.

Selbst ein Rewrite von Blosxom als Bryar oder Blog::Blosxom mangelt an der Einbindung von Plugins.

Warum weiter modernisieren?

Warum aber muss Blosxom erweitert oder modernisiert werden?

Weil die Programmierung des CGI und der Plugins auf einer Idee basiert, die mittlerweile nicht mehr als Modern Perl angesehen werden kann.

Weil Blosxom nur als Standard-CGI läuft und bei umfänglichen Blogs und vielen Plugins langsam wird, insbesondere die Antwortzeiten (bis der Server etwas ausgibt) können bis auf ca. 1,5 bis 2 Sekunden ansteigen.

Weil eine Verwendung von mod_perl, fastcgi oder pscgi unmöglich ist, da Blosxom und seine Plugins auf ein veraltetes Konzept aufsetzen, in dem globale Variablen verwendet werden und auch keine API vorhanden ist.

Weil es unmöglich ist, eine kompilierende Template-Engine wie HTML::Template::Compiled zu verwenden.

Weil keine Internationalisierung von Fehlermeldungen und anderen Ausgaben möglich ist.

Weil eine moderne Verwaltungsoberfläche und ein komfortabler Editor für Blog-Einträge und Kommentare fehlt.

Weil es andere Blog-Systeme besser können, selbst Perl basierte wie MT sind da strukturierter.

Weil …

Wer Blosxom verwendet, weiß was ich meine. ;)

Ich will die Arbeit von Rael Dornfast, Axel Beckert (XTaran), Gavin Carr, Barijaona Ramaholimihaso, Bill Ward und anderen Entwicklern nicht klein reden. Sie haben viel geleistet und ich habe ja auch davon profitiert, sonst wäre nicht dieses Blog entstanden.
Deswegen: Thanks guys. Good work for Blosxom!

Aufruf!

Deswegen würde ich gern Ideen mit anderen Perl-Programmierer_innen zusammentragen und ein Blosxom4-Projekt aufmachen.

Ideen für einen Namen des modernisierten Blosxom?

Nur findet sich eine_r, die mitmachen wollen?

Wäre schade, wenn Blosxom verwelkt und stirbt, die Blogwelt von PHP-basierten Ungetümen dominiert wird.

Leute, wenn ihr Perl programmieren könnt, Ideen, Lust an der Mitarbeit in einem neuen OpenSource-Projekt habt, meldet euch!

Per Mail, im Kommentar, in Twitter.

Auch auf perl-community.de unter Programmierende für 'Modern Blosxom' gesucht kann zum Projekt nachgefragt werden.

Wenn in Webanwendungen oder -seiten Navigationen erstellt werden, kommt es oft zu einem bestimmten Effekt: der Link auf die gerade angezeigte Seite wird auch angezeigt. Es ist nicht erkennbar, dass der Link auf die gerade angezeigte Seite verweist. Solche selbstbezüglichen Links sind dann natürlich unnötig und unsinnig.

Sowas passiert oft, teilweise erzeugt durch Programme zum Erstellen von Webseiten als auch durch diverse Content-Managment-Systeme. …weiter lesen

Der Internet Explorer benimmt sich ziemlich seltsam, was Downloads per HTTP-Header Content-Disposition anbelangt.

So weigert er sich oft von einem Link herunter zu laden und zeigt stattdessen die nachfolgende Fehlermeldung.

Fehlermeldung des Internet Explorer bei Downloadversuch

Der Server ist aber erreichbar gewesen zum Zeitpunkt des Requests.

Ein Blick in den Debugproxy Fiddler2 zeigt, dass der IE den Download (Header und Body) bekommt.

GET http://www.gwendragon.de/***?****** HTTP/1.1
Accept: application/x-ms-application, image/jpeg, application/xaml+xml, image/gif, image/pjpeg, application/x-ms-xbap, application/x-shockwave-flash, */*
Accept-Language: de-DE
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET4.0C)
Accept-Encoding: gzip, deflate
Connection: Keep-Alive
Host: www.gwendragon.de

HTTP/1.1 200 OK
Date: Wed, 12 Jan 2011 13:48:24 GMT
Server: Apache
Expires: Wed, 12 Jan 2011 13:48:24 GMT
Accept-ranges: none
X-download-options: noopen
Content-disposition: attachment; filename=repo.ico
Cache-control: no-cache
Vary: Accept-Encoding,User-Agent
Content-Length: 2310
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: image/vnd.microsoft.icon; charset=ISO-8859-1

binary data follows...

Alle anderen Konkurrenzbrowser wie Firefox, Opera, Safari, Chrome laufen.

Weiß jemand Abhilfe?

[Update]: Der IE spinnt seltsamerweise nur beim ersten Mal des Abrufs, wenn er neu gestartet wurde. Da das bei anderen Testern nicht auftritt, der Download korrekt lief, ist das wohl ein Problem meines Entwicklungsrechners.

Gernot Havranek, Perl-Programmierer, Inhaber von Havranek IT-Service & Perl und Redakteur einer österreichischen Zeitschrift für die Programmiersprache Perl hat vor einiger Zeit ein Interview mit mir geführt, welches jetzt für die Novemberausgabe 2010 Perl-Zeitung abgedruckt wurde.

Mit freundlicher Genehmigung von Gernot darf ich das auch hier im Blog veröffentlichen.…weiter lesen

Angeblich gibt es unter Linux für manche Shellentusiasten nichst besseres als die Paar Werkzeuge grep, sort, tail, find, xargs & Co. Nun ja, wer schon mal aufwändiger nach Dateiinhalten suchen musste, verfluchte öfters mal den Rattenschwanz von Pipes und Backticks. …weiter lesen