1. Herzlich willkommen bei WPDE.org, dem grössten und ältesten deutschsprachigen Community-Forum rund um das Thema WordPress. Du musst angemeldet oder registriert sein, um Beiträge verfassen zu können.
    Information ausblenden

http-Aufruf geht, https braucht bis zu 2 Minuten

Dieses Thema im Forum "Installation" wurde erstellt von Bernd aus No, 3. August 2010.

  1. Bernd aus No

    Bernd aus No Member

    Registriert seit:
    24. Juli 2008
    Beiträge:
    11
    Zustimmungen:
    0
    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
     
  2. r23

    r23 Well-Known Member

    Registriert seit:
    9. Dezember 2006
    Beiträge:
    6.240
    Zustimmungen:
    386
    Hallo Bernd,


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

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

    PHP:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Frage einfach unter einer gültigen SSL Verbindung den Inhalt von $_SERVER ab...

    PHP:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    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
     
  3. Bernd aus No

    Bernd aus No Member

    Registriert seit:
    24. Juli 2008
    Beiträge:
    11
    Zustimmungen:
    0
    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
     
  4. r23

    r23 Well-Known Member

    Registriert seit:
    9. Dezember 2006
    Beiträge:
    6.240
    Zustimmungen:
    386
    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:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    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.


    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

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

    hth

    ralf
     
  5. Bernd aus No

    Bernd aus No Member

    Registriert seit:
    24. Juli 2008
    Beiträge:
    11
    Zustimmungen:
    0
    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
     
  6. r23

    r23 Well-Known Member

    Registriert seit:
    9. Dezember 2006
    Beiträge:
    6.240
    Zustimmungen:
    386
    Hallo,

    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 ;)

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






    ich verwende in httpd.conf


    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!


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

    Code:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    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
     
  7. Putzlowitsch

    Putzlowitsch Well-Known Member

    Registriert seit:
    21. Oktober 2006
    Beiträge:
    5.955
    Zustimmungen:
    47
    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:
    Entschuldige, aber du musst dich registrieren oder anmelden um den Inhalt sehen zu können!
    Das z.B. in die functions.php des Themes einfügen und gucken was passiert.

    Gruß
    Ingo
     
  8. Bernd aus No

    Bernd aus No Member

    Registriert seit:
    24. Juli 2008
    Beiträge:
    11
    Zustimmungen:
    0
    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.
     
  9. Putzlowitsch

    Putzlowitsch Well-Known Member

    Registriert seit:
    21. Oktober 2006
    Beiträge:
    5.955
    Zustimmungen:
    47
    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
     
  10. Bernd aus No

    Bernd aus No Member

    Registriert seit:
    24. Juli 2008
    Beiträge:
    11
    Zustimmungen:
    0
    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
     
  11. Putzlowitsch

    Putzlowitsch Well-Known Member

    Registriert seit:
    21. Oktober 2006
    Beiträge:
    5.955
    Zustimmungen:
    47
    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
     
  12. Bernd aus No

    Bernd aus No Member

    Registriert seit:
    24. Juli 2008
    Beiträge:
    11
    Zustimmungen:
    0
    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.
     
  13. Putzlowitsch

    Putzlowitsch Well-Known Member

    Registriert seit:
    21. Oktober 2006
    Beiträge:
    5.955
    Zustimmungen:
    47
    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
     
  14. r23

    r23 Well-Known Member

    Registriert seit:
    9. Dezember 2006
    Beiträge:
    6.240
    Zustimmungen:
    386
    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
    Du kannst dir so unnötige arbeit ersparen.

    cu

    ralf
     
  15. Bernd aus No

    Bernd aus No Member

    Registriert seit:
    24. Juli 2008
    Beiträge:
    11
    Zustimmungen:
    0
    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
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden