[PHP] header("Location: ") redirect niet

[Pelle]

Ik loop nu net tegen iets heel raars aan. Voor een inlog-procedure heb ik een scriptje geschreven en dat in login.php gestopt.
Daarin worden een aantal session variabelen gevuld, en daarna sluit ik het login-script af met deze code:

PHP:

<?
header("Location: $HTTP_REFERER");
?>

..zodat de user weer terug gaat naar de pagina waar hij vandaan kwam. Dit werkt goed (zowel lokaal als op onze eigen webserver), maar deze site staat gehost bij Vuurwerk, en die denkt daar anders over.

Stel dat ik op de pagina index.php?page=3 zit, en dan inlog, dan kom ik -zoals het hoort- weer op index.php?page=3 uit. Maar doe ik dit bij Vuurwerk, dan kom ik op login.php?page=3 uit.
De content van de pagina is wel de content die index.php zou moeten genereren, maar de locatie in de url-balk is dus niet vervangen door index.php.

Ik heb gekeken wat php.net hierover kon vertellen, maar daar stond er niks over vermeld. Ik vermoed dat het óf aan de webserver van Vuurwerk ligt, of aan de manier waarop PHP-files daar geparsed worden (via een cgi-script in plaats van via een PHP-module).

Is er een manier om dit op te lossen? Want het geeft de nodig problemen als gebruikers uit willen loggen of de pagina vernieuwen, aangezien er dan gerefreshed wordt op een pagina die de verkeerde URL in de location-bar heeft staan en er dus een verkeerde pagina vernieuwd wordt.

[D2k]

print eerst die $HTTP_REFERRER eens af?

[SchizoDuckie]

PHP:

<?
echo ("<script language='javascript'>document.location='$http_referer'; </script>");
?>

zo pak ik dat altijd aan na het zetten van een koekje

[Pelle]

Op donderdag 07 februari 2002 23:01 schreef D2k het volgende:
print eerst die $HTTP_REFERRER eens af?

Nee, daar ligt het niet aan. Ook als ik de location er hard in zet, gaat het fout:

PHP:

<?
header("Location: blaat.php");
?>

.. geeft nog als resultaat dat er na het inloggen login.php in de adresbalk staat, maar dan met de content van blaat.php.
En als ik dat reload, dan reload ik dus login.php en niet blaat.php, en dat is niet iets wat je user verwacht, en ook iets waar ik dus niet blij mee ben

[Verwijderd]

is dit niet gewoon weer zo'n wnserver van vuurwerk-probleem ?

[Verwijderd]

Ik weeeeeet wat het is

doe eens

header("location: " . $HTTP_REFERER);

Gegarandeerd dat het werkt

[Pelle]

Op donderdag 07 februari 2002 23:24 schreef xtentic het volgende:
Ik weeeeeet wat het is

doe eens

header("location: " . $HTTP_REFERER);

Gegarandeerd dat het werkt

Nee, zoals ik al zei: het ligt niet aan de HTTP_REFERER. Het lijkt er op of er een include van de file die in de header genoemt wordt plaatsvind, in plaats van een redirect er naartoe.

[Orphix]

Op donderdag 07 februari 2002 23:29 schreef Pelle het volgende:
Nee, zoals ik al zei: het ligt niet aan de HTTP_REFERER. Het lijkt er op of er een include van de file die in de header genoemt wordt plaatsvind, in plaats van een redirect er naartoe.

Klopt, ik heb er zelf nooit last van gehad, maar ik heb ooit eens ergens gelezen dat sommige webservers een location: header niet terugsturen, maar direct het nieuwe bestand opvragen (indien op eigen domein). Logisch natuurlijk, lekker snel, ware het niet dat de client dit dan niet doorheeft...
Ik zie zo snel ook niet een andere oplossing dan de al eerder gebrachte java-script oplossing.

[Verwijderd]

Heb er zelf ook last van.. Bij m'n linux pc werkt het goed, maar zodra ik 'm op 'n windows 2000 server zet (met php ondersteuning) werkt het niet.. 'Headers not send' ofzoiets..

[Pelle]

Op donderdag 07 februari 2002 23:33 schreef Orphix het volgende:
Klopt, ik heb er zelf nooit last van gehad, maar ik heb ooit eens ergens gelezen dat sommige webservers een location: header niet terugsturen, maar direct het nieuwe bestand opvragen (indien op eigen domein). Logisch natuurlijk, lekker snel, ware het niet dat de client dit dan niet doorheeft...

Grmbl.. wanneer stappen ze daar bij Vuurwerk eens over op Apache zeg. Wellicht dat die huidige server ontzettend veilig en misschien ook wel sneller is, maar als dit soort dingen voor je geregeld worden, en je ook bijvoorbeeld voor elke php-file die je nodig hebt dingen aan je index(.cache) toe moet gaan voegen, dan heb ik het al snel gezien

Ik zie zo snel ook niet een andere oplossing dan de al eerder gebrachte java-script oplossing.

Had ik zelf ook al aan gedacht als nood-oplossing, maar echt mooi is het niet natuurlijk. Nah ja, het zei zo.

[man-o-script]

ze hebben ook apache servers bij vuurwerk,
moet je er gewoon om vragen

bel dan het gewone nummer (niet de helpdesk want weten/kunnen nix)
en vraag naar wilco noordermeer,
die is van beheer, die helpt je wel verder dan

[Pelle]

Op vrijdag 08 februari 2002 01:27 schreef man-o-script het volgende:
ze hebben ook apache servers bij vuurwerk,
moet je er gewoon om vragen

bel dan het gewone nummer (niet de helpdesk want weten/kunnen nix)
en vraag naar wilco noordermeer,
die is van beheer, die helpt je wel verder dan

Hehe, bedankt voor de tip
Maar ik denk niet dat ik dat kan maken; ik ben namelijk niet de enige die van dat domein gebruik maakt, laat staan degene die de facturen voor dat domein betaalt, dus ik ga me geen dingen op m'n hals halen die wel eens voor problemen zouden kunnen zorgen.

[HGM]

alternatieve oplossing is misschien om aan het inlogscript de URL meegeven waarnaartoe er teruggeredirect moet worden??

[Pelle]

Op vrijdag 08 februari 2002 07:06 schreef HGM het volgende:
alternatieve oplossing is misschien om aan het inlogscript de URL meegeven waarnaartoe er teruggeredirect moet worden??

* Pelle legt het nog één keer uit

Het ligt niet aan waarnaartoe er geredirect moet worden, en hoe dat wordt bepaald door het script, maar de manier waarop het gebeurt: er lijkt een include plaats te vinden in plaats van een redirect.

* Pelle denkt trouwens dat HGM veel te vroeg opstaat

[HGM]

Op vrijdag 08 februari 2002 08:44 schreef Pelle het volgende:

[..]

* Pelle legt het nog één keer uit

Heel fijn

Het ligt niet aan waarnaartoe er geredirect moet worden, en hoe dat wordt bepaald door het script, maar de manier waarop het gebeurt: er lijkt een include plaats te vinden in plaats van een redirect.

Je hoeft niet alleen te redirecten dmv de Location, een javascript redirectje is toch ook goed?
Ik begreep dat de $HTTP_REFERRER ook niet goed doorkwam, dus als je dat als variabele meegeeft naar de inlog.php, dan kan je mooi redirecten, toch??

* Pelle denkt trouwens dat HGM veel te vroeg opstaat

Tja, stage enzo he , als je beetje vroeg naar huis wil

[Pelle]

Op vrijdag 08 februari 2002 08:47 schreef HGM het volgende:
Je hoeft niet alleen te redirecten dmv de Location, een javascript redirectje is toch ook goed?

Mijn motto: nooit dingen clientside oplossen als het ook serverside kan

Ik begreep dat de $HTTP_REFERRER ook niet goed doorkwam,

Waaruit begreep je dat dan?

dus als je dat als variabele meegeeft naar de inlog.php, dan kan je mooi redirecten, toch??

Ja gaat ook wel lukken hoor, met een JS. Nood breekt wet...

Tja, stage enzo he , als je beetje vroeg naar huis wil

* Pelle verkiest uitslapen en laat naar huis altijd boven vroeg op en vroeg weg

[HGM]

Mijn motto: nooit dingen clientside oplossen als het ook serverside kan

Tja, maar motto's zijn er om gebroken te worden

Waaruit begreep je dat dan?

Uit het feit dat ik (blijkbaar) niet goed gelezen had.

Ja gaat ook wel lukken hoor, met een JS. Nood breekt wet...

Mooi dan

* Pelle verkiest uitslapen en laat naar huis altijd boven vroeg op en vroeg weg

Kan ook (ook een Pelle motto zeker )

[MisterData]

En moet er geen \n achter ?? Dus zo :

PHP:

<?
header("Location:".$HTTP_REFERER."\n");
?>

Dit probleem had ik een paar dagen geleden ook

[Verwijderd]

Op vrijdag 08 februari 2002 11:30 schreef MisterData het volgende:
En moet er geen \n achter ?? Dus zo :

PHP:

<?
header("Location:".$HTTP_REFERER."\n");
?>

Dit probleem had ik een paar dagen geleden ook

Dat hoeft het niet te zijn hoor. Als je het bijv. in een functie hebt moet je niet vergeten om 'm eerst even te globallen:

global $HTTP_REFERER

[Petuhr]

Op vrijdag 08 februari 2002 01:27 schreef man-o-script het volgende:
ze hebben ook apache servers bij vuurwerk,
moet je er gewoon om vragen

bel dan het gewone nummer (niet de helpdesk want weten/kunnen nix)
en vraag naar wilco noordermeer,
die is van beheer, die helpt je wel verder dan

Wil nix zeggen hoor, maar wilco is geen beheer

[Pelle]

Op vrijdag 08 februari 2002 12:42 schreef Boer_Frients het volgende:
Dat hoeft het niet te zijn hoor. Als je het bijv. in een functie hebt moet je niet vergeten om 'm eerst even te globallen:

global $HTTP_REFERER

* Pelle denkt dat een hoop mensen niet écht lezen wat er nou staat

Het probleem is niet de referer, maar het feit dat er een include in plaats van een redirect lijkt plaats te vinden. De juiste pagina wordt geladen, maar dan met login.php in de adres-balk (zodat het lijkt of login.php die code heeft gegenereerd, terwijl dat niet zo is aangezien login.php alleen maar redirect).

[Verwijderd]

/me denkt dat pelle te veel denkt, probeer het eens op een andere manier of laat eens wat meer code zien ... indien het geen probleem is van de server kant moet je toch eens gaan kijken of de fout in je eigen source verwerkt zit

[Verwijderd]

Op donderdag 07 februari 2002 23:29 schreef Pelle het volgende:

[Een verhaaltje van Xtentic dat hij een punt(.) voor HTTP_REFERER moet zetten en dat hij garandeert dat het dan werkt]

Nee, zoals ik al zei: het ligt niet aan de HTTP_REFERER.

Gegarandeerd dat het dan zou werken he
Wat krijg ik nu van Xtentic?

[Verwijderd]

Ow het werkt ook gegarandeerd maar wanneer de domein geen gegevens geeft geeft die $HTTP_REFERER wel dus ook geen info, dat wil nog niet zeggen dat dat niet werkt

b.t.w tegenwoordig is het xtentic

[eek]

gebruik gewoon die javascript redirect

[Grum]

na post 5 oid ging et fout
tis $HTTP_REFERRER

[Pelle]

Op vrijdag 08 februari 2002 17:12 schreef xtentic het volgende:
/me denkt dat pelle te veel denkt, probeer het eens op een andere manier of laat eens wat meer code zien ... indien het geen probleem is van de server kant moet je toch eens gaan kijken of de fout in je eigen source verwerkt zit

* Pelle diepe zucht

..en dan zeggen ze dat ik eigenwijs ben. Hmmm.

Ok, bijvoorbeeld (en om even duidelijk te maken dat het niet aan de referer ligt, een voorbeeld zonder referer waarbij hetzelfde probleem optreedt):

melp.php

code:

<a href="login.php?page=blaat.php">klik hier</a>

login.php

PHP:

<?
/* query doen, opslaan in session-var, je kent het wel */
header("Location: $page");
/* FYI: dit geeft hetzelfde resultaat als de volgende constructies 
   (waarvan het overigens nutteloos is om ze te testen omdat je van te
   voren al inziet dat het daar niet aan ligt) :
   header("Location: $page\n");
   header("Location: " . $page);
   header("Location: " . $page . "\n"); */
?>

En wat is dan de output? Precies, toch login.php en niet blaat.php:



Dus Xtentic, wees maar niet bang, ik weet waar ik het over heb, en zeker met iets simpels als dit vind ik het een beetje raar dat je suggereert dat m'n source niet klopt. Lees het hele topic nog eens door, dan snap je misschien waar het over gaat en dat het een bug of feature betreft waarover op php.net niks te vinden was, noch op de help-pages van Vuurwerk zelf. Vandaar dat ik het hier vroeg. En niet om een JS-oplossing te krijgen (wat ik overigens wel op prijs stel, daar niet van), maar dus om een antwoord te krijgen op de vraag waarom de server niet redirect, maar include.

[D2k]

k ik doe ook weer een gok
doe eens echo "'$page'";
en dan evt trim($page)

[Pelle]

Op vrijdag 08 februari 2002 19:21 schreef Grum_ het volgende:
na post 5 oid ging et fout
tis $HTTP_REFERRER

Dat had * Pelle niet van Grum_ verwacht
Op heel php.net hebben ze het namelijk over $HTTP_REFERER namelijk. Zie hier bijvoorbeeld:

http://www.php.net/manual/en/faq.using.php
onderaan, bij puntje 11

Voor de volledigheid:
zoeken op php.net naar http_referrer
zoeken op php.net naar http_referer

Dus

_{maar zoals gezegd, dat heeft met dit probleem niks te maken}

[Pelle]

Op vrijdag 08 februari 2002 19:26 schreef D2k het volgende:
k ik doe ook weer een gok
doe eens echo "'$page'";
en dan evt trim($page)

Believe me, ik heb alle soorten debug-trucks al uit de kast gehaald. Het is gewoon naar alle waarschijnlijkheid een vuile streek van de webserver, die ik had gehoopt met een PHP-oplossing te kunnen omzeilen, door eerst bijvoorbeeld andere headers te versturen ofzo.

[eborn]

Ik heb zelf ook gemerkt dit prima onder Apache werkt (Linux, maar vast ook de Windows port), maar als ik precies hetzelde script onder IIS draai dan gaat het mis.

[Sjaaky]

Als er in de titelbalk login.php blijft staan en de gebruiker refresht de site dan stuurt login.php toch blaat.php weer door? Dan maakt het toch niet uit wat er in de titelbalk staat?

Je hebt naast de javascript- en http-redirect ook nog een html-redirect.

code:

<html>
<head>
 <meta HTTP-EQUIV="REFRESH" CONTENT="3;URL=http://www.com/etc.php">
</head>
..
</html>

Dit wordt door veel meer clients ondersteund dan de javascript oplossing. De 3 achter CONTENT= staat voor het aantal seconden dat er gewacht moet worden voordat de client gaat refreshen.

[Grum]

Op vrijdag 08 februari 2002 19:29 schreef Pelle het volgende:

[..]

Dat had * Pelle niet van Grum_ verwacht
Op heel php.net hebben ze het namelijk over $HTTP_REFERER namelijk. Zie hier bijvoorbeeld:

http://www.php.net/manual/en/faq.using.php
onderaan, bij puntje 11

Voor de volledigheid:
zoeken op php.net naar http_referrer
zoeken op php.net naar http_referer

Dus

_{maar zoals gezegd, dat heeft met dit probleem niks te maken}

niemand heeftet gezien

[Pelle]

Op vrijdag 08 februari 2002 20:41 schreef Sjaaky het volgende:
Als er in de titelbalk login.php blijft staan en de gebruiker refresht de site dan stuurt login.php toch blaat.php weer door? Dan maakt het toch niet uit wat er in de titelbalk staat?

Noop. Want naar login.php zijn gegevens gepost, en zijn die niet aanwezig of foutief dan wordt er een header("Location: ") naar een andere pagina geset.

Je hebt naast de javascript- en http-redirect ook nog een html-redirect.

Yepz, weet ik. Het feit dat het onder IIS niet werkt, zegt me genoeg om te vermoeden dat het inderdaad aan de webserver ligt. Niks aan te doen, jammer dan. HTML of JS-oplossing dan maar

Bedankt voor de reacties iig

[Verwijderd]

Op vrijdag 08 februari 2002 19:24 schreef Pelle het volgende:
Dus Xtentic, wees maar niet bang, ik weet waar ik het over heb, en zeker met iets simpels als dit vind ik het een beetje raar dat je suggereert dat m'n source niet klopt. Lees het hele topic nog eens door, dan snap je misschien waar het over gaat en dat het een bug of feature betreft waarover op php.net niks te vinden was, noch op de help-pages van Vuurwerk zelf. Vandaar dat ik het hier vroeg. En niet om een JS-oplossing te krijgen (wat ik overigens wel op prijs stel, daar niet van), maar dus om een antwoord te krijgen op de vraag waarom de server niet redirect, maar include.

Jah de meeste foutjes worden gemaakt doordat mensen of te snel coden (zoals ik) of omdat ze maar halve kennis hebben van de dingen waar ze mee bezig zijn (ook zoals ik). Dus is het normaal dat ik daar dus ook vanuit ga want zoals ik heb gezien ben je meer een expert in JS dan in PHP, maar als het niet aan je source ligt probeer het dan eens op een f2s acount, je mag die van mij benutten indien je dat graag wilt

(username/password kan je krijgen )

[Sjaaky]

Tja je kan het natuurlijk ook op een heel andere manier oplossen en dat werkt met een include. Deze controleert of je ingelogd bent (dmv een session of desnoods cookies).
Als dat zo is laat hij gewoon de pagina zien.
Als dat niet zo is laat hij een inlog schermpje zien, de user vult de gegevens in en post ze daarna. De inlog-include ziet dat en zorgt er dmv een sessie voor dat hij ook de volgende keer weet dat de user is ingelogd.
Het uitloggen gebeurt door het beeindigen van de sessie.
(bij deze manier komen er dus geen redirects aan te pas).

Op de manier zoals jij het nu doet kan je (denk ik) zonder in te loggen in het beveiligde gedeelte komen, als je de url weet naar dat bestand.

[johnwoo]

dit werkt bij mij prima

PHP:

<?
header('302 Found');
header('Location: ' . $thefile);
?>

[brammetje]

Op vrijdag 08 februari 2002 21:15 schreef Pelle het volgende:
Yepz, weet ik. Het feit dat het onder IIS niet werkt, zegt me genoeg om te vermoeden dat het inderdaad aan de webserver ligt. Niks aan te doen, jammer dan. HTML of JS-oplossing dan maar

Dat lijkt mij ook inderdaad.

[Verwijderd]

Op vrijdag 08 februari 2002 21:32 schreef Sjaaky het volgende:
[verhaal over een andere manier]

Op de manier zoals jij het nu doet kan je (denk ik) zonder in te loggen in het beveiligde gedeelte komen, als je de url weet naar dat bestand.

pelle is niet dom, volgens mij, hij zal vast wel bovenaan elke pagina een include naar een controle functie hebben staan of de client wel ingelogd is...

[Verwijderd]

Op vrijdag 08 februari 2002 21:22 schreef xtentic het volgende:

[..]

Jah de meeste foutjes worden gemaakt doordat mensen of te snel coden (zoals ik) of omdat ze maar halve kennis hebben van de dingen waar ze mee bezig zijn (ook zoals ik). Dus is het normaal dat ik daar dus ook vanuit ga want zoals ik heb gezien ben je meer een expert in JS dan in PHP, maar als het niet aan je source ligt probeer het dan eens op een f2s acount, je mag die van mij benutten indien je dat graag wilt

(username/password kan je krijgen )

lees eerst eens goed de reactie van pelle en dan de hele topic nog eens door, men was er al lang uit dat het niet aan de source ligt...
het zou kunnen dat je de indruk hebt gekregen dat pelle meer een JS expert is, maar hij kan heus wel een php script debuggen, je doet alsof pelle een php newbie is, en daar zit ik me notabene aan te ergeren

[HGM]

Op vrijdag 08 februari 2002 22:12 schreef jurriebur het volgende:

[..]

lees eerst eens goed de reactie van pelle en dan de hele topic nog eens door, men was er al lang uit dat het niet aan de source ligt...
het zou kunnen dat je de indruk hebt gekregen dat pelle meer een JS expert is, maar hij kan heus wel een php script debuggen, je doet alsof pelle een php newbie is, en daar zit ik me notabene aan te ergeren

Check de naam van het plaatje van Pelle, dat zegt genoeg

[Pelle]

Op vrijdag 08 februari 2002 21:22 schreef xtentic het volgende:
Jah de meeste foutjes worden gemaakt doordat mensen of te snel coden (zoals ik) of omdat ze maar halve kennis hebben van de dingen waar ze mee bezig zijn (ook zoals ik). Dus is het normaal dat ik daar dus ook vanuit ga want zoals ik heb gezien ben je meer een expert in JS dan in PHP, maar als het niet aan je source ligt probeer het dan eens op een f2s acount, je mag die van mij benutten indien je dat graag wilt

Euhm, ik weet niet hoe jij mijn PHP-skills met mijn JS-skills kunt vergelijken want voor zover ik weet is er hier op GoT namelijk heel weinig bekend over mijn PHP-kunsten.
Ik ga hier niet roepen dat ik een goeroe ben, want dat ben ik niet, maar ik ben met anderhalf jaar professionele en beroepsmatige PHP-ervaring denk ik het n00b-niveau wel ontgroeid.
Bedankt voor je aanbod, maar ik heb zelf lokaal (thuis en op m'n werk) een webserver draaien, een f2s-account, een host.sk-account en onbeperkte toegang tot de server van m'n werk, dus daar hoef je je niet druk om te maken.

Op vrijdag 08 februari 2002 21:32 schreef Sjaaky het volgende:
Tja je kan het natuurlijk ook op een heel andere manier oplossen en dat werkt met een include. Deze controleert of je ingelogd bent (dmv een session of desnoods cookies).
Als dat zo is laat hij gewoon de pagina zien.
Als dat niet zo is laat hij een inlog schermpje zien, de user vult de gegevens in en post ze daarna. De inlog-include ziet dat en zorgt er dmv een sessie voor dat hij ook de volgende keer weet dat de user is ingelogd.
Het uitloggen gebeurt door het beeindigen van de sessie.
(bij deze manier komen er dus geen redirects aan te pas).

Op de manier zoals jij het nu doet kan je (denk ik) zonder in te loggen in het beveiligde gedeelte komen, als je de url weet naar dat bestand.

Ik include al een login-check, en alle pagina's zijn gewoon openbaar; de enige reden dat die login erin zit is zodat authorized users de pagina ook realtime kunnen editen. Login en userrights worden opgeslagen in de session, en indien de rechten van de ingelogde user toestaan dat een pagina geedit wordt, dan wordt er een stuk javascript geinclude die editen mogelijk maakt.
De file login.php zorgt slechts voor het vullen van de session-vars, en niks anders. Alle pagina's zijn dus door iedereen te zien, en het is dus niet zo dat je op beveiligde gedeeltes van de pagina kunt komen zonder daarvoor gerechtigd te zijn.

Dus mensen, wees maar niet bang, ik post hier wel niet zo vaak in /14 maar ik weet echt wel waar ik mee bezig ben

[drZymo]

Uhm zoals johnwoo ook al indirect vertelde. De server stuurt na een redirect wel een 302 door (wat een redirect aangeeft), maar kan daarna ook gewoon de html pagina meegeven. Het ligt aan de client om dan de url te verversen of niet. De url staat namelijk in de http header.

De client krijgt dus een 302, met een Location : blabla.bla. De client kan dan zelf bepalen of hij dit wilt tonen of niet. Ik zou het dus willen aanraden om het ook ff met andere browsers te proberen. Werkt het overal niet, ja dan is er wat fout met der server

edit: het gaat hier dus om het VERVERSEN van de adresbalk.

[SchizoDuckie]

Krijgt iemand als je een session init, niet ook een cookie ge-set


Dan klopt het wel, header:location werkt niet na een setcookie

[D2k]

Op zaterdag 09 februari 2002 13:02 schreef papa_eend het volgende:
Krijgt iemand als je een session init, niet ook een cookie ge-set


Dan klopt het wel, header:location werkt niet na een setcookie

mjah dan zou ie een error krijgen toch?
en die krijgt ie niet....
Pelle: ik heb ook nog eens zitten kijken maar ook nog nix kunnen ontdekken

[SchizoDuckie]

Op zaterdag 09 februari 2002 13:08 schreef D2k het volgende:

[..]

mjah dan zou ie een error krijgen toch?
en die krijgt ie niet....
Pelle: ik heb ook nog eens zitten kijken maar ook nog nix kunnen ontdekken

Lees hier maar eens wat reacties over header(Location:);

http://www.php.net/manual/en/function.setcookie.php

[D2k]

Op zaterdag 09 februari 2002 13:12 schreef papa_eend het volgende:

[..]

Lees hier maar eens wat reacties over header(Location:);

http://www.php.net/manual/en/function.setcookie.php

mjah ik zie het nu van die link ff niet?
je kan makkelijk zoiets doen hoor

PHP:

<?
setcookie ("blaat", "waarde",time()+$time);
header("Location:index2.php");
?>

dus ik snap je ff niet?

[Verwijderd]

gewoon zo... ?

function redirect($url, $delay=0) {
echo "<meta http-equiv='Refresh' content='$delay; url=$url'>";
die;
}

was al wel genoemd maar het werkt wel waarschijnlijk...

[Orphix]

Je pikt zo de mensen die niet vaak in /13 komen er uit
Kijk maar eens naar de icon van Pelle aan zijn onvaardigheden ligt het echt niet. Ik vind het jammer dat die een beetje onterecht zo wordt behandeld.
Lees de thread eens door, hij kent de JS en Meta-tags oplossingen ook wel, maar dat is minder mooi (en terecht).

Ik weet ook nog steeds de oplossing niet, maar ik wou nog ff een idee geven, probeer eens na de header(..) wat output te printen. Misschien maar een paar newlines oid, misschien dat die de pagina dan wel terugstuurt.

[Pelle]

* HGM just became my personal hero

In plaats van:

PHP:

<?
header("Location: $page");
?>

..raadde hij dit aan:

PHP:

<?
header("Location: http://www.volledigeurl.nl/metpath/$page");
?>

En dat werkt
Thanks!

[Erik Jan]

Op zaterdag 09 februari 2002 17:20 schreef Pelle het volgende:
En dat werkt
Thanks!

Klopt had ik ook een keer gehad, Xitami wil ook een volledige URL. Maarhmm, bevat de HTTP_REFERER die je browser doorgeeft niet de volledige URL IE doet dat wel geloof ik...

[Pelle]

Op zaterdag 09 februari 2002 17:37 schreef Erik Jan het volgende:
Klopt had ik ook een keer gehad, Xitami wil ook een volledige URL. Maarhmm, bevat de HTTP_REFERER die je browser doorgeeft niet de volledige URL IE doet dat wel geloof ik...

Klopt, maar het voordeel is dat ik 1 pagina heb waarvandaan alles wordt aangeroepen (index.php). Ik hoef dus alleen de id van de pagina mee te geven aan het loginscript om weer op de goeie plek uit te komen (login.php?page=4 redirect dan dus naar index.php?page=4), en dat is precies wat ik wil.

[Verwijderd]

Probeer eens:

<?php
Header("Location: http://" . HTTP_REFERER);
?>

Kan zijn dat ie zonder dat http:// eem lokaal bestand
probeert te zoeken. Krijg je geen foutmelding ofzo?
Duurt het gewoon lang en/of komt ie met een 404 file not
found error? Zoja, dan zou dit het kunnen zijn.\
Suc7.

[Pelle]

Op zondag 10 februari 2002 09:38 schreef delite het volgende:
Probeer eens:

<?php
Header("Location: http://" . HTTP_REFERER);
?>

Kan zijn dat ie zonder dat http:// eem lokaal bestand
probeert te zoeken. Krijg je geen foutmelding ofzo?
Duurt het gewoon lang en/of komt ie met een 404 file not
found error? Zoja, dan zou dit het kunnen zijn.\
Suc7.

* Pelle *
Misschien moet je eerst het topic eens doorlezen voor je een reply geeft; dat bespaart je een hoop tikwerk namelijk

[RedHat]

je header:location werkt niet om dat er al headers gestuurt zijn in je script.
gewoon meta http evec doen.

[man-o-script]

Op vrijdag 08 februari 2002 12:46 schreef Petuhr het volgende:

[..]

Wil nix zeggen hoor, maar wilco is geen beheer