location-header und Provider-Einschränkungen?

[Patrick Andrieu]

Hallo alle!

Gibt es sowas?
Dieser dreizeiler läuft auf Atomic-Eggs einwandfrei:

<?php
  header("Location: http://www.google.de");
?>

Das gleiche Skriptche auf www.netclusive.de:

Warning: Cannot modify header information - headers already sent by (output startet at /home/www/USER/html/PFAD/ZUM/SCRIPT/script.php:1) in /home/www/USER/html/PFAD/ZUM/SCRIPT/script.php on line 2

Echt, der sch... Provider bietet noch nicht mal Perl. Ich hoffe, die lesen hier mit. Das gehackte-Seite-Problem, das ich letzens hier ansprach, fand auch bei denen statt.

Viele Grüße aus Frankfurt/Main,
Patrick

[ChrisB]

Hi,

Dieser dreizeiler läuft auf Atomic-Eggs einwandfrei:

<?php
  header("Location: http://www.google.de");
?>

Das gleiche Skriptche auf www.netclusive.de:

Warning: Cannot modify header information - headers already sent by (output startet at /home/www/USER/html/PFAD/ZUM/SCRIPT/script.php:1) in /home/www/USER/html/PFAD/ZUM/SCRIPT/script.php on line 2

Dann ist da vermutlich kein output buffering per Default aktiv, was auf deiner Eggs-Seite deinen Fehler implizit "behebt".

Script in UTF-8 mit BOM gespeichert?

MfG ChrisB

[Patrick Andrieu]

Hallo Christoph!

was auf deiner Eggs-Seite deinen Fehler implizit "behebt".

Was für »meinen« Fehler?

Script in UTF-8 mit BOM gespeichert?

Kann ich mir nur beim ersten Test vorstellen. Das erste Skript könnte so gespeichert worden sein, beim Test-Skript http://www.atomic-eggs.com/z_testdir/scripts/php/location.php, das ich auch prompt bei netclusive hochgeladen habe, sicher nicht (wobei »sicher« unsicher ist, ich blicke manchmal nicht durch, wann EditPad Lite eine BOM reinschreibt und wann nicht).

Viele Grüße aus Frankfurt/Main,
Patrick

[ChrisB]

Hi,

was auf deiner Eggs-Seite deinen Fehler implizit "behebt".

Was für »meinen« Fehler?

Den, irgendwelche Ausgaben vor einem header-Aufruf gemacht zu haben.

Script in UTF-8 mit BOM gespeichert?

Kann ich mir nur beim ersten Test vorstellen. Das erste Skript könnte so gespeichert worden sein, beim Test-Skript http://www.atomic-eggs.com/z_testdir/scripts/php/location.php, das ich auch prompt bei netclusive hochgeladen habe, sicher nicht (wobei »sicher« unsicher ist, ich blicke manchmal nicht durch, wann EditPad Lite eine BOM reinschreibt und wann nicht).

Na dann solltest du erst mal dieses "sicher" verifizieren.

Die Meldung besagt ja, dass Ausgabe und header im gleichen Script auftraten, also kann es kaum an irgendwelchen automatisch eingebundenen prepend-Files o.ä. liegen.
Leerzeile kann auch nicht sein, sonst würden sie Zeilennummern ja nicht 1 und 2 lauten. Bliebe noch anderer Whitespace vor dem öffnenden PHP-Tag - oder eben die "unsichtbare" BOM, als vermutlich plausibelste Ursache.

MfG ChrisB

[Patrick Andrieu]

Hallo ChrisB!

Den, irgendwelche Ausgaben vor einem header-Aufruf gemacht zu haben.

Es gibt keine. Ich kann zwar kein PHP, aber so dumm bin ich net ;) Habe doch dreizeiler erst getestet und dann gepsotet, den ich ich geschrieben habe, nach dem das um nur ein paar Zelen längere Skript (aber ohne Ausgabe) nicht funzen™ wollte.

[BOM]
Na dann solltest du erst mal dieses "sicher" verifizieren.

Steht für morgen an (heute kein Bock mehr - geht mir wie bei den Collapsing Margins: ich geh' baden) ;)

Bliebe noch anderer Whitespace vor dem öffnenden PHP-Tag

Gibt´s keine (im Editor sichtbaren)

der eben die "unsichtbare" BOM, als vermutlich plausibelste Ursache.

Ja, aber die gäbe es doch auch bei _meinem_ Server, oder? Ich habe das location.php-Skript nach den erfloglosen Versuchen mit meinem Original-Skript ZUERST auf Atomic Eggs hochgeladen UND DANN bei netclusive. Wenn PHP mit der BOM ein Problem hat, dann sollte es auch BEI MIR nicht funzen™, oder?

Viele Grüße aus Frankfurt/Main,
Patrick

[ChrisB]

Hi,

Den, irgendwelche Ausgaben vor einem header-Aufruf gemacht zu haben.

Es gibt keine. Ich kann zwar kein PHP, aber so dumm bin ich net ;)

Aber nur die Tatsache, dass du für Perl mehr übrig hast, bringt PHP sicher nicht dazu, dich anzulügen.

oder eben die "unsichtbare" BOM, als vermutlich plausibelste Ursache.

Ja, aber die gäbe es doch auch bei _meinem_ Server, oder?

Nein, wie gesagt - wenn output buffering aktiv ist, dann wird dieser "Fehler" dadurch kompensiert, weil alle Ausgaben nicht sofort herausgeschickt, sondern zunächst in einem Puffer gesammelt werden, so dass auch spätere Aufrufe von header noch möglich sind - diese können dann nämlich immer noch an den Anfang des HTTP Response gepackt werden (wo sie hin gehören), eben weil vorherige Ausgaben noch nicht durchgereicht wurden.

MfG ChrisB

[Patrick Andrieu]

Hallo ChrisB!

Aber nur die Tatsache, dass du für Perl mehr übrig hast, bringt PHP sicher nicht dazu, dich anzulügen.

Habe ich nie behauptet, aber ich behaupte: für Provider, die kein Perl anbieten, habe ich nichts übrig.

Ich glaube und hoffe: ich bin nicht der Einzige.

Nein, wie gesagt - wenn output buffering aktiv ist, dann wird dieser "Fehler"

Ja, _was_ für einen Fehler? Die (mögliche BOM)? Die Tatasche, dass mir PHP nicht liegt? Was denn? Es existiert kein Leerzeichen noch irgendein echo-Ausgabe. Der Dreizeiler ist so, wie ich ihn gepostet habe.

Und wie kriege ich 'raus, ob dieses »output buffering« aktiv ist oder nicht? Aus der phpinfo? Und wenn es inaktiv ist, kann ich das ändern?

Was kann ein Ottonormalphplaie, der irgendwas von header('location: ...') liest, dafür, dass sein Provider etwas anders eingestellt hat, als der Provider von seinem Nachbarn?

Viele Grüße aus Frankfurt/Main,
Patrick

[ChrisB]

Hi,

Nein, wie gesagt - wenn output buffering aktiv ist, dann wird dieser "Fehler"

Ja, _was_ für einen Fehler? Die (mögliche BOM)?

Ja - wenn du alles andere, also "wirkliche" Ausgaben (inkl. white space) ausschliessen kannst - dan bleibt eigentlich nur noch die.

Und wie kriege ich 'raus, ob dieses »output buffering« aktiv ist oder nicht? Aus der phpinfo?

Jipp, nach dem Wert der Direktive output_buffering schauen.

Und wenn es inaktiv ist, kann ich das ändern?

Die Direktive ist PHP_INI_PERDIR änderbar.

Was kann ein Ottonormalphplaie, der irgendwas von header('location: ...') liest, dafür, dass sein Provider etwas anders eingestellt hat, als der Provider von seinem Nachbarn?

Nun, auch der Ottonormalphplaie sollte wissen, dass davor keine Ausgaben erlaubt sind. Die BOM ist ein Sonderfall, eben weil man sie nicht "sieht" - aber sie gehört eben auch zu den Ausgaben, wenn sie vorhanden ist - also Scripte in UTF-8 wenn möglich immer ohne speichern.

Und output_buffering ist eben keine Einstellung, die man "einfach so" aktivieren sollte, ohne guten Grund. Wenn ein Provider das per Default doch macht, halte ich das für eher unsinnig und kontraproduktiv.

MfG ChrisB

[Patrick Andrieu]

Hallo ChrisB!

Also, schon mal Danke für Deine Geduld.
Icg habe selber keine mehr, und morgen steht eh was anders auf dem Programm ;)

Ja - wenn du alles andere, also "wirkliche" Ausgaben (inkl. white space) ausschliessen kannst - dan bleibt eigentlich nur noch die.

Es sind keine, außer der Einrückung.

Die Direktive ist PHP_INI_PERDIR änderbar.

Bei so einem Provider, der auf sicher spielt und dennoch XSS-Scripting durchgehen lässt, habe ich meine Zweifel, ob er Usern, die gern Perl hätten aber nicht dürfen, erlaubt, in irgendeine INI rumzupfuschen erlaubt.

Ich versuche schon, dem »Kunden« dazu zu bewegen, sich einen (in Worten) ORDENTLICHEN Provider zuzulegen, der wo Perl hat, und wo der alte Onkel Pata sich damit auskennt, statt dieses Pseudo-Programmierzeugs (siehe Alexanders Antwort weiter unten).

Und output_buffering ist eben keine Einstellung, die man "einfach so" aktivieren sollte, ohne guten Grund. Wenn ein Provider das per Default doch macht, halte ich das für eher unsinnig und kontraproduktiv.

Der Gerechtigkeithalber muss ich sagen, dass Perl nicht immer Perl ist, suche einfach nach »Tainted Love« im Archiv.

Wie auch immer, ich habe keine Lust, mich mit irgendwelchen Providerschrott (so sollte es nicht an der BOM liegen) auseinanderzusetzen, und wenn, die Umleitung wird höchstens 5% der Besucher meines Auftraggebers betreffen - dann mache ich sie eben über den Umweg eines Aufrufs bei MIR. Dann läuft's und dann hat sogar netclusive einen Aufruf weniger! Hoch leben fähige Provider, die sowas einkalkulieren!

Badegelseifenprost!

Viele Grüße aus Frankfurt/Main,
Patrick

[ChrisB]

Hi,

Die Direktive ist PHP_INI_PERDIR änderbar.

Bei so einem Provider, der auf sicher spielt und dennoch XSS-Scripting durchgehen lässt,

Hu?
XSS liegt im allgemeinen eher an den Scripten, die eingesetzt werden, und eher weniger am Provider.

habe ich meine Zweifel, ob er Usern, die gern Perl hätten aber nicht dürfen, erlaubt, in irgendeine INI rumzupfuschen erlaubt.

PHP_INI_PERDIR bedeutet i.d.R. unter anderem in einer .htaccess konfigurierbar.

Ich versuche schon, dem »Kunden« dazu zu bewegen, sich einen (in Worten) ORDENTLICHEN Provider zuzulegen, der wo Perl hat, und wo der alte Onkel Pata sich damit auskennt, statt dieses Pseudo-Programmierzeugs (siehe Alexanders Antwort weiter unten).

Wenn PHP-Scripte "Pseudo-Programmierung" sind, liegt das oftmals am - "Pseudo-Programmierer" :-)
Und auch Perl erlaubt dem damit unerfahrenen Nutzer sicherlich, damit Mist zu bauen.

Wie auch immer, ich habe keine Lust, mich mit irgendwelchen Providerschrott (so sollte es nicht an der BOM liegen) auseinanderzusetzen,

Warten wir die Klärung dieses Umstandes doch erst mal ab.

MfG ChrisB

[Patrick Andrieu]

Hallo ChrisB!

Wenn PHP-Scripte "Pseudo-Programmierung" sind, liegt das oftmals am - "Pseudo-Programmierer" :-)
Und auch Perl erlaubt dem damit unerfahrenen Nutzer sicherlich, damit Mist zu bauen.

Sicher. Ich habe auch keine Scheu, mich in Sachen PHP als Pseudo-Programmierer zu betrachten...

»» Wie auch immer, ich habe keine Lust, mich mit irgendwelchen Providerschrott (so sollte es nicht an der BOM liegen) auseinanderzusetzen,
Warten wir die Klärung dieses Umstandes doch erst mal ab.

...zumal Du mt der BOM recht hattest ;)

Nichtsdestotrotz wird demnächst gewechselt, die Leuten wollen auch da weg (was'n Glück). Dann darf ich mich serverseitig wieder austoben und muss nicht stundenlang suchen, bevor ich etwas auf die Beinen stelle.

Viele Grüße aus Frankfurt/Main,
Patrick

[Malcolm Beck´s]

hi,

Wie auch immer, ich habe keine Lust, mich mit irgendwelchen Providerschrott (so sollte es nicht an der BOM liegen) auseinanderzusetzen,

Erstelle doch mal eine Seite, die einfach Valides HTML ausspuckt, diese dann hochladen und durch den Valligator jagen, der sagt dir, ob BOM oder nicht.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">  
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">  
<head><title></title><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body></body></html>

Das einfach per echo in der PHP-Datei ausgeben lassen und validieren; AFAIK neigt Editpad zur BOM, muss man in den Einstellungen korrigieren.

mfg

[Patrick Andrieu]

Hallo Malcolm!

Erstelle doch mal eine Seite, die einfach Valides HTML ausspuckt, diese dann hochladen und durch den Valligator jagen, der sagt dir, ob BOM oder nicht.

Bei HTML-Dateien habe ich keine Probleme, auch keine Warnung beim Vali, dass eine BOM gefunden wurde.

Das einfach per echo in der PHP-Datei ausgeben lassen und validieren; AFAIK neigt Editpad zur BOM, muss man in den Einstellungen korrigieren.

Bei anderen Dateien, so beim Gallery-Skript letztens, ist es mir aufgefallen. Das Template hat die Endung .tpl, beim Validieren des resultierenden XHTML erhalte ich die Warnung. Dabei meinte ich, in den Einstellung »speichern ohne BOM« gewählt zu haben, oder gilt das bei EditPad nur für HTML-Dateien?

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Re!

Dabei meinte ich, in den Einstellung »speichern ohne BOM« gewählt zu haben,

Hatte ich, doch nur für HTML-Dateien ;)

oder gilt das bei EditPad nur für HTML-Dateien?

Wenn ich es so einstelle, ja ;)

Jetzt ist alls i.O.

Viele Grüße aus Frankfurt/Main,
Patrick

[Malcolm Beck´s]

hi,

Hatte ich, doch nur für HTML-Dateien ;)

Hast du schon auf UTF-8 umgestellt? Oder ist die BOM das Resultat einer umstellung?

» oder gilt das bei EditPad nur für HTML-Dateien?

Da weiss ich auch nicht, was sich die Entwickler dabei gedacht haben, das man für jeden Datentyp das extra einstellen muss, und warum es überhaupt diese BOM gibt.

mfg

[Patrick Andrieu]

Hallo Malcolm!

Hast du schon auf UTF-8 umgestellt? Oder ist die BOM das Resultat einer umstellung?

Die BOM hatte mir EditPad in jede Datei geschrieben, die nicht HTML war. Und das war mit dem PHP-Test-Skript ja der Fall.

Jetzt habe ich die Einstellungen geändert (alle Dateien KEINE BOM) und es ist alles in Ordnung.

Viele Grüße aus Frankfurt/Main,
Patrick

[Patrick Andrieu]

Hallo in-eigener-Sache!

Habe doch dreizeiler

Habe doch den Dreizeiler...

den ich ich geschrieben habe

Ja, ich ich ich ich und ich...

Ich  hasse Safaris Textareas Handling und die Tatsache, dass ich bei drei Rechnern und drei Tastaturen nie weiß, wo ich bin ;)

Viele Grüße aus Frankfurt/Main,
Patrick

[Cybaer]

Hi,

Echt, der sch... Provider bietet noch nicht mal Perl.

Was den Fehler angeht: Don't blame the provider, it's just *your* fault!

Was Perl angeht: PHP ist nunmal deutlich beliebter.

Gruß, Cybaer