Guten Morgen,

ich habe hier grade eine ganz prinzipielle Überlegung zum Thema PHP,
Formulare und dem "Reload-Problem".

Wenn ich ein HTML-Formular an ein PHP-Skript abschicke und dann im Browser
einen Reload mache, dann werden die Post-Daten normalerweise nochmal
abgeschickt und damit - soweit ich keine speziellen Vorkehrungen getroffen
habe - ein zweites mal z.B. in eine Datenbank eingetragen.

Ein Lösungsansatz für dieses Problem ist, nach der Auswertung der
POST-Daten einen HTTP-Redirect zu machen. Ich habe das hier mal
bespielhaft implementiert:

----------8<----------
<?

session_start();
if ( !array_key_exists('messages', $_SESSION) ) {
$_SESSION['messages'] = array();
}

// Aktion ausführen
if ( isset($_POST['feld']) ) {
// Ausführung der Aktion in Logfile schreiben
file_put_contents("log", "Verarbeitung: ".$_POST['feld']."\n", FILE_APPEND);
// Bestätigungsmeldung in Session zwischenspeichern
$_SESSION['messages'][] = "Verarbeitet: ".$_POST['feld'];
// Weiterleitung an die Seite ohne POST
header("Location: ".$_SERVER['PHP_SELF']);
exit;
}

// Meldungen ausgeben
foreach ( $_SESSION['messages'] as $message ) {
?>
<p><?=htmlspecialchars($message)?></p>
<?
}
$_SESSION['messages'] = array();

?>

<form action="<?=$_SERVER['PHP_SELF']?>" method="POST">
<input type="text" name="feld">
<input type="submit">
</form>
----------8<----------

Wenn man nun also nach dem Abschicken des Formulars einen Reload macht,
wird nur die ganz normale Seite neu geladen, ohne Post-Daten. Auch mit den
Back- und Forwardbuttons kann man den Aufruf mit den Post-Daten
anscheinend nicht mehr erreichen. Offensichtlich speichert der Browser nur
wirklich angezeigte Seiten in seiner History, keine Redirects.

Meine Frage ist nun: Ist das zuverlässig? Halten sich wirklich alle
Browser an diese Regel? Ist diese Regel vielleicht auch noch irgendwo
standardisiert? Oder gibt es da einen Haken?

Ich habe auch schon eine Ausnahme von der Regel entdeckt: Im Opera kann
man "Enable automatic redirection" abschalten. Ein Redirect erzeugt dann
im Browser eine Seite mit einem Link auf das Ziel des Redirects. Wenn man
auf dieser Seite nun einen Reload macht, dann werden die Post-Daten
jedesmal erneut abgeschickt.

Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

Magnus Rosenbaum schrieb:
> Guten Morgen,
>
> ich habe hier grade eine ganz prinzipielle =DCberlegung zum Thema PHP,
> Formulare und dem "Reload-Problem".
>
> Wenn ich ein HTML-Formular an ein PHP-Skript abschicke und dann im Brow=
ser
> einen Reload mache, dann werden die Post-Daten normalerweise nochmal
> abgeschickt und damit - soweit ich keine speziellen Vorkehrungen getrof=
fen
> habe - ein zweites mal z.B. in eine Datenbank eingetragen.
>
> Ein Lösungsansatz für dieses Problem ist, nach der Auswertung der
> POST-Daten einen HTTP-Redirect zu machen. Ich habe das hier mal
> bespielhaft implementiert:
>
> ----------8<----------
> <?
>
> session_start();
> if ( !array_key_exists('messages', $_SESSION) ) {
> $_SESSION['messages'] =3D array();
> }
>
> // Aktion ausführen
> if ( isset($_POST['feld']) ) {
> // Ausführung der Aktion in Logfile schreiben
> file_put_contents("log", "Verarbeitung: ".$_POST['feld']."\n", FILE_AP=
PEND);
> // Bestätigungsmeldung in Session zwischenspeichern
> $_SESSION['messages'][] =3D "Verarbeitet: ".$_POST['feld'];
> // Weiterleitung an die Seite ohne POST
> header("Location: ".$_SERVER['PHP_SELF']);

Ein Location Header hat eine vollstaendige URI zusein und nicht nur ein
Teil. Also http://example.com/path/script.php

Das was du hier beschrieben hast findet man auch unter
11.19. Wie verhindere ich mehrfaches Absenden eines Formulars?
http://www.php-faq.de/q/q-formular-mehrfach.html

wieder. Ein weitere Moeglichkeit ist der Einsatz einer Challenge oder
eines Tokkens.

25.1. Wie kann ich eine schummelsichere Abstimmung codieren?
http://www.php-faq.de/q/q-scripte-abstimmung.html

Gruss
Joerg

--
TakeNet GmbH, Geschaeftsfuehrer Wolfgang Meier
97080 Wuerzburg Tel: +49 931 903-2243
Alfred-Nobel-Straße 20 Fax: +49 931 903-3025
HRB Wuerzburg 6940 http://www.takenet.de

Joerg Behrens wrote:
> Ein Location Header hat eine vollstaendige URI zusein und nicht nur ein
> Teil. Also http://example.com/path/script.php

Ich weiß, aber besonders sinnvoll erscheint mir diese Regel irgendwie
nicht. Ist denn außer PHP selbst irgendein HTTP-Client bekannt, der mit
einem relativen Pfad hier nicht zurechtkommt? Oder gibt es dafür einen
sonstigen speziellen Grund? Mir ist der Sinn dieser Regel jedenfalls
bisher verschlossen geblieben.

Die Implementierung dieser Regel scheint ja auch gar nicht so einfach zu
sein. Am einfachsten wäre es wohl so:

header("Location: ".$_SERVER['SCRIPT_URI']);

Aber SCRIPT_URI ist nicht immer verfügbar, auf meinem lokalen Rechner hier
z.B. nicht. Keine Ahnung warum. Falls zumindest HTTP_HOST verfügbar ist,
könnte man es dann so machen:

$uri = "http";
if (isset($_SERVER['HTTPS']) and $_SERVER['HTTPS']=="on") $uri .= "s";
$uri .= "://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];
header("Location: ".$uri);

Wenn man aber nicht wieder auf die selbe URI weiterleiten will, sondern
auf eine andere, dann wird's wohl etwas schwieriger. Hier mein Versuch:

----------8<----------

// Alte URI
$uri = "http";
if (isset($_SERVER['HTTPS']) and $_SERVER['HTTPS']=="on") $uri .= "s";
$uri .= "://".$_SERVER['HTTP_HOST'].$_SERVER['REQUEST_URI'];

// Neue relative URI
$target = "../../info/example.php?param=1#anchor";

$target_uri = abs_uri($uri, $target);
header("Location: ".$target_uri);


/**
* Erzeugt einen kanonischen Pfad
*
* [at] param string $path Absolute oder relative Pfadangabe
* [at] return string
*/
function canonicalize_path($path) {
$elements = explode("/", $path);
$out = array();
foreach ($elements as $element) {
switch ($element) {
case "":
if ($out) continue 2;
break;
case ".":
continue 2;
case "..":
if ($out and $out[count($out)-1]!="..") {
array_pop($out);
continue 2;
}
}
array_push($out, $element);
}
return implode("/", $out);
}


/**
* Erzeugt aus einer relativen eine absolute URI
*
* [at] param string $baseuri Absolute Basis-URI
* [at] param string $relpath Relative Ziel-URI
* [at] return string
*/
function abs_uri($baseuri, $relpath) {

$parsed = parse_url($baseuri);

if ( substr($relpath, 0, 1)=="#" ) {
if (isset($parsed['fragment'])) {
$absuri = substr($baseuri, 0, (strlen($parsed['fragment']) + 1) * -1);
} else {
$absuri = $baseuri;
}
return $absuri.$relpath;
}

$hostpart = $parsed['scheme'].':';
if (isset($parsed['user'])) {
$hostpart .= $parsed['user'];
if (isset($parsed['pass'])) {
$hostpart .= ":".$parsed['pass'];
}
$hostpart .= " [at] ";
}
$hostpart .= $parsed['host'];
if (isset($parsed['port'])) $hostpart .= ":".$parsed['port'];

$basedir = dirname($parsed['path'])."/";
$abspath = canonicalize_path($basedir.$relpath);

return $hostpart.$abspath;
}

----------8<----------

> Das was du hier beschrieben hast findet man auch unter
> 11.19. Wie verhindere ich mehrfaches Absenden eines Formulars?
> http://www.php-faq.de/q/q-formular-mehrfach.html
> wieder.

Ja, danke. Meine Frage wird da aber leider auch nicht beantwortet.

> Ein weitere Moeglichkeit ist der Einsatz einer Challenge oder
> eines Tokkens.

Was ist das und wie kann man damit das Reload-Problem lösen? Ich habe
leider nichts dazu gefunden.

cu, Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

..oO(Magnus Rosenbaum)

>Joerg Behrens wrote:
>> Ein Location Header hat eine vollstaendige URI zusein und nicht nur ein
>> Teil. Also http://example.com/path/script.php
>
>Ich weiß, aber besonders sinnvoll erscheint mir diese Regel irgendwie
>nicht. Ist denn außer PHP selbst irgendein HTTP-Client bekannt, der mit
>einem relativen Pfad hier nicht zurechtkommt?

Lynx gibt immerhin eine Warnung aus. Darüberhinaus wurden vor einiger
Zeit auch mal Probleme berichtet, die durch relative URLs zusammen mit
einem Querystring im Location-Header verursacht wurden. Ich finde nur
leider die Msg-ID nicht mehr.

>Oder gibt es dafür einen
>sonstigen speziellen Grund? Mir ist der Sinn dieser Regel jedenfalls
>bisher verschlossen geblieben.

Die HTTP-Spezifikation erfordert es, das sollte Grund genug sein. Bei
einer relativen URL darf der Browser praktisch raten, wohin er geschickt
werden soll. Einfach zu sagen "dann nimm doch die Request-URL als
Grundlage" ist nicht zulässig, da es nirgends definiert ist. Obendrein
haben einige Browser auch gelegentlich Probleme, eine relative URL mit
Hilfe einer gegebenen Basis-URL korrekt und RFC-konform aufzulösen.

Micha

Michael Fesser wrote:
> Darüberhinaus wurden vor einiger Zeit auch mal Probleme berichtet, die
> durch relative URLs zusammen mit einem Querystring im Location-Header
> verursacht wurden. Ich finde nur leider die Msg-ID nicht mehr.

Ich habe danach gesucht, aber es schein schon sehr gut versteckt zu sein.

>> Oder gibt es dafür einen sonstigen speziellen Grund? Mir ist der Sinn
>> dieser Regel jedenfalls bisher verschlossen geblieben.
>
> Die HTTP-Spezifikation erfordert es, das sollte Grund genug sein.

Im Prinzip gebe ich Dir da schon recht. Aber man kann den Standard ja auch
mal hinterfragen, alleine schon um ihn besser zu verstehen.

Schau Dir mal die praktischen Auswirkungen an. Wenn hier in der
Newsgroup jemand darauf hingewiesen wird, die URL im Location Header
absolut zu machen, dann wird er es ziemlich wahrscheinlich so einbauen,
dass es nur zur Hälfte funktioniert.

Entweder er schreibt die absolute URL gleich hardcoded rein, dann gibt's
Probleme wenn das Skript mal auf einem anderen Server, in einem anderen
Verzeichnis oder in einer Testumgebung laufen soll, oder wenn der
Webserver über mehrere verschiedene Hostnamen erreichbar ist.

Oder er baut es aus den $_SERVER-Informationen zusammen, so wie ich das
versucht habe. Das ist dann so umständlich, dass man schon sehr gut
aufpassen und sich recht gut mit PHP auskennen muss, um keinen Bug
reinzubringen. In den Contributed Notes zu der Funktion realpath() sieht
man jede Menge solcher Versuche voller Fehler.

Die Wahrscheinlichkeit, dass bei der Implementierung der absoluten URL was
schief geht halte ich daher für sehr viel höher, als dass mal ein Client
mit der relativen URL nicht zurecht kommt. Ist halt die pragmatische
Sicht.

> Bei einer relativen URL darf der Browser praktisch raten, wohin er
> geschickt werden soll. Einfach zu sagen "dann nimm doch die Request-URL
> als Grundlage" ist nicht zulässig, da es nirgends definiert ist.

Gibt es noch andere Alternativen zwischen denen der Browser raten könnte,
welche gemeint sein könnte?

> Obendrein haben einige Browser auch gelegentlich Probleme, eine
> relative URL mit Hilfe einer gegebenen Basis-URL korrekt und
> RFC-konform aufzulösen.

Das gilt dann wohl aber für alle URL-Abgaben, nicht nur im Location
Header. Also müsste man nach diesem Argument _alle_ URLs absolut schreiben
und das kann wohl nicht die Lösung sein.

Übrigens habe ich noch was gefunden, das nahelegt, dass es doch nicht so
ganz klar ist mit dem Standard:
http://groups.google.com/group/de.comp.lang.php/browse_threa d/thread/135ce30f7f77ce1b/06348bacd3110f57#06348bacd3110f57
http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html#7 .2.1.2
http://cgi-spec.golux.com/cgi-120-00a.html#ISSUE-010
http://cgi-spec.golux.com/issues-120-detailed.html#ISSUE-010

cu, Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

..oO(Magnus Rosenbaum)

>Michael Fesser wrote:
>> Darüberhinaus wurden vor einiger Zeit auch mal Probleme berichtet, die
>> durch relative URLs zusammen mit einem Querystring im Location-Header
>> verursacht wurden. Ich finde nur leider die Msg-ID nicht mehr.
>
>Ich habe danach gesucht, aber es schein schon sehr gut versteckt zu sein.

Dito. Ich meine, es war in <dciwam/>, ist aber zu lange her. Ich hab's
leider nicht in meinem lokalen Archiv.

>>> Oder gibt es dafür einen sonstigen speziellen Grund? Mir ist der Sinn
>>> dieser Regel jedenfalls bisher verschlossen geblieben.
>>
>> Die HTTP-Spezifikation erfordert es, das sollte Grund genug sein.
>
>Im Prinzip gebe ich Dir da schon recht. Aber man kann den Standard ja auch
>mal hinterfragen, alleine schon um ihn besser zu verstehen.

Durchaus. Nur sollte man auch im Hinterkopf behalten, daß vom Standard
abweichendes Verhalten nicht immer implementiert sein muß. Viele Browser
und sonstige Benutzeragenten (z.B. Download-Manager oder Suchmaschinen)
akzeptieren natürlich auch relative URLs im Location-Header, aber sie
müssen es nicht.

Ein Standard mag einem persönlich unsinnig erscheinen, aber er ist nun
mal das Maß der Dinge und i.d.R. das, worauf man sich verlassen kann.
Alles, was vom Standard abweicht, ist "Betreten auf eigene Gefahr".

>Schau Dir mal die praktischen Auswirkungen an. Wenn hier in der
>Newsgroup jemand darauf hingewiesen wird, die URL im Location Header
>absolut zu machen, dann wird er es ziemlich wahrscheinlich so einbauen,
>dass es nur zur Hälfte funktioniert.

Kommt immer auf die Situation drauf an.

>Entweder er schreibt die absolute URL gleich hardcoded rein, dann gibt's
>Probleme wenn das Skript mal auf einem anderen Server, in einem anderen
>Verzeichnis oder in einer Testumgebung laufen soll, oder wenn der
>Webserver über mehrere verschiedene Hostnamen erreichbar ist.
>
>Oder er baut es aus den $_SERVER-Informationen zusammen, so wie ich das
>versucht habe. Das ist dann so umständlich, dass man schon sehr gut
>aufpassen und sich recht gut mit PHP auskennen muss, um keinen Bug
>reinzubringen. In den Contributed Notes zu der Funktion realpath() sieht
>man jede Menge solcher Versuche voller Fehler.

Ich hab mir Deine Funktionen angeschaut und finde sie eigentlich viel zu
kompliziert. Mal abgesehen davon, daß Dinge wie Benutzername und
Passwort in einer HTTP-URL ohnehin nicht zulässig sind. Aber ich würde
auch das Aufdröseln des Pfades dem Browser überlassen. Zugegeben, ganz
sicher bin ich mir in dieser Sache nicht und müßte den RFC genauer
studieren, ob das zulässig ist.

>Die Wahrscheinlichkeit, dass bei der Implementierung der absoluten URL was
>schief geht halte ich daher für sehr viel höher, als dass mal ein Client
>mit der relativen URL nicht zurecht kommt. Ist halt die pragmatische
>Sicht.

Akzeptiert.

>> Bei einer relativen URL darf der Browser praktisch raten, wohin er
>> geschickt werden soll. Einfach zu sagen "dann nimm doch die Request-URL
>> als Grundlage" ist nicht zulässig, da es nirgends definiert ist.
>
>Gibt es noch andere Alternativen zwischen denen der Browser raten könnte,
>welche gemeint sein könnte?

Berechtigte Frage. Aber wie gesagt - es ist nicht definiert, was der
Browser in solch einem Falle tun soll. Ähnlich verhält es sich z.B. mit
einem "mailto:" im "action"-Attribut eines Formulars - es mag in einigen
Fällen funktionieren, ist aber komplett neben jeglicher Spezifikation,
ergo unzuverlässig.

>> Obendrein haben einige Browser auch gelegentlich Probleme, eine
>> relative URL mit Hilfe einer gegebenen Basis-URL korrekt und
>> RFC-konform aufzulösen.
>
>Das gilt dann wohl aber für alle URL-Abgaben, nicht nur im Location
>Header.

Ja. Es gab z.b. Fälle, in denen leere URLs falsch aufgelöst wurden:
Anstatt sich direkt auf das aktuelle Dokument zu beziehen wie vom RFC
gefordert, wurde auf das Verzeichnis des aktuellen Dokuments aufgelöst.

>Also müsste man nach diesem Argument _alle_ URLs absolut schreiben
>und das kann wohl nicht die Lösung sein.
>
>Übrigens habe ich noch was gefunden, das nahelegt, dass es doch nicht so
>ganz klar ist mit dem Standard:
>http://groups.google.com/group/de.comp.lang.php/browse_thre ad/thread/135ce30f7f77ce1b/06348bacd3110f57#06348bacd3110f57
>http://cgi-spec.golux.com/draft-coar-cgi-v11-03-clean.html# 7.2.1.2
>http://cgi-spec.golux.com/cgi-120-00a.html#ISSUE-010
>http://cgi-spec.golux.com/issues-120-detailed.html#ISSUE-01 0

Naja, das bezieht sich alles auf CGI, nicht auf HTTP. Innerhalb von PHP
kannst Du auch <http://name:passwort [at] example.com> verwenden, obwohl das
per RFC explizit _nicht_ erlaubt ist - PHP wandelt aber die Logindaten
automatisch in entsprechende HTTP-Header um. Das sind also durchaus zwei
Paar Schuhe.

Micha

Michael Fesser wrote:
> Aber ich würde
> auch das Aufdröseln des Pfades dem Browser überlassen. Zugegeben, ganz
> sicher bin ich mir in dieser Sache nicht und müßte den RFC genauer
> studieren, ob das zulässig ist.

Die RFCs in Ehren, aber selbst wenn das zulässig wäre, dann halte ich die
Wahrscheinlichkeit, dass es trotzdem nicht überall funktioniert, immer
noch für höher, als bei den relativen URLs.

Standards sind sicher wichtig und notwendig und es wäre gut, wenn sich
mehr Leute an die Standards halten würden. Aber nachdem sich ziemlich
viele Sachen heutzutage leider nicht an die Standards halten, kommt man
leider nicht weit, wenn man sich selbst immer nur strikt an die Standards
hält. Nur weil man sich an die Standards hält muss es noch nicht auch in
der Praxis funktionieren.

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

Magnus Rosenbaum schrieb:

> Standards sind sicher wichtig und notwendig und es wäre gut, wenn sich
> mehr Leute an die Standards halten würden. Aber nachdem sich ziemlich
> viele Sachen heutzutage leider nicht an die Standards halten, kommt man
> leider nicht weit, wenn man sich selbst immer nur strikt an die Standards
> hält.

Genau diese Denkweise ist das Problem warum immer mehr Software
existiert die sich nicht um Standards schert.

> Nur weil man sich an die Standards hält muss es noch nicht auch in
> der Praxis funktionieren.

Die Wahrscheinlichkeit dessen ist aber um ein erhebliches Maß höher. Mal
ganz abgesehen von der ideologischen Herausforderung nicht alles wie
andere im 0815 Stil zu bauen.

Ein Standard zwingt ja keinen schlechtere Software zu bauen und läst
immer einen gewissen Spielraum. Sich da an schlechten Beispielen zu
orientieren ist kein guter persöhnlicher Standard.

MfG, Ulf

Magnus Rosenbaum:

> Die RFCs in Ehren, aber selbst wenn das zulässig wäre, dann halte ich
> die Wahrscheinlichkeit, dass es trotzdem nicht überall funktioniert,
> immer noch für höher, als bei den relativen URLs.

Warum auf "Wahrscheinlichkeit" bauen, wenn man es ohne größeren Aufwand
gleich Standardkonform machen kann? So groß ist die Ersparnis doch gar
nicht.

> Standards sind sicher wichtig und notwendig und es wäre gut, wenn sich
> mehr Leute an die Standards halten würden. Aber nachdem sich ziemlich
> viele Sachen heutzutage leider nicht an die Standards halten, kommt
> man leider nicht weit, wenn man sich selbst immer nur strikt an die
> Standards hält. Nur weil man sich an die Standards hält muss es noch
> nicht auch in der Praxis funktionieren.

Wenn Du Standards für wichtig und notwendig hältst und es gut wäre, wenn
sich mehr Leute an Standards halten würden und die Standards in der
Praxis funktionieren: Warum hältst Du dich nicht einfach an die
Standards?

Lies auch mal http://en.wikipedia.org/wiki/Robustness_Principle und
denke darüber nach.

--
Today is Setting Orange, the 73rd day of The Aftermath in the YOLD 3173

Ulf Kadner wrote:
> Magnus Rosenbaum schrieb:
>> Standards sind sicher wichtig und notwendig und es wäre gut, wenn
>> sich mehr Leute an die Standards halten würden. Aber nachdem sich
>> ziemlich viele Sachen heutzutage leider nicht an die Standards
>> halten, kommt man leider nicht weit, wenn man sich selbst immer nur
>> strikt an die Standards hält.
>
> Genau diese Denkweise ist das Problem warum immer mehr Software
> existiert die sich nicht um Standards schert.

Ja, richtig. Aber zumindest beruflich sehe ich dazu keine Alternative. Die
Kunden interessieren sich nämlich in der Regel nicht im geringsten für
irgendwelche Standards. Wenn etwas bei 80% der User funktioniert, wird das
als ausreichend angesehen. Meine regelmäßigen Einwände, dass man mit einer
Einhaltung der Standards nahezu 100% erreichen könnte, interessieren
niemanden. Also komme ich hier um einen Kompromiss nicht herum.

>> Nur weil man sich an die Standards hält muss es noch nicht auch in
>> der Praxis funktionieren.
>
> Die Wahrscheinlichkeit dessen ist aber um ein erhebliches Maß höher.

Ja, sicher, in fast allen Fällen funktioniert es, wenn man sich an die
Standards hält. Aber eben leider nicht wirklich immer.

Das beste Beispiel ist ja HTML/CSS. Wenn man sich da komplett an die
Standards hält, funktioniert einiges je nach Browser nicht so ganz wie
erwartet. Was mich persönlich so nervt, dass ich mich inzwischen mehr auf
das Backend konzentriere und andere Leute die HTML/CSS-Sachen machen lasse.

> Mal ganz abgesehen von der ideologischen Herausforderung nicht alles
> wie andere im 0815 Stil zu bauen.

Was meinst Du?

cu, Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

Christoph Jeschke wrote:
> Warum auf "Wahrscheinlichkeit" bauen, wenn man es ohne größeren Aufwand
> gleich Standardkonform machen kann? So groß ist die Ersparnis doch gar
> nicht.

In den allermeisten Fällen würde ich das auch so sagen, aber in diesem
Fall (relative URLs im Location Header) ist die standardkonforme Umsetzung
eben doch mit größerem Aufwand und mehr Fehlerquellen verbunden.

> Wenn Du Standards für wichtig und notwendig hältst und es gut wäre, wenn
> sich mehr Leute an Standards halten würden und die Standards in der
> Praxis funktionieren: Warum hältst Du dich nicht einfach an die
> Standards?

Ich gehe davon aus, dass dieser Standard in der Praxis eben nicht so ganz
funktioniert.

Außerdem drängt sich bei mir so langsam der Eindruck auf, dass diese Regel
(absolute URLs im Location Header) eher unabsichtlich zustande gekommen
ist. Vielleicht hat damals noch keiner daran gedacht, dass man diesen
Header in CGI Skripten für die Formularverarbeitung verwenden könnte. Bei
in Webservern fest eingetragenen Redirects stören die absoluten URLs ja
auch weniger. In der nächsten Version von HTTP könnte man das ja mal
korrigieren.

cu, Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

Magnus Rosenbaum schrieb:

> Wenn etwas bei 80% der User funktioniert, wird das
> als ausreichend angesehen.

Solche Webseiten kenne ich auch zur Genüge. Die meisten davon
funktionieren ausschließlich mit dem MSIE richtig. Damit hat man schon
mal alle Unix/Linux-User von vornherein ausgeschlossen.

Eine solche Webseite besuche ich genau einmal und nie wieder.

Gruß. Claus

Magnus Rosenbaum schrieb:

> Christoph Jeschke wrote:
>
>> Warum auf "Wahrscheinlichkeit" bauen, wenn man es ohne größeren Aufwand
>> gleich Standardkonform machen kann? So groß ist die Ersparnis doch gar
>> nicht.
>
> In den allermeisten Fällen würde ich das auch so sagen, aber in diesem
> Fall (relative URLs im Location Header) ist die standardkonforme Umsetzung
> eben doch mit größerem Aufwand und mehr Fehlerquellen verbunden.

Der "größere Aufwand" besteht darin, sich _einmal_ eine Funktion zu
basteln, die aus einer relativen URL die entsprechende absolute
zusammenbaut, und dann konsequent diese Funktion zu benutzen. Somit gibt
es genau _eine_ Fehlerquelle, nämlich diese Funktion.

>> Wenn Du Standards für wichtig und notwendig hältst und es gut wäre, wenn
>> sich mehr Leute an Standards halten würden und die Standards in der
>> Praxis funktionieren: Warum hältst Du dich nicht einfach an die
>> Standards?
>
> Ich gehe davon aus, dass dieser Standard in der Praxis eben nicht so ganz
> funktioniert.

Kein Standard funktioniert in der Praxis hundertprozentig, proprietäre
Lösungen jedoch noch viel seltener.

> Außerdem drängt sich bei mir so langsam der Eindruck auf, dass diese Regel
> (absolute URLs im Location Header) eher unabsichtlich zustande gekommen
> ist.

Aber sie existiert nun mal.

Gruß. Claus

Magnus Rosenbaum:

> Ja, richtig. Aber zumindest beruflich sehe ich dazu keine Alternative.
> Die Kunden interessieren sich nämlich in der Regel nicht im geringsten
> für irgendwelche Standards. Wenn etwas bei 80% der User funktioniert,
> wird das als ausreichend angesehen. Meine regelmäßigen Einwände, dass
> man mit einer Einhaltung der Standards nahezu 100% erreichen könnte,
> interessieren niemanden. Also komme ich hier um einen Kompromiss nicht
> herum.

Inwiefern tangiert es deine Auftraggeber, ob Du Locations korrekt
absolut oder unkorrekt relativ angibst? Es kostet ja nicht mal mehr
Zeit, sondern spart langfristig Debugging-Aufwand.

> Ja, sicher, in fast allen Fällen funktioniert es, wenn man sich an die
> Standards hält. Aber eben leider nicht wirklich immer.

Inwiefern funktionieren denn absolute Weiterleitungen schlechter als
relative?

> Das beste Beispiel ist ja HTML/CSS. Wenn man sich da komplett an die
> Standards hält, funktioniert einiges je nach Browser nicht so ganz wie
> erwartet.

Das könnte daran liegen, dass es immermal wieder Stimmen gibt, die
Standards zwar für ganz nett halten, aber dann doch wider besseren
Wissens ignorieren.

--
Today is Sweetmorn, the 1st day of Chaos in the YOLD 3174

Magnus Rosenbaum meinte:

> Das beste Beispiel ist ja HTML/CSS. Wenn man sich da komplett an die
> Standards hält, funktioniert einiges je nach Browser nicht so ganz wie
> erwartet.

Aso. Und wenn man Standards ignoriert läuft alles ganz toll
cross-browser? Man kann problemlos standardkonforme Webseiten basteln,
die nicht nach 08/15 ausschauen. Aber ein bisserl beschäftigen muss man
sich schon mit HTML/CSS.

Nebenbei: Was hat diese "Argument" mit deiner Header-Location-URI zu tun?

Und: Es gibt mittlerweile genug Kunden die Standardkonformität fordern -
vielleicht wissen sie nicht warum, aber man kann auch als Auftragnehmer
damit bequem verhindern, dass der Kunde fehlerhafte Anzeigen im Browser
XY, der Version soundso auf OS demunddem reklamiert.

Gregor



--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Magnus Rosenbaum meinte:

> In den allermeisten Fällen würde ich das auch so sagen, aber in diesem
> Fall (relative URLs im Location Header) ist die standardkonforme Umsetzung
> eben doch mit größerem Aufwand und mehr Fehlerquellen verbunden.

Was du als "Aufwand" ansiehst...
Wo du Fehlerquellen ortest...

Wenn *das* schon Aufwand ist und Fehlerquelle sein kann, würde ich
einfach die Finger vom Programmieren von Webapplikationen lassen.


Gregor


--
http://www.gregorkofler.at ::: Landschafts- und Reisefotografie
http://www.licht-blick.at ::: Forum für Multivisionsvorträge
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Gregor Kofler wrote:
> Wenn *das* schon Aufwand ist und Fehlerquelle sein kann, würde ich
> einfach die Finger vom Programmieren von Webapplikationen lassen.

Bei den Fehlerquellen bezog ich mich auf Leute, die von PHP nur wenig bis
halbwegs Ahnung haben.

Ich habe bis jetzt noch keine fehlerfreie Implementation gesehen. Mein
Vorschlag oben war auch nicht fehlerfrei. Zeigt doch bitte mal eure
Implementationen her, vielleicht finden wir dann noch einen besseren Weg
als meinen Versuch :-)

cu, Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

Gregor Kofler wrote:
> Man kann problemlos standardkonforme Webseiten basteln, die nicht nach
> 08/15 ausschauen. Aber ein bisserl beschäftigen muss man sich schon mit
> HTML/CSS.

Ich arbeite bei einem Projekt mit einer HTML/CSS-Designerin zusammen, die
auch einmal den Biene-Award gewonnen hat. Und die verwendet auch solche
Hacks wie wid\th= und ähnliches.

> Nebenbei: Was hat diese "Argument" mit deiner Header-Location-URI zu
> tun?

Inzwischen sind wir leider zur Diskussion über Standards im Allgemeinen
abgedriftet. *gähn*

Meine ursprüngliche Frage war ja, ob diese Methode, das nochmalige
Abschicken von Formulardaten zu verhindern, irgendwie standardisiert ist,
oder ob sich das nur mehr oder weniger zufällig so eingebürgert hat. Aber
hier kennt anscheinend niemand einen zugrundeliegenden Standard :-(

cu, Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

Magnus Rosenbaum meinte:

> Ich habe bis jetzt noch keine fehlerfreie Implementation gesehen.

Was gibt es da zu "implementieren"? Es braucht eine absolute URI -
fertig. Meine Lösung um an aus einem

> Mein Vorschlag oben war auch nicht fehlerfrei.

Ja, weil ein relativer Pfad.

> Zeigt doch bitte mal eure
> Implementationen her, vielleicht finden wir dann noch einen besseren Weg
> als meinen Versuch :-)

Seufz...

header(
'Location: http://'.
$_SERVER['HTTP_HOST'].
rtrim(SUBDIR, /').'/'.
$destPage);
exit;

SUBDIR ist eine Konstante, die typischerweise '' ist.

Das Problem ist ausschließlich, ob HTTP_HOST belegt ist. Zumindest auf
dem Indianer und dem IIS ist es belegt.

Gregor


--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Magnus Rosenbaum meinte:
> Gregor Kofler wrote:
>> Man kann problemlos standardkonforme Webseiten basteln, die nicht nach
>> 08/15 ausschauen. Aber ein bisserl beschäftigen muss man sich schon mit
>> HTML/CSS.
>
> Ich arbeite bei einem Projekt mit einer HTML/CSS-Designerin zusammen, die
> auch einmal den Biene-Award gewonnen hat. Und die verwendet auch solche
> Hacks wie wid\th= und ähnliches.

Verrät das was über den Award, oder die Qualitäten des Preisträgers?

Über die Sinnhaftigkeit und den Gehalt solcher "Awards" lässt sich wohl
trefflich streiten:
Einer der letzten Preisträger ist pfizer, der kommt ohne solche Hacks
aus. Mal abgesehen, vom hausbackenen Erscheinungsbild, kann ich auch
sonst wenig Sensationelles entdecken. Offensichtlich reichen
Standardkonformität, Tabellenfreiheit und 'em' statt 'px' schon für so
einen Award.

> Meine ursprüngliche Frage war ja, ob diese Methode, das nochmalige
> Abschicken von Formulardaten zu verhindern, irgendwie standardisiert ist,
> oder ob sich das nur mehr oder weniger zufällig so eingebürgert hat. Aber
> hier kennt anscheinend niemand einen zugrundeliegenden Standard :-(

Natürlich gibt es Standards dazu. Etwa:

RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
http://www.faqs.org/rfcs/rfc2616
Abschnitt 14.30

Und POST-Daten sind natürlich nicht mehr vorhanden, da die ja explizit
im Header mitgeliefert werden müssen. Welchen Browser du hast ist dabei
blunznwurscht, weil der Redirect am Server erfolgt.

Zufrieden jetzt?

Gregor



--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Gregor Kofler wrote:
> Was gibt es da zu "implementieren"? Es braucht eine absolute URI -
> fertig.

Dass eine absolute URL in einem Skript hardcoded nichts verloren hat ist
aber schon klar, oder?

> Seufz...

Och, Du Armer ;-)

> header(
> 'Location: http://'.
> $_SERVER['HTTP_HOST'].
> rtrim(SUBDIR, /').'/'.

Hier fehlt ein Singlequote.

> $destPage);
> exit;

Wenn Du dann ein Verzeichnis höher springen willst, hast Du wieder einen
Pfad mit /../ drin. Das hatten wir oben schon diskutiert.

> SUBDIR ist eine Konstante, die typischerweise '' ist.

Muss dann wohl so sein:

define('SUBDIR', dirname($_SERVER['PHP_SELF']));

Den "typischen" leeren String ergibt das aber in keinem Fall. Also was
schreibst Du in das SUBDIR?

cu, Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641

Magnus Rosenbaum meinte:

>> header(
>> 'Location: http://'.
>> $_SERVER['HTTP_HOST'].
>> rtrim(SUBDIR, /').'/'.
>
> Hier fehlt ein Singlequote.

Sorry, doch kein echtes Cut'n'Paste.

>> $destPage);
>> exit;
>
> Wenn Du dann ein Verzeichnis höher springen willst, hast Du wieder einen
> Pfad mit /../ drin. Das hatten wir oben schon diskutiert.

Warum?

Im Original schaut das so aus:
protected function redirect($destPage = '') {
header('Location: http://'.$_SERVER['HTTP_HOST'].rtrim(SUBDIR,
'/').'/'.$destPage);
exit;
}

Der Aufruf mit $this->redirect('meinunterverzeichnis/zielseite.php');
Da braucht's keine '..', weil immer vom Root ausgegangen wird. Nachdem
die Seite aber ohnedies vollkommen "dynamisch generiert" wird, reicht
immer sowas wie $this->redirect('?page=ziel');

>> SUBDIR ist eine Konstante, die typischerweise '' ist.
>
> Muss dann wohl so sein:
>
> define('SUBDIR', dirname($_SERVER['PHP_SELF']));
>
> Den "typischen" leeren String ergibt das aber in keinem Fall. Also was
> schreibst Du in das SUBDIR?

SUBDIR wird gelegentlich am localhost belegt, da Projekte in Unterordner
liegen und nicht unbedingt eine Subdomain verpasst kriegen. Im
Produktivbetrieb ist das immer ''.

Gregor


--
http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
http://web.gregorkofler.com ::: meine JS-Spielwiese
http://www.image2d.com ::: Bildagentur für den alpinen Raum

Magnus Rosenbaum schrieb:

> Ich habe bis jetzt noch keine fehlerfreie Implementation gesehen. Mein
> Vorschlag oben war auch nicht fehlerfrei. Zeigt doch bitte mal eure
> Implementationen her, vielleicht finden wir dann noch einen besseren Weg
> als meinen Versuch :-)

function redirect($file) {

// Hostname bestimmen

$host = $_SERVER['HTTP_HOST'];

// Absoluten Verzeichnispfad ermitteln

if (substr($file, 0, 1) == '/') {
$dir = '';
$file = substr($file, 1);
} else {
$dir = dirname($_SERVER['PHP_SELF']);
while (substr($file, 0, 3) == '../') {
$dir = dirname($dir);
$file = substr($file, 3);
}
if ($dir == '/')
$dir = '';
else
$dir = "$dir/";
}

// URL zusammenbauen

$url = "http://$host$dir$file";

// Weiterleitung durchführen

header("Location: $url");
exit;
}

Gruß. Claus

Gregor Kofler wrote:
> Verrät das was über den Award, oder die Qualitäten des Preisträgers?

Dazu müsste man wohl mal genauer hinschauen.

> Über die Sinnhaftigkeit und den Gehalt solcher "Awards" lässt sich wohl
> trefflich streiten:
> Einer der letzten Preisträger ist pfizer, der kommt ohne solche Hacks
> aus. Mal abgesehen, vom hausbackenen Erscheinungsbild, kann ich auch
> sonst wenig Sensationelles entdecken. Offensichtlich reichen
> Standardkonformität, Tabellenfreiheit und 'em' statt 'px' schon für so
> einen Award.

Ja, um Standardkonformität ging es ja gerade, nicht um Sensationen :-]

> Natürlich gibt es Standards dazu. Etwa:
>
> RFC 2616 - Hypertext Transfer Protocol -- HTTP/1.1
> http://www.faqs.org/rfcs/rfc2616
> Abschnitt 14.30

---8<---
14.30 Location

The Location response-header field is used to redirect the recipient
to a location other than the Request-URI for completion of the
request or identification of a new resource. For 201 (Created)
responses, the Location is that of the new resource which was created
by the request. For 3xx responses, the location SHOULD indicate the
server's preferred URI for automatic redirection to the resource. The
field value consists of a single absolute URI.

Location = "Location" ":" absoluteURI

An example is:

Location: http://www.w3.org/pub/WWW/People.html

Note: The Content-Location header field (section 14.14) differs
from Location in that the Content-Location identifies the original
location of the entity enclosed in the request. It is therefore
possible for a response to contain header fields for both Location
and Content-Location. Also see section 13.10 for cache
requirements of some methods.
---8<---

Da steht was ein Redirect ist. Aber dass die Anfrage, die den Redirect
ergab, nicht noch einmal an den Server geschickt werden darf, außer wenn
das Formular explizit nochmal abgeschickt wird, steht da nicht.

> Und POST-Daten sind natürlich nicht mehr vorhanden, da die ja explizit
> im Header mitgeliefert werden müssen.

Aber sie könnten ja trotzdem später nochmal vom Browser geschickt werden.
Die Browser speichern ja auch abgeschickte POST-Daten in ihrer History.

> Welchen Browser du hast ist dabei blunznwurscht, weil der Redirect am Server erfolgt.

Wenn der Redirect am Server erfolgen würde, dann würde mein Opera ihn ja
nicht unterbinden können. Siehe mein Ursprungsposting, letzter Absatz.

HTTP Live Headers im Firefox zeigt auch, dass der Browser den Redirect
ausführt:

----------------------------------------------------------
http://localhost/phpkonzepte/location/form.php

POST /phpkonzepte/location/form.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; de; rv:1.8.1.11)
Gecko/20071205 Firefox/2.0.0.11
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0 .9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost/phpkonzepte/location/form.php
Cookie: PHPSESSID=304dc2a8ee999ac6c607c031fe4db9e2
Authorization: Basic bWFnbnVtOmNhZWRlcw==
Content-Type: application/x-www-form-urlencoded
Content-Length: 9
feld=test
HTTP/1.x 302 Found
Date: Wed, 02 Jan 2008 14:16:02 GMT
Server: Apache
X-Powered-By: PHP/5.2.5-pl1-gentoo
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Location: http://localhost/phpkonzepte/location/form.php
Content-Length: 0
Keep-Alive: timeout=15, max=98
Connection: Keep-Alive
Content-Type: text/html
----------------------------------------------------------
http://localhost/phpkonzepte/location/form.php

GET /phpkonzepte/location/form.php HTTP/1.1
Host: localhost
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; de; rv:1.8.1.11)
Gecko/20071205 Firefox/2.0.0.11
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0 .9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de-de,de;q=0.7,en;q=0.3
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://localhost/phpkonzepte/location/form.php
Cookie: PHPSESSID=304dc2a8ee999ac6c607c031fe4db9e2
Authorization: Basic bWFnbnVtOmNhZWRlcw==

HTTP/1.x 200 OK
Date: Wed, 02 Jan 2008 14:16:02 GMT
Server: Apache
X-Powered-By: PHP/5.2.5-pl1-gentoo
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Length: 149
Keep-Alive: timeout=15, max=97
Connection: Keep-Alive
Content-Type: text/html
----------------------------------------------------------

> Zufrieden jetzt?

Erst wenn ich schlauer bin als vorher :-)

cu, Magnus

--
Carl Magnus Rosenbaum M.A.
Administration - Programmierung - Weiterbildung http://cmr.cx/
Tel: +49 89 70066626 Fax: +49 89 70066686 Mobil: +49 163 7006662
PGP Fingerprint: DEBC 3C99 EF1D 74F0 D4C7 EFF5 C268 3690 0EA1 7641