[PHP] header (location)

[Verwijderd]

Voor je met antwoorden post, lees dan liefst eerst deze post: http://gathering.tweakers.net/forum/list_messages/764502
Ik heb net hetzelfde probleem, en ik heb al alles gedaan wat daar werd
aangeraad, maar niets gaf een oplossing.

Hopelijk heeft de topic starter van de vorige post al een ander en deftigere oplossing gevonden
dan zijn meta of javascript ...

Ik zit met helemaal hetzelfde probleem.

Werkt lokaal perfect (IIS) maar op de webhost (Apache) niet meer.
Ik krijg ook een witte pagina zonder fout.
Er komen geen error's in mijn error-log binnen.

Dat redirecten kan toch zo complex niet zijn?
Ik kan me niet voorstellen dat iedereen zo'n slordige code
moet schrijven in php om te kunnen doorsturen naar een
andere pagina.

Mijn redirect gaat als volgt...

PHP:

   session_write_close();
   $URL = $root . $taal . "/intrest.php";
   header ("Location : $URL");
   exit();

DE $URL bevat wel degelijk de juiste absolute URL!
Als ik na de header een echo "tekst" beeld hij deze af
op de anders zo lege en witte website, alsof de header er
gewoon niet stond.

Ik heb ook een klein scriptje in elkaar geplooid om de header
functie te testen en daar lukt het WEL.

Met het toevoegen van echo "tekst" heb ik mijn code al opgevolgd
of deze wel degelijk de weg volgt die het moet volgen en alles klopt
maar er wordt blijkbaar gewoon over de header()-functie gesprongen.

[Megamind]

Je mag ook geen text output geven na een header Zet een je error-reporting op E_ALL en dan zie je pas wat er aan de hand is. Zet ook voor de zekerheid een exit; achter je header();

[Verwijderd]

Megamind schreef op zaterdag 11 december 2004 @ 09:41:
Je mag ook geen text output geven na een header Zet een je error-reporting op E_ALL en dan zie je pas wat er aan de hand is. Zet ook voor de zekerheid een exit; achter je header();

Jij kan die vorige post blijkbaar heel snel lezen!
Dat stond daar ook in als mogelijkheid om je probleem te debuggen.
Dat heb ik gedaan, en het gaf ook NIETS van output, dus bij deze ben
ik zeker dat de header zeker niet in conflict komt met eerder verstuurde
headers! Het komt er op neer dat de code gewoon de header functie overslaat.

Blijkbaar heb je zelf mijn post niet helemaal gelezen ! want er staat exit()
na mijn header() !

[ Voor 8% gewijzigd door Verwijderd op 11-12-2004 09:46 ]

[Grijze Vos]

euhm, ik heb een probleem gehad met firefox een keer, die las de header niet als ik niets outputte naar de browser. Ik -moest- dus juist wel wat output erachter zetten.

[Verwijderd]

Grijze Vos schreef op zaterdag 11 december 2004 @ 10:06:
euhm, ik heb een probleem gehad met firefox een keer, die las de header niet als ik niets outputte naar de browser. Ik -moest- dus juist wel wat output erachter zetten.

Ik heb het al met IE6 en firefox getest, maar het blijft het zelfde,
ik zal nog eens opera proberen ook, maar ik denk dat daar het
probleem niet zit.

---

Opera : Zelfde probleem

[GlowMouse]

Waar staat de site? Dan kunnen we zelf even kijken wat er gebeurt.

[Verwijderd]

GlowMouse schreef op zaterdag 11 december 2004 @ 10:29:
Waar staat de site? Dan kunnen we zelf even kijken wat er gebeurt.

www.splendidvending.be/test/

Je gaat naar "Audit" -> "Start Wizard"

Dan krijg je een formulier die je moet invullen.
Of je die nu juist of fout invult doet er niet toe.
Je wordt zowiezo doorgestuurd naar php/wizard.php
die de controle uitvoerd en naargelang het juist is
of fout je doorstuurd of terugstuurd.
Het is dus die file waar het misloopt en je krijg niets te zien...

[GlowMouse]

Even gesnifft, dit is wat er gebeurt:

POST /test/php/wizard.php?form=1&taal=ned HTTP/1.0
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*
Referer: http://www.splendidvendin...19a08f7a870a94ae36ed0a685
Accept-Language: nl
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)
Host: www.splendidvending.be
Content-Length: 80
Connection: Keep-Alive
Pragma: no-cache
Cookie: PHPSESSID=e0fb53919a08f7a870a94ae36ed0a685

firm=&street=&nr=&code=&city=&lastname=&firstname=&tel=&mail=&next=next%A0%3E%3EHTTP/1.1 200 OK
Date: Sat, 11 Dec 2004 10:26:02 GMT
Server: Apache/1.3.33 (Unix) mod_gzip/1.3.26.1a mod_auth_passthrough/1.8 mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.9 FrontPage/5.0.2.2634a mod_ssl/2.8.21 OpenSSL/0.9.7a
X-Powered-By: PHP/4.3.9
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://www.splendidvending.be/test/ned/form1.php
Connection: close
Content-Type: text/html

Er zit een spatie tussen Location en de dubbelepunt. Misschien ligt het daaraan.
Verder ziet het er goed uit.

[ Voor 3% gewijzigd door GlowMouse op 11-12-2004 11:28 ]

[Verwijderd]

Je moet natuurlijk geen code 200 terugkrijgen, maar 30x.

En er mag inderdaad geen spatie tussen location en de dubbelepunt. Ik vraag me toch telkens af waar mensen zulke dingen vandaan halen. Daar is nou documentatie voor, in dit geval hier

[Verwijderd]

Hartelijk dank GlowMouse & Cheatah

Vreemd dat ze in die oude topic er zo lang hebben over gedaan,
om het niet te vinden en u zo snel een juist oplossing!

En tjah, hoe dat komt dat mensen daar niet achter kijken.
Omdat veel programmeertalen daar veel te soepelen in zijn!

Ik ben nieuw in de wereld van php maar vanaf nu heb ik dus
ook geleerd dat php heel strict is ... hartelijk dank!

Voor mijn part mag er een slotje op want het is beantwoord...
of is dat hier de gewoonte niet?

[NMe]

Verwijderd schreef op zaterdag 11 december 2004 @ 12:41:
Hartelijk dank GlowMouse & Cheatah

Vreemd dat ze in die oude topic er zo lang hebben over gedaan,
om het niet te vinden en u zo snel een juist oplossing!

In dat andere topic was dat de fout niet, daar stond de header netjes zoals het hoorde.

En tjah, hoe dat komt dat mensen daar niet achter kijken.
Omdat veel programmeertalen daar veel te soepelen in zijn!

Ik ben nieuw in de wereld van php maar vanaf nu heb ik dus
ook geleerd dat php heel strict is ... hartelijk dank!

PHP is juist één van de minst stricte talen die ik ken. Dit heeft dan ook niks met PHP te maken, maar het HTTP protocol, en daar moet je je wel degelijk aan houden.

Voor mijn part mag er een slotje op want het is beantwoord...
of is dat hier de gewoonte niet?

Nee.

[Verwijderd]

Verwijderd schreef op zaterdag 11 december 2004 @ 12:41:

Ik ben nieuw in de wereld van php maar vanaf nu heb ik dus
ook geleerd dat php heel strict is ... hartelijk dank!

Het is eerder dat het HTTP protocol vrij goed is vastgelegd. Wat ik raar vind is dat Apache, de HTTP server, gewoon een verkeerde header accepteert en meestuurt in de response. Wat mij betreft zou Apache dat niet moeten pikken. En anders zou de header functie het wel af moeten vangen. Die zou best een warning mogen geven als er een ongeldige header bij zit.

In dit geval lijkt het me duidelijk dat de PHP functie header jouw header niet herkent als iets waarbij hij een speciale actie moet ondernemen (een 30x response gebruiken). Daarom gaat het dus mis.

[Verwijderd]

Ik heb wel al gemerkt dat bestanden zoals 404.shtml, 403.shtml niet op mijn webhost staan, misschien daarom dat ik een wit scherm krijg en geen fout ... alhoewel er geen enkele error binnenkomt in mijn error-log.

En het is bij de Apache server dat hij de witte pagina toont,
en bij IIS dat hij er niets van aantrekt en de header toch uitvoert.
Misschien stond er bij de IIS standaard buffering op voor er output kwam.
en is IIS wat soepeler met HTTP standaarden. (zou me niet verwonderen,
't is tenslotten een microsoft product )

[GlowMouse]

Ik heb wel al gemerkt dat bestanden zoals 404.shtml, 403.shtml niet op mijn webhost staan, misschien daarom dat ik een wit scherm krijg en geen fout ... alhoewel er geen enkele error binnenkomt in mijn error-log.

Heeft hier niets mee te maken, want er wordt geen pagina opgevraagd die niet bestaat ofzo.

Verwijderd schreef op zaterdag 11 december 2004 @ 13:34:
En het is bij de Apache server dat hij de witte pagina toont,
en bij IIS dat hij er niets van aantrekt en de header toch uitvoert.
Misschien stond er bij de IIS standaard buffering op voor er output kwam.
en is IIS wat soepeler met HTTP standaarden. (zou me niet verwonderen,
't is tenslotten een microsoft product )

Zinloos microsoft-gebash. Het is de client die de header interpreteert, en niet de server. Blijkbaar had IIS wel door dat de spatie daar niet hoort, en had hem daarom weggehaald.

[Verwijderd]

GlowMouse schreef op zaterdag 11 december 2004 @ 14:53:

Zinloos microsoft-gebash. Het is de client die de header interpreteert, en niet de server. Blijkbaar had IIS wel door dat de spatie daar niet hoort, en had hem daarom weggehaald.

Terechte bash dus. Programmeertalen moeten niet iets gaan wijzigen omdat de programmeur vast iets anders bedoelt had. Er hoort een waarschuwing of foutmelding gegeven te worden, die de programmeur moet oplossen. Kortom, zowel PHP als Apache als IIS doet erg raar.

[edit]
Net zoiets achterlijks: als er een undefined constant gebruikt wordt, dan geeft de interpreter een notice, maar hij gaat gewoon lekker verder en behandelt het verder als een string. Daardoor lopen er nog steeds prutsers rond die $_POST[melp] gebruiken, terwijl ze $_POST['melp'] bedoelen.

[ Voor 22% gewijzigd door Verwijderd op 11-12-2004 14:57 ]

[drm]

Cheatah:
Het is eerder dat het HTTP protocol vrij goed is vastgelegd. Wat ik raar vind is dat Apache, de HTTP server, gewoon een verkeerde header accepteert en meestuurt in de response. Wat mij betreft zou Apache dat niet moeten pikken. En anders zou de header functie het wel af moeten vangen. Die zou best een warning mogen geven als er een ongeldige header bij zit.

In HTTP is volgens mij helemaal niet vastgelegd dat je geen onbestaande headers mee mag sturen. D'r staat ook niet dat het wel mag, maar goed

In dit geval lijkt het me duidelijk dat de PHP functie header jouw header niet herkent als iets waarbij hij een speciale actie moet ondernemen (een 30x response gebruiken). Daarom gaat het dus mis.

Dat doet Apache, want de HTTP response code wordt door apache toegevoegd, niet door php. Dat is ook de reden dat sommige headers in een cgi versie van php niet werken. Maar da's een detail

[Verwijderd]

drm schreef op zaterdag 11 december 2004 @ 14:55:

In HTTP is volgens mij helemaal niet vastgelegd dat je geen onbestaande headers mee mag sturen. D'r staat ook niet dat het wel mag, maar goed

Het is wel degelijk vastgelegd. Ik ga het niet helemaal opsommen, maar als je de HTTP/1.1 RFC doorleest, dan zie je vanzelf wel dat elke header regel (op de status regel na) voldoet aan het patroon token ":" waarde, waarbij de token natuurlijk geen spaties mag bevatten. Zie hoofdstuk 4.

Dat doet Apache, want de HTTP response code wordt door apache toegevoegd, niet door php. Dat is ook de reden dat sommige headers in een cgi versie van php niet werken. Maar da's een detail

In de documentatie wordt niet geheel duidelijk of het PHP of Apache is die daarvoor zorgt, ik persoonlijk dacht dat het PHP was.

Maar het neemt niet weg dat ik vindt dat zowel PHP als de webserver het verkeerd doen als je hier geen waarschuwing voor krijgt

[drm]

Cheatah:
Het is wel degelijk vastgelegd. Ik ga het niet helemaal opsommen, maar als je de HTTP/1.1 RFC doorleest, dan zie je vanzelf wel dat elke header regel (op de status regel na) voldoet aan het patroon token ":" waarde, waarbij de token natuurlijk geen spaties mag bevatten. Zie hoofdstuk 4.

Ja, dat klopt, de syntax wel, maar niet welke headers wel en niet gestuurd mogen worden.

edit:

Cheatah:
In de documentatie wordt niet geheel duidelijk of het PHP of Apache is die daarvoor zorgt, ik persoonlijk dacht dat het PHP was.

Ik heb mijn conclusies getrokken n.a.v. http://nl.php.net/manual/en/features.http-auth.php merk ik. 't Gaat namelijk op zodra je zelf de response code wilt bepalen (bijv 404). Dat werkt alleen als php een module is en niet in de cgi versie. Als PHP zelf de response code zou verzorgen, zou ik niet weten waarom het dan in de cgi versie niet zou werken. Maar 't staat er niet expliciet idd.

[ Voor 43% gewijzigd door drm op 11-12-2004 15:25 ]

[Verwijderd]

drm schreef op zaterdag 11 december 2004 @ 15:20:

Ja, dat klopt, de syntax wel, maar niet welke headers wel en niet gestuurd mogen worden.

In dit geval is de syntax dus gewoon fout, vandaar de opmerking. Je mag inderdaad je eigen headers bedenken en meesturen, zolang ze maar aan die standaard syntax voldoen.

Ze zijn dus wellicht onbekend, maar moeten wel kunnen worden herkend. Zijn we het zo met elkaar eens?

[drm]

ja, ik geloof dat we het dan al eens waren

[Verwijderd]

nu we toch bezig zijn over headers. ik doe gewoon dit:

header("location: form.php"), dus zonder de gehele url de voor. Ik weet dat dit niet volgens de "standaard" is, maar het werkt gewoon in FF en IE browsers. Voor deze site http://www.n0thing.org (testsite) heb ik zelfs alleen maar de variabele mee gegeven, dus zoiets als header("location: ?msg=3").

Weten jullie misschien of er (nog) browsers zijn waarbij dit niet werkt??

[ Voor 14% gewijzigd door Verwijderd op 12-12-2004 02:52 . Reden: was ik toch ff location vergeten, dom, dom ]

[drm]

Da's nou precies de reden dat je je aan 't protocol moet houden. Dan hoef je die vraag namelijk helemaal niet te stellen

[Alex)]

Ik had zelf een keer deze fout gemaakt, en het werkte voor geen meter.
Ik zocht me rot, uiteindelijk gevonden... Location: ontbrak.
Dat het geaccepteerd wordt vind ik raar, kennelijk corrigeert de webserver je fout ofzo... het hoort i.i.g. niet en dat moet verbeterd worden!

[Verwijderd]

Alex schreef op zondag 12 december 2004 @ 01:52:
Ik had zelf een keer deze fout gemaakt, en het werkte voor geen meter.
Ik zocht me rot, uiteindelijk gevonden... Location: ontbrak.
Dat het geaccepteerd wordt vind ik raar, kennelijk corrigeert de webserver je fout ofzo... het hoort i.i.g. niet en dat moet verbeterd worden!

nou je het zegt, ik ben natuurlijk "location: " vergeten, zal het ff aanpassen. (dit was ik dus niet vergeten bij m'n scriptje)

[ Voor 7% gewijzigd door Verwijderd op 12-12-2004 02:54 . Reden: extra info ]

[Alex)]

Ok, dat werkt gewoon. Alleen blijft dan vaak het oude URL in de adresbalk staan (bij IE iig wel)
Daarom is het beter om toch een volledig pad te pakken...

[Verwijderd]

Bij deze pleit ik voor een vereenvoudiging van RFC's, ;.. dan zou ik ze eindelijk eens lezen
(en Microsoft misschien ook ) Het is net of sommige er een roman willen van maken!

[NMe]

Verwijderd schreef op zondag 12 december 2004 @ 10:21:
Bij deze pleit ik voor een vereenvoudiging van RFC's, ;.. dan zou ik ze eindelijk eens lezen
(en Microsoft misschien ook ) Het is net of sommige er een roman willen van maken!

NOFI, maar complexe zaken zijn niet voor luie mensen.

[Verwijderd]

Ik kan ook niks in de RFC vinden. Deze zijn te complex en onlogisch opgebouwd.