Header-Funktion funktioniert nicht

[headhunt3r]

Hallo liebe bplaced-Gemeinde,
ich möchte gern meinen Webspace von meinem alten Anbieter auf bplaced umziehen.

Nun kommt mein Problem:

Und zwar funktioniert bei bplaced der Aufruf header(“Location: xxx.php”); nicht.
Wenn ich auf einen Button bei mir klicke, um eine andere Seite auf meinem Webspace zu öffnen, bringt er folgendes:

http://xxx.bplaced.net/xxx/xxx.php?action=andere

anstatt auf diese Seite zu wechseln:

http://xxx.bplacet.net/xxx/xxx2.php

die Action wird folgendermaßen aufgerufen:

Andere Mitglieder

Sozusagen klickt man auf den Button “Andere Mitglieder”, daraufhin geht er in der php-Datei in die Action andere (und übermittelt die Formulardaten an die Funktion andere):

If ($action == “andere”)
{
header(“Location: xxx2.php”);
}

und öffnet die andere Seite xxx2.php .

Genau dies klappt auf meinem anderen Hoster so, also kann in diesem Code ja kein Fehler sein (meines Erachtens, sonst würde es ja beim anderen Hoster nicht funktionieren).

Nun habe ich die Seite auf bplaced hochgeladen und keiner meiner Buttons, die ich so aufgebaut habe, klappt mehr.

Habt ihr eine Idee woran es liegen könnte?

Das Nachfragen beim Support brachte leider auch keinen Erfolg, deswegen versuche ich es nun auf diesem Wege.

Danke schonmal im Vorraus,

mfg Headhunt3r

[sbbaus]

Mmh, ist das Verzeichnis vom xxx2.php vielleicht nicht richtig? Ich bin ehrlich gesagt auch etwas verwundert, warums nicht klappt?!

[headhunt3r]

Die beiden php-Dateien befinden sich definitiv im gleichen Verzeichnis.

Müssen Sie ja auch, da ich es 1 zu 1 kopiert habe, und es beim anderen Hoster genau so funktioniert (also nicht nur die php-Dateien, sondern die ganze Ordner-Struktur auch).

Ich habe sogar das, was ich bei bplaced hochgeladen habe, nochmal erneut beim anderen Hoster hochgeladen, und bei diesem funktioniert es weiterhin.

Vlt. wurde irgendeine php-Funktion, die meine Funktion benötigt, hier deaktiviert?

[hoffmann]

Tja, ich glaube nicht, daß es daran liegt, aber bereits das
(X)HTML ist Pfusch. Einerseits wird das Formular per 'POST’
verschickt, andererseits wird aber ein GET-Parameter
angehängt - Unsinn, obgleich das bei einigen browsern und
servern funktionieren mag.

Wird der GET-Parameter action überhaupt irgendwo eingelesen?

[headhunt3r]

[quote=“hoffmann”]Tja, ich glaube nicht, daß es daran liegt, aber bereits das
(X)HTML ist Pfusch. Einerseits wird das Formular per 'POST’
verschickt, andererseits wird aber ein GET-Parameter
angehängt - Unsinn, obgleich das bei einigen browsern und
servern funktionieren mag.

Wird der GET-Parameter action überhaupt irgendwo eingelesen?[/quote]

Wieso ist das Unsinn?

Und zu deiner Frage:
Nein, der GET-Parameter action wird nirgends eingelesen
(also nicht in der Form: $action=$_GET[“action”]; ).
Dies könnte ich aber ausprobieren, wenn ich von der Arbeit zu Hause bin.

Da ich ja der Meinung bin/war, dass wenn ich im Formular xxx.php?action=andere angebe, er von alleine in die ($action==“andere”) geht.

Weil ich es ihm ja beim abschicken des Formulars “sage”, dass er in die Action gehen soll.

Oder versteh ich da was falsch?

Danke schonmal für die Antworten.

[sbbaus]

Du verstehst da in der Tat was falsch ! Solltest natürlich erst die Variable einlesen, das es bei dem anderen Host klappt ist wahrscheinlich eine Einstellung des Servers.

[headhunt3r]

@sbbaus

Du verstehst da in der Tat was falsch ! Solltest natürlich erst die Variable einlesen, das es bei dem anderen Host klappt ist wahrscheinlich eine Einstellung des Servers.

Ok, ich werde es sofort ausprobieren wenn ich heute von der Arbeit komme und werde euch auf dem Laufenden in dem Thread hier halten.

Danke nochmal an euch für die so rasche Antwort.

Mfg Headhunt3r

[hoffmann]

Zum Pfusch - Formulardaten werden entweder per POST oder GET
geschickt, nicht beides. Ob man das per HTTP beides gleichzeitig
senden darf, weiß ich nicht genau, beim (X)HTML ist es jedenfalls
technisch ausgeschlossen.

Mag natürlich sein, daß da einige browser und server den
Pfusch großzügig umgehen, verlassen sollte man sich darauf
aber wohl nicht.

Zum Verständnis: Dieser angehängte GET-Parameter täuscht
vor, daß man ein Formular per GET verschickt hat, das ist
keinesfalls eine beliebige Konstruktion, sondern beschreibt
genau das, was der browser eigentlich losschickt, wenn ein
Formular per GET verschickt wird. Das tut er nicht, wenn es per
POST verschickt wird, was eine andere Methode ist.

Zum dem Fehler - klar, wenn es nicht in das Skript eingelesen
wird, wird es auf dem hiesigen server nicht funktionieren,
unabhängig davon, ob der Pfusch überhaupt funktionieren sollte
oder nicht. Ich denke, der Apache verarbeitet auch den Pfusch,
der eigentlich gar nicht auftreten sollten, wenn man das
ordentlich gemacht hat ;o) Ob jeder browser den Pfusch
verarbeitet, kann ich nicht sagen.

[chrisb]

@hoffmann

Formulardaten werden entweder per POST oder GET geschickt, nicht beides. Ob man das per HTTP beides gleichzeitig senden darf, weiß ich nicht genau, beim (X)HTML ist es jedenfalls technisch ausgeschlossen.

Hast du mal eine Stelle in der Spezifikation, wo das stehen soll?

Fakt ist, es funktioniert eigentlich überall. Mir ist noch kein Browser untergekommen, der damit Probleme macht.
Bei der serverseitigen Verarbeitung kommt es halt auf die verwendete Technik an.
PHP hat damit kein Problem, und auch andere Sprachen können sowohl Querystring als auch POST-Body auswerten.

[headhunt3r]

[quote=„headhunt3r“][quote=„hoffmann“]
Wird der GET-Parameter action überhaupt irgendwo eingelesen?[/quote]

$action=$_GET[„action“]
[/quote]

Dies war nun der Fehler bzw. die Lösung für mein Problem, ich bedanke mich bei hoffmann und bei sbbaus für die schnelle Hilfe … kann man ja mal vergessen, überall anders hatte ich das $_GET, nur grad dort nicht ^^.

Kann geschlossen werden .

Freundliche Grüße

Headhunt3r

[chrisb]

@headhunt3r

kann man ja mal vergessen, überall anders hatte ich das $_GET, nur grad dort nicht

Stelle bitte das error_reporting auf E_ALL (und display_errors auf on), während du entwickelst - dann kann PHP dich auf solche „Vergesslichkeiten” schon selber hinweisen.

[hoffmann]

@chrisb

[quote=„hoffmann“]Formulardaten werden entweder per POST oder GET geschickt, nicht beides. Ob man das per HTTP beides gleichzeitig senden darf, weiß ich nicht genau, beim (X)HTML ist es jedenfalls technisch ausgeschlossen.

Hast du mal eine Stelle in der Spezifikation, wo das stehen soll?
[/quote]

Das ist direkt die Definition des Attributes method, also z.B.

edition-w3.de/TR/1999/REC-ht … tml#h-17.1

oder ausführlicher erläutert:

edition-w3.de/TR/1999/REC-ht … mit-format

Insofern kann es bei einem anständigen HTML-Dokument gar
nicht passieren, daß beides auftritt.

Daß der Autor überhaupt selber eine ‚query‘ an die URI anhängt,
ist an sich keine ganz saubere Sache, denn das ist eigentlich
das Problem des browsers, dies anzuhängen, wenn ein Formular
losgeschickt wird. Ist auch einer der Gründe, warum zumindest
früher die Roboter von Suchmaschinen damit recht zögerlich
umgingen, weil das signalisiert, daß das kein permanenter Inhalt
ist, der sich zu indexieren lohnt (weil das inzwischen viele Leute
so machen, wird es dann jetzt eben doch indexiert, was aber zur
Folge hat, daß sich bei wirklich dynamischen URIs manchmal die
Roboter verirren und aufhängen).

Die PHP-Anleitungen sprechen deshalb in dem Zusammenhang
auch davon, daß eine GET-Anfrage vorgetäuscht wird.
Beispiel 3:
php.net/manual/de/faq.html.p … l.encoding

[chrisb]

[quote=“hoffmann”]Das ist direkt die Definition des Attributes method, also z.B.

edition-w3.de/TR/1999/REC-ht … tml#h-17.1

oder ausführlicher erläutert:

edition-w3.de/TR/1999/REC-ht … mit-format[/quote]
Ich kann da nichts derartiges herauslesen.

[quote]Das Attribut method des FORM-Elements gibt die HTTP-Methode an, die zur Übertragung des Formulars an das verarbeitende Programm verwendet wird. Dieses Attribut kann zwei Werte entgegennehmen:

get: Mit der HTTP-Methode »get« wird der Formulardatensatz an den URI gehängt, der durch das action-Attribut angegeben ist (mit einem Fragezeichen (»?«) als Trennzeichen) und dieser neue URI wird zu dem verarbeitenden Programm geschickt.
post: Mit der HTTP-Methode »post« wird der Formulardatensatz im Rumpf des Formulars eingeschlossen und zum verarbeitenden Programm geschickt.
[/quote]
Ich weiss nicht, wo du da herausliest, dass die Angabe eines URI mit einem nicht-leeren Querystring im action-Attribut bei POST irgendwie untersagt wäre.

[quote]Insofern kann es bei einem anständigen HTML-Dokument gar
nicht passieren, daß beides auftritt.[/quote]
Da erwartest du offenbar mehr “Anstand”, als die Spezifikation fordert.

[quote]Daß der Autor überhaupt selber eine ‘query’ an die URI anhängt,
ist an sich keine ganz saubere Sache, denn das ist eigentlich
das Problem des browsers, dies anzuhängen, wenn ein Formular
losgeschickt wird.[/quote]
Wieso soll das keine saubere Sache sein?

HTTP-URIs können einen Query-Part haben, und ich kann in der Spezifikation eines solchen keine Stelle entdecken, die vorschreiben würde, wer den “erstellen” dürfte.

[quote] Ist auch einer der Gründe, warum zumindest
früher die Roboter von Suchmaschinen damit recht zögerlich
umgingen, weil das signalisiert, daß das kein permanenter Inhalt
ist, der sich zu indexieren lohnt[/quote]
Das ist aber, wenn wir hier über method=post abgesendete Formulare reden, nicht von Belang.

[quote]Die PHP-Anleitungen sprechen deshalb in dem Zusammenhang
auch davon, daß eine GET-Anfrage vorgetäuscht wird.
Beispiel 3:
php.net/manual/de/faq.html.p … l.encoding[/quote]
Das ergibt m.E. weder in der deutschen Version noch im Original einen Sinn.

Links werden immer per GET angefordert - wie man da bei einem Beispiel-Link davon sprechen kann, dass damit ein GET-Request “gefaked” würde, erschliesst sich mir nicht.
(Abgesehen davon, hat eine lässige Formulierung im PHP-Manual bzgl. HTTP keinerlei normativen Charakter.)