PHPGangsta - Der praktische PHP Blog

PHP Blog von PHPGangsta


Search Results

Gearman Worker verbinden sich nach Upgrade nicht mehr

with 5 comments

Heute ein kurzer Tipp bezüglich PECL/gearman: Wenn ihr bei der Nutzung einer aktuellen Version den folgenden Fehler bekommt

send_packet(GEARMAN_COULD_NOT_CONNECT) Failed to send server-options packet
-> libgearman/connection.cc:430

dann liegt es daran dass ihr keinen Port beim Aufruf der Methode GearmanClient::addServer() angegeben habt. Bisher war der zweite Parameter optional und als Default wurde 4730 genommen, aber seit einigen Versionen (welcher genau kann ich nicht sagen) scheint er angegeben werden zu müssen. Wir benutzen aktuell PECL/gearman Version 1.1.1 kompiliert mit libgearman 1.1.5

Falls ihr also Gearman nutzt und den zweiten Parameter noch nicht gesetzt habt, fügt ihn am besten jetzt schon hinzu, damit ihr bei einem Upgrade in der Zukunft keine Probleme bekommt.

Hier habe ich die Lösung gefunden (wäre ich selbst wahrscheinlich nie drauf gekommen):
http://stackoverflow.com/questions/14883681/gearman-gives-me-gearman-could-not-connect-it-is-definitely-running
https://answers.launchpad.net/gearmand/+question/221277

Written by Michael Kliewe

April 8th, 2013 at 3:22 pm

Javascript Web Worker

without comments

Ergänzend zu einem älteren Artikel über Google Gears hier eine kurze Statusmeldung: Mittlerweile sind die modernen Browser (zur Zeit Firefox 3.5, Safari 4 und Google Chrome) in der Lage, die Funktionalität der Worker auch ohne das Gears-Plugin anzubieten, sodass man auf eine große Anzahl an Nutzern zurückgreifen kann. Wir werden also in Zukunft vermehrt tolle Seiten mit vielen Effekten und Funktionalitäten sehen, und vielleicht ja auch selbst entwickeln.

Weitere Infos bietet die Suchmaschine eurer Wahl. Einfach nach “Javascript Web Worker” suchen, es gibt bereits einige Beispiele und auch den Draft, der diese Technik hoffentlich bald zum Standard macht.

Written by Michael Kliewe

Oktober 28th, 2009 at 9:24 pm

Posted in PHP

Tagged with , ,

SSLv3: Uralt, bröckelig, abschalten!

with 5 comments

[EDIT] Tja, da schreibt man gerade drüber und ein paar Minuten später wird die Lücke veröffentlicht: Poodle . Details im Google Blog. Das Problem liegt im SSLv3 Protokoll selbst, es wird keine Patches geben, es muss ausgeschaltet werden. Eigentlich wäre nur uralt-Software wie der IE6 unter WindowsXP betroffen, aber durch Downgrade-Attacken die bei TLS möglich sind, sind alle betroffen und können auf das schwache SSLv3 downgegraded werden wenn es denn auf Server+Client unterstützt wird. Also abschalten!

Seit 2 Tagen gibt es Gerüchte über eine kritische Lücke in SSLv3. Aktuell (Mitternacht) ist noch nichts publik geworden außer ein eventuell interessanter Patch von Microsoft, und eine Falschmeldung eines OpenBSD-Patches, der in Wirklichkeit schon einige Monate alt ist.

Sicher ist dass SSLv3 18 Jahr alt ist, und vor 15 Jahren durch TLSv1.0 abgelöst wurde. Bei mail.de haben wir SSLv3 bereits vor einigen Monaten deaktiviert auf den Webseiten da kaum ein Client dieses alte Protokoll benutzte außer der IE6 auf WindowsXP Systemen. Da wir den IE6 eh schon lange nicht mehr unterstützen war es sehr einfach, SSLv3 abzuschalten.

Für die anderen Protokolle wie IMAP, POP3 und SMTP haben wir SSLv3 allerdings noch aktiviert gelassen da es noch diverse E-Mail-Clients gibt die TLS >1.0 noch nicht beherrschen. Auch einige ältere Smartphones beherrschen noch kein TLS1.0 oder neuer, sodass es Sinn machte es noch aktiviert zu lassen, denn es gab auch (noch) keine bekannten Angriffsvektoren.

Read the rest of this entry »

Written by Michael Kliewe

Oktober 15th, 2014 at 12:18 am

Wer nutzt die ungewöhnlichen PHP-Tags?

with 19 comments

Vorgestern begann eine interessante Diskussion inklusive eines RFC in der PHP-Internals-Mailingliste, in der es um die Abschaffung zweier alter und selten genutzter Möglichkeiten geht, PHP-Code als solchen zu markieren. Normalerweise beginnt PHP-Code mit <?php oder <?

Es gibt aber weitere Möglichkeiten für diesen Einsatzzweck:

<script language="php">
    echo 'Hallo';
</script>

<% echo 'Hallo'; %>

php_tagsNun ist die Frage: Soll bzw. kann man diese alternativen Tags aus der PHP-Engine entfernen? Ein Gegenargument wäre dass durch die Entfernung plötzlich der PHP-Quelltext an den Browser ausgegeben würde, ein Besucher der Webseite würde also den möglicherweise geheimen Sourcecode mit Passwörtern usw. zu Gesicht bekommen. Ist das eine reelle Gefahr die die Abschaffung für immer oder mindestens lange Zeit verhindert? Oder betrifft das nur ein paar hundert weltweit genutzte kleine Webseiten, auf die man keine Rücksicht nehmen kann?

Welche Vorteile hätte eine Entfernung, bringt es neben dem verringerten PHP-Engine-Code auch kleine Performancevorteile oder ähnliches?

In welcher Version sollte man diese Tags als DEPRECATED markieren, um so die Admins auf die nahende Entfernung hinzuweisen? Wie viele Admins oder Programmierer bekommen die DEPRECATED-Meldungen im Error-Log überhaupt mit?

Wer von euch nutzt diese ungewöhnlichen Methoden in seinem Code oder hat ihn bereits in Fremdcode oder Bibliotheken gesehen? Ich muss zugeben dass ich von den beiden Möglichkeiten in den letzten 10 Jahren nichts gehört habe und nicht wußte dass sie existieren, und sie demnach auch noch nie irgendwo gesehen habe…

Written by Michael Kliewe

September 12th, 2014 at 11:37 am

Posted in PHP

Tagged with , ,

HTML-Validierung: Reine Zeitverschwendung, oder?

with 5 comments

Gastartikel von David Becker, er arbeitet als Autor bei netzsieger.de

w3c_imageDiese Frage wird ein Teil der Webgemeinde vehement bejahen, die anderen werden ebenso überzeugt widersprechen. Ob eine klare Antwort in dieser Thematik überhaupt möglich ist, sei vorerst offengelassen. Jeder, der sich etwas genauer mit der Frage auseinandergesetzt hat, kommt zu einem anderen Schluss, hauptsächlich abhängig von den eigenen Erfahrungen und Konsequenzen. Bei näherer Recherche ergibt sich schnell, dass selbst Branchengrößen wie Amazon oder Facebook invaliden Code verwenden. Ja, selbst Google nimmt diese in Kauf. Aber nur weil andere es machen, muss es nicht zwangsläufig für jeden der richtige Weg sein.

Welche Vorteile ergeben sich durch validen Code?

Mit einem Vorurteil kann direkt aufgeräumt werden. Google bestraft Websites mit invalidem Code nicht. Die Top-Suchergebnisse beliebiger Sucheingaben sind fast immer Websites, die ungültiges HTML beinhalten. Den Code des eigenen Webauftritts komplett fehlerlos zu halten, ist also kein Freifahrtschein, von Google dafür auch belohnt zu werden. Es gibt aber durchaus andere Argumente, die für möglichst ausschließliche Nutzung validen Codes sprechen.

Gerade veraltetes, fehlerhaftes HTML mag aktuell korrekt angezeigt werden. Bei zukünftigen Browsern könnte das aber schon nicht mehr der Fall sein. Was gerade noch problemlos erscheint, könnte dann plötzlich doch Probleme bereiten. Außerdem darf auch nicht die gegenseitige Verstärkung mehrerer Fehler unterschätzt werden. Zwei, drei Fehler auf einer Seite bleiben vielleicht ohne Konsequenzen, bei noch mehr invalidem Code wird die Seite dann aber vielleicht doch nicht mehr korrekt angezeigt.

Read the rest of this entry »

Written by Michael Kliewe

Juli 30th, 2014 at 4:03 pm