http-Aufruf geht, https braucht bis zu 2 Minuten

Bernd aus No

Hi,

ich betreibe zwei Blogs auf einer Datenbank (die Prefixe unterscheiden sich).
Der eine Blog läuft unter einer sehr alten WordPress-Version (2.0.x), der zweite Blog ist in der Version 3.0.1.

Aus dem Intranet kann ich beide Blogs per http bedienen und dies mit normalen Reaktionsgeschwindigkeiten. Normalerweise benutze ich die Blogs aus dem Internet heraus und verwende https. Die alte WordPress-Version reagiert normal schnell, die neue ist ätzend langsam, bis zu zwei Minuten vergehen, bis man von einem Beitrag zum anderen kommt.

Der https-Request kommt von Außen an meiner Firewall an und wird per Portforwarding auf eine Maschine in der DMZ weiter geleitet. Dort läuft eine aktuelle Apache2-Installation, die die Anfragen abhängig vom Pfad hinter der Domainangabe auf weitere virtuelle Maschinen in der DMZ verteilt (mit der Direktive ProxyPass - der weitergeleitete Request erfolgt mit http).

Diese Technik setze ich seit Jahren ein, sie funktioniert mit alten WordPress-Versionen sowie mit MediaWiki, SVN und WebDav einwandfrei.

Meine Vermutung:

WordPress in der Version 3.0.x versucht erst eine Antwort mit https (der Ursprungsrequest ist ja https)
Nach Ablauf eines Timers wird dann auf die Antwort mit http gegeben.

Messungen auf den beteiligten Maschinen zeigen während der Wartezeiten keinen IP-Trafik und keine Aktivitäten der beteiligten Apache-Server.

Gibt es einen Weg, das Verhalten der neuen WordPress-Versionen zu beeinflussen?

Gruß
Bernd

Werbepost

Hallo!

Wenn du gerade an deiner Website arbeitest oder dein aktuelles Hosting überdenkst: Wir betreiben mit NetzLiving eine Hosting-Plattform, die speziell auf Performance, Sicherheit und einfache Verwaltung ausgelegt ist.

✔️ Schnelle Ladezeiten (optimiert für WordPress & Co.)
✔️ Deutsche Server & DSGVO-konform
✔️ Persönlicher Support (kein 0815-Ticket-System)

Mehr erfahren

r23

Hallo Bernd,

Zitat von Bernd aus No

Meine Vermutung:
WordPress in der Version 3.0.x versucht erst eine Antwort mit https (der Ursprungsrequest ist ja https)
Nach Ablauf eines Timers wird dann auf die Antwort mit http gegeben

Ich vermute, dass du auf deinem Server Probleme mit der Funktion is_ssl
hast.

~/wp-includes/functions.php Zeile ab 3406

PHP

function is_ssl() {
    if ( isset($_SERVER['HTTPS']) ) {
        if ( 'on' == strtolower($_SERVER['HTTPS']) )
            return true;
        if ( '1' == $_SERVER['HTTPS'] )
            return true;
    } elseif ( isset($_SERVER['SERVER_PORT']) && ( '443' == $_SERVER['SERVER_PORT'] ) ) {
        return true;
    }
    return false;
}

Alles anzeigen

Frage einfach unter einer gültigen SSL Verbindung den Inhalt von $_SERVER ab...

PHP

var_dump($_SERVER);

und passe die Funktion an deine Umgebung an.

Es kann selbstverständlich auch an einem anderen Punkt liegen. Die Suche nach "https" wurde in meiner Wp Installation alleine 198 mal in 56 Dateien gefunden.

hth

ralf

Bernd aus No

Hallo Ralf,

die Inspektion der Variablen _SERVER hat keinen Hinweis auf auf https oder den Port 443 ergeben. Der Request kommt über Port 80, so wie erwartet.

Ich habe auch mal die Function is_ssl manipuliert (sie lieferte immer false) - hat nichts gebracht.

Gruß
Bernd

r23

Hallo,

die super Provider in Deutschland verwenden allerdings schon den Port 443 für ihr SSL-gebastel - sie stellen dir nur keine richtigen Informationen in $_SERVER zur Verfügung.

Bei einigen "Providern" musst du eine Varbaile suchen *die nur unter* einer SSL Verbindung zur Verfügung steht.

Z.b.
$_SERVER['HTTP_X_FORWARDED_HOST']

Lege dir ein PHP Script mein_script.php in das WP-doc Root mit dem Inhalt

PHP

echo '<pre>';
    print_r($_SERVER);
    echo '</pre>';

rufe das Script mit SSL Verschlüsselung auf

a) https://ssl_proxy_weiterleitung.example.org/mein_script.php
und ohne
b) http://www.example.org/mein_script.php

Suche hier einen eindeutigen Unterschied zwischen a und b.

Zitat von Bernd aus No

Der Request kommt über Port 80, so wie erwartet.

SSL- Verschlüsselung läuft normalerweise nicht über Port 80.

Evtl. ist die SSL-Konfiguration auf deinem Server nicht richtig? oder das Zertifikat ist abgelaufen oder das Zertifikat ist inzwischen aus anderen Gründen ungültig?

Dein Server sollte unter einer https-Anfrage ein einfaches HTML Domument ohne Probleme ausliefern können. Sollte dies bereits scheitern (?) liegt der Fehler nicht an WP sondern an der Server Konfiguration oder schlimmer an deinem Cleint

Zitat von Bernd aus No

Ich habe auch mal die Function is_ssl manipuliert (sie lieferte immer false) -

dies wurde bei einem sehr flüchtigen Blick von mir vermutet.

hth

ralf

Bernd aus No

Hi Ralf,

ich arbeite auf meinem eigenen Rechner (bzw. Intranet), nicht über einen Provider. Der Zugang zu meinem Rechner erfolgt über eine DynDNS-Adresse.

Da mein Intranet von Außen nur für wenige Personen geöffnet ist, baue ich gerade an einer offen erreichbaren, virtuellen Maschine, in der ich das nachbilde, was in der geschützten Umgebung nicht funktioniert.

Vielleicht finde ich dabei Unterschiede und kann das Problem lösen. Oder ein freundlicher Zeitgenosse testet von Außen und kann mir helfen.

Gruß
Bernd

r23

Hallo,

Zitat von Bernd aus No

ich arbeite auf meinem eigenen Rechner (bzw. Intranet), nicht über einen Provider. Der Zugang zu meinem Rechner erfolgt über eine DynDNS-Adresse.

Mit

https://localhost/mein_script.php
und
http://localhost/mein_script.php

kannst du relativ einfach deine Server Umgebung abfragen. Solltest du auch unter http://localhost/mein_script.php keine sinnvolle Antwortwortzeit erhalten, kennst du ja den Schuldigen ;)

Zitat von Bernd aus No

Da mein Intranet von Außen nur für wenige Personen geöffnet ist, baue ich gerade an einer offen erreichbaren, virtuellen Maschine, in der ich das nachbilde, was in der geschützten Umgebung nicht funktioniert.

von aussen kann man doch nur sehen, dass es nicht funktioniert? Warum etwas fehlerhaftes zeigen?

ich verwende in httpd.conf

Code

# Secure (SSL/TLS) connections
Include "conf/extra/httpd-ssl.conf"
#
# Note: The following must must be present to support
#       starting without SSL on platforms with no /dev/random equivalent
#       but a statically compiled-in mod_ssl.
#
<IfModule ssl_module>
    SSLRandomSeed startup builtin
    SSLRandomSeed connect builtin
    SSLSessionCache "shmcb:logs/ssl.scache(512000)"
    SSLSessionCacheTimeout 300
</IfModule>

Alles anzeigen

und da du den Port 80 erwartet hast (?) hier mein Auszug aus
conf/extra/httpd-ssl.conf

Code

# This is the Apache server configuration file providing SSL support.
# It contains the configuration directives to instruct the server how to
# serve pages over an https connection. For detailing information about these 
# directives see <URL:http://httpd.apache.org/docs/2.2/mod/mod_ssl.html>


.
.
.


<IfModule ssl_module>




#       Listen directives: "Listen [::]:443" and "Listen 0.0.0.0:443"
#
#Listen 0.0.0.0:443
#Listen [::]:443
Listen 443


<IfModule mime_module>
    AddType application/x-x509-ca-cert .crt
    AddType application/x-pkcs7-crl    .crl
</IfModule>




<VirtualHost _default_:443>
    #   General setup for the virtual host
    DocumentRoot "/usr/www/.../htdocs"
    ServerName localhost:443
    ServerAdmin webmaster@localhost
    ErrorLog "logs/error.log"
    <IfModule log_config_module>
        CustomLog "logs/access.log" combined
    </IfModule>
#
# usw.
#

Alles anzeigen

aber dies wolltest du ja nicht wissen. PHP Scripte erwarten bei einer SSL- Verbindung

$_SERVER['HTTPS'] = on
meinetwegen geht noch
$_SERVER['HTTPS'] = 1

Wenn deine Umgebung dies PHP nicht zur Verfügung stellt, ist deine Server Konfiguration leider schrottig.

hth

ralf

Putzlowitsch

Vielleicht klemmt es auch irgendwie beim "Redirect Canonical", was es bei WP 2.0.x noch nicht gab. Versuchsweise könnte man das ja mal abschalten:

PHP

remove_filter('template_redirect', 'redirect_canonical');

Das z.B. in die functions.php des Themes einfügen und gucken was passiert.

Gruß
Ingo

Bernd aus No

Hi *,

ich habe die letzten zwei Tage einige Testfälle generiert und muss feststellen: meine Überschrift zum Thread ist falsch!

Das Problem ist nicht http oder https sondern sind Unterschiede in den Versionen 2.0 und 3.0 von WordPress.

Um meine Testfälle verstehen zu können, ist die Kenntnis meines Intranets wichtig.
Internet
|
v
Router
|
------------------ privates Netz 172.128.100.x (DMZ)
| : : : |
v v
'Maschine A' 'Maschine wpt'

Alle Anfragen über http (Port 80) und https (Port 443) werden vom Router an die Maschine 'A' weitergeleitet.
In der Maschine 'A' läuft ein apache2-Server, der Anhand der Pfadangabe entscheidet, welche Maschine für die Bearbeitung zuständig ist.
Wenn eine andere Maschine beauftragt wird, erfolgt die Weiterleitung per Apache-Directive ProxyPass.
Die Weiterleitung benutzt immer http, auch wenn der Request per https kam.

Für meine Testfälle habe ich eine virtuelle Maschine 'wpt' erstellt.
Sie bassiert auf debian, benutzt apache2, php5 und mysql5.0.32.
Vier WordPress-Installationen habe ich erstellt, je zwei mit der Version 2.0 und 3.0.
Sie benutzen alle die selbe mySQL-Datenbank, jede Installation hat ihren eigenen Tabellensatz (unterschiedliche Prefixe).

In der Maschine 'A' ist neben apache2 ebenfalls php5 und mysql5.0.32 installiert.
Hier sind zwei WordPress-Installationen erstellt, je eine mit der Version 2.0 und 3.0.

Damit ergeben sich die folgende 6 Testfälle:
lfdNr URL Protokoll WP-Version Ausführung in Maschine
1 http://v-h.homeip.net/wordpress-20/ http 2.0.10 A
2 http://v-h.homeip.net/wordpress-30/ http 3.0.1 A
3 http 2.0.10 wpt
4 http 3.0.1 wpt
5 https 2.0.10 wpt
6 https 3.0.1 wpt

Die genannten URLs können zum Testen verwendet werden ('/' am Ende ist wichtig!).
Zum Test der normalen Geschwindigkeit (ohne Nutzung von WordPress) kann 'mein_script.php' an die URL angehängt werden.
[ Nach Abschluss dieses Threads werde ich die Zugänge wieder verschließen. ]

Die von mir beobachteten Geschwindigkeitsunterschiede durch die interne Weiterleitung sind maginal.
Krass sind die Unterschiede zwischen Version 2.0 und 3.0. Dabei spielt die interne Weiterleitung offensichtlich keine Rolle.

Der Fehler muss an einer ganz anderen Stelle liegen. In der php.ini habe ich das Memory-Limit von 16 auf 48 MByte erhöht, brachte aber nichts.

Diese Diskussion sollte ggfs an einer anderen Stelle des Forums weitergeführt werden. Der Admin möge den Thread bitte verschieben.

Gruß
Bernd

PS: Der Tipp von Ingo hat leider nichts gebracht.

Putzlowitsch

Wenn man WP 3.0 aufruft (Link Nr. 2), und dann den Request gleich wieder abbricht, kann man danach die Seite für etwa 60 Sekunden ganz normal Aufrufen. Das ist dann praktisch genauso schnell wie WP 2.0 (Link 1).

Der Grund dürfte sein, daß Wordpress regelmäßig nach Hause "telefoniert", um z.B. nachzuschauen, ob es Updates gibt oder Ähnliches. Wenn der Request fehlschlägt, wird frühestens nach 60 Sekunden ein neuer Versuch gestartet.

Ursache sind möglicherweise nicht korrekt konfigurierte HTTP-Request-Methoden oder eine Firewall, die überhaupt keine HTTP-Requests vom Server nach draußen läßt.

Für die Request-Methoden könnte man mit dem Plugin "123 HTTP Transport" probieren, ob das Abschalten bestimmter Transport-Methoden das Problem beseitigt.

Ansonsten muß man rausfinden, warum WP sich nicht nach Hause verbinden kann.

Gruß
Ingo

Bernd aus No

Hi Ingo,

dein Tipp geht sicher in die richtige Richtung.
Mit tcpdump, netstat und lsof sowie der paralellen Überwachung des Logs von Apache konnte ich sehen,
dass jeder Request von Aussen sofort ankommt.

Nach einem Abbruch des ersten Request und sofortiger Wiederholung funktioniert alles, wie erwartet.
Nach einer Minute (plus knapp eine Sekunde) behebt sich fehlerhafte Zustand von selbst.
Bricht man keinen Request ab, dauert jeder eine Minute.
Bricht man einen ab, kann man anschließend normal arbeiten.
Es darf jedoch keine längere Pause entstehen.
Ist die Pause länger als 25 .. 30 Sekunden, kommt das Programm wieder in den fehlerhaften Zustand.

Während des fehlerhaften Zustands gibt keine Kontaktversuche nach Außen.
Auch meine Firewall liefert keine Hinweise auf abgewiesene Pakete.
Die Maschinen der DMZ dürfen über die Ports 80, 53 und 123 mit der Außenwelt Kontakt aufnehmen,
dies ist bisher immer ausreichend gewesen.

Nun bleibt die Frage, auf was wartet der PHP-Code.
Der Abbruch eines Requests und seine Wiederholung scheint den Programmablauf für kurze Zeit in den richtigen Zustand zu bringen.
Oder man muss dem Programm geben, worauf es wartet - nur was könnte es sein?
Meine Forschungen haben haben keine Hinweise ergeben.

Gibt es ein Forum, in dem man mit den Entwicklern Kontakt aufnehmen kann?
Es geht ja nun nicht mehr um Fragen zur Installation.
Eine Frage der Konfiguration wird es wohl auch nicht sein.
Ich vermute fehlerhaften Code oder Unverträglichkeit in der Betriebssystemumgebung.
Irgend etwas wird erwartet, was in meiner Umgebung nicht vorhanden ist.

Gruß
Bernd

Putzlowitsch

Was ist mit den oben genannten Wordpress-HTTP-Transport-Methoden?

Hast Du mal nachgesehen, welche konfiguriert sind und welche möglicherweise nicht funktionieren. Bei mir war es damals, als ich das gleiche Problem hatte, die Streams-Methode. Diese wurde zwar als verfügbar erkannt, war aber PHP-seitig nicht richtig konfiguriert. Das deaktivieren der Streams-Methode hatte dann das Problem behoben.

Gruß
Ingo

Bernd aus No

Hi Ingo,

den Hinweis aus das Plugin habe ich nicht die Aufmerksamkeit zukommen lassen, die ihm gebührt.
Ich bin zutiefst zerknirscht!!

Habe das "123 HTTP Transport" installiert.
Wenn "streams" und "fopen" deaktiviert sind, läuft alles wunderbar.

-------- Problem behoben --------

Vielen Dank für deine Hilfe.
Bernd

PS: Beim Aktivieren des Plugin gab es diese Fehlermeldung:
"Das Plugin hat unerwartet 166 Zeichen während der Aktivierung erzeugt. Falls du Meldungen “headers already sent” siehst oder dein Feed nicht funktioniert, solltest du das Plugin deaktivieren oder löschen."
Es scheint jedoch gut zu funktionieren.

Putzlowitsch

Ja, die Meldung hatte ich vorhin bei mir beim Testen auch. Kann ich mir nicht erklären, wie das kommt. Muß ich mal untersuchen...

Gruß
Ingo

r23

Zitat von Bernd aus No

Habe das "123 HTTP Transport" installiert.
Wenn "streams" und "fopen" deaktiviert sind, läuft alles wunderbar.

Du verwendest ein fehlerhaltes und altes System.

Apache/2.2.3 (Debian) DAV/2 PHP/5.2.0-8+etch16 mod_ssl/2.2.3 OpenSSL/0.9.8c

PHP ist z.B.
Version 5.2.14

bzw. PHP 5.3.3 aktuell.

Hier die ChangeLog mit Links zu Bug Meldungen rund um Streams und Co
http://php.net/ChangeLog-5.php

Hier ein Link zum PHP Handbuch

Aktuell bleiben
http://www.php.net/manual/de/security.current.php

Zitat

Wie auch bei anderen Scriptsprachen und Programmen auf Systemebene, ist der beste Ansatz ein regelmäßiges Updaten, und sich laufend über die letzten Versionen und deren Änderungen zu informieren.

Du kannst dir so unnötige arbeit ersparen.

cu

ralf

Bernd aus No

Hi Ralf,

so alt, wie du es darstellst, ist mein System nicht. Ich habe lauter virtuelle Maschinen unter xen laufen.
Grundlage ist der "c't-Server" vom letzten Jahr (Debian etch).

Alle Maschinen sind auf dem aktuellen Stand, den man mit 'apt-get update; apt-get -y upgrade' erreichen kann.
Natürlich weiß ich, dass es eine neuere Debian-Variante gibt und dass auch Apache, mySQl und PHP sich weiter entwickelt haben.

Ein neues System aufzusetzen bedeutet, neue Hardware beschaffen. Das laufende System wird gebraucht und kann nicht einfach vom Netz genommen werden.

Das Host-System muss mit neuem Debian nachgebaut werden (einen neueren "c't-Server" gibt es leider noch nicht) und alle virtuellen Maschinen müssen portiert werden (einige Hundert GByte).

Ich denke, ein einigermaßen gut funktionierendes System sollte zwei bis drei Jahre laufen, bevor man es gegen etwas Neueres austauscht - zumindest im privaten Bereicht.

Wir sollten die Diskussion an dieser Stelle beenden.
Ich danke allen, die zur Lösung meines Problems beigetragen haben.

Gruß
Bernd

Willkommen! Melden Sie sich an oder registrieren Sie sich.

http-Aufruf geht, https braucht bis zu 2 Minuten

Jetzt mitmachen!