Problem mit isset auf verschiedenen Webservern

[Oliver Gierke]

Hallo zusammen,

ich bin auf ein komisches Problem gestoßen. Eine PHP-Anwendung auf eine Webserver lieferte mir immer einen Fehler. Ich habe jetzt ein wenig im COde gewühlt und festgestellt, dass die Anwendung aus dem Querystring einen Wert holt, bzw erst testet ob der wert überhaupt gesetzt ist:

isset($_GET['menuaction']));

auf dem externen Webserver funktioniert das für urls wie:

index.php?menuaction=bla&b=5&c=6

das erwartete ergebnis 'true'. Die Webanwendung erzeugt allerdings auch urls wie

index.php?menuaction=bla&b=5&c= (also schlüssel ohne werte hintendran)

bei dier art urls liefert der webserver für das "isset" false, mein lokale xampp installation allerdings korrekterweise "true"

gibts da ne php.ini einstellung?

 

[Dr Dau]

Hallo!

Warum sollte das Script kein false liefern?
Schliesslich erwartet es ja hinter &c= eine Variable, die fehlt aber, also liefert es korrekterweise ein false.
Mit andern Worten, die URL wird unvollständig übergeben.
Dass es unter XAMPP läuft, kann ich mir nur so erklären dass es unter Windows läuft, der Webserver läuft aber sicherlich unter Linux.
Du solltest dein Script also dahingehend überprüfen, dass es auch wirklich nur das übergibt was es übergeben soll.

PS: Bitte mehr auf den Punkt 12 in der Netiquette achten.

Gruss Dr Dau

 

[Oliver Gierke]

nein nein, du hast mich falsch verstanden...

ich teste IMMER mit

isset($_GET['menuaction'])

das Problem ist, (wie ich gestern noch herrausbekommen habe), dass überhaupt keine GET-Variablen ankommen, sobald beim letzten schlüssel/wert paar der wert fehlt.

Ein bekannter meinte, das liegt an nem Bug in PHP 4.3.3 ... jetzt hab ich 4.3.11 installiert... gleiches ergebnis...

wer es testen mag:

http://www.ecratum.de/develop/index.php?menuaction=bla&b=bla (funktioniert)
http://www.ecratum.de/develop/index.php?menuaction=bla&b= (funktioniert nicht)

der (sinnlose) Debugcode lautet

<? echo(isset($_GET['menuaction'])); ?>
<br />
<?print_r($_REQUEST); ?>

Danke Ollie

PS: es handelt sich bei der Software um eGroupware 1.0.0.8 ;-)

 

[Oliver Gierke]

war wohl laut strato ein Bug in suPHP 0.5 ...

Problem gelöst


Trotzdem danke ;-)

REINHAUN!