apache 2.2 update

B

Bernd R. Rickert

Angesehenes Mitglied
Hallo,
Kann mir mal jemand sagen, was an apache 2.2 besser ist als an Apache 2.0.
Ausser dass der Apache 2.2 total empfindlich auf outputs vor headern reagiert, was einen Haufen Arbeit beim Umstellen bringt,
konnte ich keine Änderung feststellen.
Bei Javascript vor dem Header sehe ich den Output ja noch ein, aber das eine leere Programmzeile als Output bewertet wird, finde ich ziemlich übertrieben.

Neues Konto wegen Mailserver update.

Gruss

Bernd-Reinhard
 
Hallo,


QUOTE (Bernd R. Rickert @ Mi 22.3.2006, 11:23)[...]
Bei Javascript vor dem Header sehe ich den Output ja noch ein, aber das eine leere Programmzeile als Output bewertet wird, finde ich ziemlich übertrieben.
[...]

von was für einen Programmcode genau redest Du?

Wenn der Apache 2.2 sehr kleinlich bei Header von serverseitigen Scripten ist, würde ich das schon eher positiv sehen, als negativ.



MfG Sascha Ahlers
 
Hallo Sascha,

Bei includes die mit so beginnen ist der Fehler aufgetreten.

<?

session_start()
....

Umgeschrieben auf
<? session_start()
....

funktionierte es dann.
Bei einem include habe ich den Kommentar aus ersten Zeile entfernen müssen.
Bei weiteren includes wurde der "?>" als output erkannt, aber nicht immer, was den Eindruck von Instabilität hinterlässt. Apache 2.0 scheint mir wesentlich robuster. Es ist halt ein anderer Programmierstil den gesamten output erst zwischenzuspeichern, besonders, wenn mitten in den Seiten Javascripte mit anschliessendem exit - Befehl stehen.

Mysql 5 ist ja eine echte Bereicherung, aber was ist nun besser am Apache 2.2?

Gruss
Tuemmel
 
Ich finde es schade, dass viele ehemals gute Scripte, wie z.B. der php open chat einfach durch solche Kleinlichkeiten auf der Strecke bleiben.
 
QUOTE (Bernd R. Rickert @ Mi 22.3.2006, 15:09)[...] Bei includes die mit so beginnen ist der Fehler aufgetreten. [...]

Das liegt an PHP, das hat überhaupt nichts mit dem Apache zu tun. Außerdem stellen solle Tags eigentlich keinen guten Programmierstil unter PHP dar.
Ich vermute mal eher, dort hat sich ein kryptisches Zeichen eingemögelt. Wenn es wirklich an den den Apache liegt, wovon ich nicht ausgehe, weil die Datei ja eigentlich vorher durch den PHP Parser geht und von dort an an den Apache weitergereicht wird. Der Apache behandelt dort eher die Abfrage.
Ansonsten diesen Fehler einfach mal melden.



QUOTE (Bernd R. Rickert @ Mi 22.3.2006, 15:09)[...] Mysql 5 ist ja eine echte Bereicherung, aber was ist nun besser am Apache 2.2? [...]

Was am Apache 2.2 bisher besser ist, kann ich nicht sagen, ich verwende noch den Apache 2.0 und habe den gelesenden Artikel über den Apache 2.2 schon wieder weitesgehend vergessen. Ich schau mal, ob ich Ihn widerfinde.



QUOTE (Bernd R. Rickert @ Mi 22.3.2006, 15:15)Ich finde es schade, dass viele ehemals gute Scripte, wie z.B. der php open chat einfach durch solche Kleinlichkeiten auf der Strecke bleiben.

Nur leider handelt es sich meistens auch um hausgemachte Fehler von den Programmiern der Scripte. Ich ärgere mich über solche Scripte schon regelmäßig über sowas, da ich mir schon zu Anfang angewöhnt habe, immer die "short_open_tags" abzuschalten.



MfG Sascha Ahlers
 
Die php-Version ist eigentlich noch die gleiche geblieben und vor dem Update lief alles glatt.
Mit dem kryptischen Zeichen stimme ich Dir zu.
Ich hätte die Dateien als Ascii- code analysieren sollen.

Gruss

Bernd R. Rickert
 
So, nun zu den Verbesserungen im Apache 2.2.

Beim Apache 2.2 wurde folgendes verbessert:
  • Verbesserte, neue und erweiterte Module für die Authenfizierung.
  • Die Proxy-Funktion des Apache, mit zwei neuen Modulen, wobei mod_proxy_balancer, zum ersten Mal das Load-Balancing ohne Software von Drittanbieter realisiert werden kann.
  • Erweiterung der Multiprocessing-Module, welche seit Version 2.0.x eingeführt wurden. (Für mich hört sich das in dem Artikel auch nach einer Verbesserung der Arbeitsweise an.)
  • Verbesserung des Modules Filter.

Quelle: iX 1/2006 - Neuerungen in Apache 2.2 (Feder-Update) von Sascha Kersken, Seite 99



MfG Sascha Ahlers
 
QUOTE (Sascha Ahlers @ Mi 22.3.2006, 16:34) Ich vermute mal eher, dort hat sich ein kryptisches Zeichen eingemögelt. Wenn es wirklich an den den Apache liegt, wovon ich nicht ausgehe.

Vielen Dank für die Ausführungen,

Die Multiprocessing-Module sind für den Betrieb mehrerer Server auf einem Computer optimiert,
habe ich irgendwo aufgeschnappt.

Der Parser kommt weder mit einem Zeilenumbruchszeichen ascii 13 noch mit einem Leerzeichen ascii 10 vor dem <? tag zurecht.
Wie er auf ascii 160 reagiert habe ich noch nicht ausprobiert. Der ist ja auch ziemlich selten.

Inzwischen scheint sich der Parser selbst auch ein wenig stabilisiert zu haben, denn diese Ascii-Zeichen nach dem Einleitungstag <? werden nicht mehr interpretiert. Vor ein paar Tagen war das einmal der Fall, als die Zeile mit dem ?> Tag in einer Fehlermeldung diagnostiziert wurde. Auslöser war aber eher ein 13 10 oder 160 vor der Zeile mit dem End-Tag.

Sorry für falsche Apache-Anschuldigungen.

Gruss

Bernd R. Rickert
 
Hast Du mal versucht, auf die PHP-Short-Tags zu verziechten, und stattdessen eher die PHP-Full-Tags zu verwenden?


CODE PHP-Short-Tags:
<? ... ?>
<?= "Eine Ausgabe" ?>

PHP-Full-Tags:
<?php ... ?>
<?php echo "Eine Ausgabe"; ?>


Siehe dazu auch: http://www.php.net/manual/de/language.basic-syntax.php


Kurz noch angemerkt, aber ein Zeichen zu 160 glaube ich, gibt es nicht im ASCII, dann wärest Du schon bei ANSI-Zeichensatz.
wink.gif




MfG Sascha Ahlers
 
Hallo Sascha,

Danke für den Hinweis, ich hab alle short tags geändert in lange.
Ich werde mich dann mal in die Authentifierung einlesen.

btw.
Inder Ascii-Zeichensatztabellechr(160) wird im erweiterten Ascii - Code zwar als ein à, dargestellt, ist aber hier tatsächlich ein ansi-Code-Space-Zeichen, dass normalerweise in Textareas vor oder nach einem Zeilenumbruch gesetzt wird.

Gruss

Bernd-R. Rickert

 
QUOTE (Bernd R. Rickert @ So 26.3.2006, 5:20) [...] ist aber hier tatsächlich ein ansi-Code-Space-Zeichen, dass normalerweise in Textareas vor oder nach einem Zeilenumbruch gesetzt wird. [...]

Bei einer Textarea wird normalerweise ein Carriage Return und ein Line Feed (New Line) gesetzt → "\r\n", und keinerlei Leerzeichen, es sei denn man tippt selber eines ein.



MfG Sascha Ahlers
 
QUOTE (Sascha Ahlers @ So 26.3.2006, 7:07)
QUOTE (Bernd R. Rickert @ So 26.3.2006, 5:20) [...] ist aber hier tatsächlich ein ansi-Code-Space-Zeichen, dass normalerweise in Textareas vor oder nach einem Zeilenumbruch gesetzt wird. [...]

Bei einer Textarea wird normalerweise ein Carriage Return und ein Line Feed (New Line) gesetzt → "\r\n", und keinerlei Leerzeichen, es sei denn man tippt selber eines ein.



MfG Sascha Ahlers

Dann frage ich mich, was am ie 6 normal ist. Dort werden in dem Fall Leerzeichen eingesetzt.

Gruss

Bernd R. Rickert
 
QUOTE (Bernd R. Rickert @ So 26.3.2006, 10:26) [...] Dann frage ich mich, was am ie 6 normal ist. Dort werden in dem Fall Leerzeichen eingesetzt. [...]

Keine Ahnung, was beim MSIE 6 normal ist, aber bei mir scheint er dies nicht zu machen. Auch wenn dieser nur mittels Wine betrieben wird.


MfG Sascha Ahlers
 
Hallo Sascha,

Bei mir macht er das, und ich hab mich bei den Inputs für gruppenfreizeit einen ganzen Tag damit herumgeschlagen müssen, bis ich endlich rausgekriegt habe, warum die Zeilenumbrüche sich immer verschoben haben oder Leerzeichen hinzukamen, ohne dass die geschrieben worden sind. Anschliessend habe ich die chr(160)-Leerzeichen mit str_replace vor dem Speichern entfernt.

Gruss

Bernd R. Rickert


 
Genau aufgetreten sind die 160er, wenn eine Textarea zum Updaten aus der Datenbank mit einem Value gefüllt worden ist und anschliessend verändert wurde. Beim Relaod mit den Request-Variablen waren dann die 160er mit dabei, ohne jedoch manuell eingegeben worden zu sein.

Gruss

Bernd R. Rickert
 
Sie müssen sich einloggen oder registrieren, um hier antworten zu können.
Zurück
Oben